Technical Lab: Configure identity-based access for Azure Files
Questions
Question 1 — Multiple Choice
An administrator team needs to enable identity-based authentication for an SMB share in Azure Files. The environment has on-premises domain controllers synchronized with Microsoft Entra ID via Microsoft Entra Connect, and clients access files from machines joined to the local AD DS domain.
Which identity source should be configured in the storage account for share-level and file-level permissions to work correctly in this scenario?
A) Microsoft Entra Kerberos, as it's the only option that validates tokens issued by Entra ID for hybrid clients
B) On-premises AD DS, as clients are joined to the local domain and Kerberos authentication will be issued by local DCs
C) Microsoft Entra Domain Services, as it offers automatic integration with Entra Connect synchronization
D) No additional configuration is needed, as Entra Connect already propagates identities to the storage account automatically
Question 2 — Technical Scenario
An administrator configured on-premises AD DS authentication for an Azure Files share and assigned the Storage File Data SMB Share Contributor role to a group of users at the share level. After configuration, users can list files but cannot create or modify existing files.
Share-level permission: Storage File Data SMB Share Contributor
Directory/file-level permission (NTFS): Not configured (inheriting default)
What is the most likely cause of the described behavior?
A) The Storage File Data SMB Share Contributor role doesn't cover write operations; the correct one would be Storage File Data SMB Share Elevated Contributor
B) NTFS permissions at the directory/file level are blocking writes, as Azure Files applies both layers and the most restrictive permission prevails
C) AD DS authentication doesn't support write operations on SMB shares; this requires Microsoft Entra Kerberos
D) The storage account needs to have hierarchical namespace enabled for write permissions to work via identity
Question 3 — True or False
When configuring Microsoft Entra Kerberos for Azure Files access, machines joined exclusively to the on-premises AD DS domain (without hybrid join or Entra ID join) can authenticate using this method without any additional client configuration.
Question 4 — Technical Scenario
An administrator needs external users (B2B guests) to access an Azure Files share via SMB using their corporate identities already present in Microsoft Entra ID. The environment doesn't have on-premises AD DS.
After enabling Microsoft Entra Kerberos in the storage account and assigning the Storage File Data SMB Share Reader role to guests, users report they cannot mount the share.
Which step was omitted?
A) Guests need to be converted to native tenant members before accessing SMB shares
B) It's necessary to enable hierarchical namespace for Microsoft Entra Kerberos to work with external identities
C) SMB access with Microsoft Entra Kerberos requires clients to be Entra ID joined or hybrid; B2B guests are not supported in this flow
D) The correct role for B2B guests is Storage File Data SMB Share Elevated Contributor; the Reader role doesn't allow mounting
Question 5 — Multiple Choice
Considering the three identity sources supported by Azure Files for SMB authentication (on-premises AD DS, Microsoft Entra Domain Services, and Microsoft Entra Kerberos), which statement correctly describes a behavioral difference between them?
A) Only Microsoft Entra Domain Services requires the storage account to be in the same virtual region as the service's managed network
B) Microsoft Entra Kerberos issues Kerberos tickets directly through Entra ID, while on-premises AD DS and Microsoft Entra Domain Services depend on domain controllers for ticket issuance
C) On-premises AD DS supports NFS share mounting, while other options support only SMB
D) Microsoft Entra Domain Services doesn't support NTFS permissions at the file level; only share-level permissions via RBAC are applicable
Answer Key and Explanations
Answer Key — Question 1
Answer: B
When clients are joined to on-premises AD DS and the environment uses Microsoft Entra Connect only for synchronization, Kerberos ticket issuance occurs through local domain controllers. The storage account must be configured with the on-premises AD DS source, which requires registering the storage account as a computer object or service account in the local Active Directory.
The main error in incorrect alternatives is confusing identity synchronization (Entra Connect) with Kerberos authentication: Entra Connect doesn't automatically delegate authentication to Entra ID. Microsoft Entra Kerberos is suitable for clients with hybrid join or Entra ID join, not for exclusively on-premises clients.
Answer Key — Question 2
Answer: B
Azure Files applies two independent layers of access control: share-level permissions via RBAC and NTFS permissions at the directory and file level. When NTFS permissions aren't explicitly configured, default behavior may restrict writes depending on how the share was created. The most restrictive permission between the two layers always prevails.
Alternative A is a plausible distractor but incorrect: the Storage File Data SMB Share Contributor role includes read and write. Alternative C is false; on-premises AD DS supports writes normally. Alternative D confuses Azure Files with Azure Data Lake Storage Gen2, where hierarchical namespace is relevant for access control.
Answer Key — Question 3
Answer: False
Microsoft Entra Kerberos requires the client device to be Entra ID joined (Entra ID join) or hybrid joined (Hybrid Entra ID join). Machines joined exclusively to on-premises AD DS cannot obtain tokens from Entra ID to initiate the Kerberos authentication flow via Entra, as this mechanism depends on the client's ability to authenticate directly with Entra ID. For these clients, the correct source is on-premises AD DS.
Answer Key — Question 4
Answer: C
Microsoft Entra Kerberos supports tenant member users (including hybrid join scenarios), but does not support B2B guest identities for SMB mounting. This is an explicit limitation of the authentication method: the Kerberos ticket acquisition flow via Entra ID is not available for guest identities.
Alternative A is incorrect because converting guests to members is not a standard Azure Files operation. Alternative B confuses Azure Files with Azure Data Lake Storage Gen2. Alternative D is incorrect because the issue isn't insufficient RBAC role, but fundamental incompatibility between identity type and authentication method.
Answer Key — Question 5
Answer: B
This is the central architectural difference between the three methods. Microsoft Entra Kerberos represents an evolution where Entra ID itself acts as the Key Distribution Center (KDC), issuing Kerberos tickets without needing domain controllers. Meanwhile, on-premises AD DS and Microsoft Entra Domain Services depend on DCs (local or managed, respectively) for ticket issuance.
Alternative A is partially true regarding networking, but doesn't correctly describe an authentication behavior difference. Alternative C is false; NFS support in Azure Files is independent of identity source and isn't tied to AD DS. Alternative D is false; Microsoft Entra Domain Services supports NTFS permissions normally, operating equivalently to on-premises AD DS in this aspect.