Troubleshooting Lab: Configure identity-based access for Azure Files
Diagnostic Scenarios
Scenario 1 — Root Cause
A development team reported that after migrating an on-premises file server to Azure Files, users can mount the SMB share and list root directories, but receive the error "Access is denied" when trying to open any subdirectory or file.
The administrator verified the following before opening the ticket:
- On-premises AD DS authentication has been enabled on the storage account for two weeks
- The security group FS-Usuarios-Leitura has the Storage File Data SMB Share Reader role assigned at the share level
- Microsoft Entra Connect is synchronizing normally, with the last cycle completed 18 minutes ago
- The storage account has the firewall configured to allow the branch office network
The team also reports that the previous administrator migrated the data using robocopy with the /copyall flag from a Windows Server 2019 server.
Event observed on client when accessing subdirectory:
Status: 0xC0000022 - STATUS_ACCESS_DENIED
SMB dialect: SMB 3.0
Authentication: Kerberos
What is the root cause of the observed problem?
A) The storage account firewall is blocking SMB traffic from branch office clients
B) The Storage File Data SMB Share Reader role doesn't cover subdirectory access; the Storage File Data SMB Share Contributor role is required
C) The NTFS permissions copied by robocopy /copyall don't include the correct Entra ID/AD DS group, blocking access in subdirectories even with correct RBAC
D) Microsoft Entra Connect hasn't synchronized the groups in time and Azure Files doesn't yet recognize the user's membership in the FS-Usuarios-Leitura group
Scenario 2 — Action Decision
The cause of the problem has already been identified: the production storage account is configured with Microsoft Entra Kerberos as the identity source, but the clients that need to access the share are machines joined exclusively to on-premises AD DS, without hybrid join to Entra ID. Users are receiving authentication errors when trying to mount the share.
The environment has the following constraints:
- The share is in active production with approximately 200 users connected via other compatible clients (hybrid machines)
- Changing the storage account identity source requires disabling the current configuration and re-enabling with the new source, which forces remounting of all connected clients
- The scheduled maintenance window is in 6 days
- The support team has Contributor permission on the storage account, but doesn't have permission to modify RBAC role assignments on the share
What is the correct action to take at this moment?
A) Immediately change the identity source to on-premises AD DS, as the interruption will be brief and the 200 users will reconnect automatically
B) Hybrid join the problematic machines to Entra ID now, resolving the incompatibility without changing the storage account
C) Document the problem, communicate to stakeholders and execute the identity source change during the maintenance window in 6 days
D) Create a second storage account with on-premises AD DS configured and migrate the data before the maintenance window
Scenario 3 — Root Cause
A newly hired administrator configured Azure Files with on-premises AD DS authentication following the official documentation. The storage account registration process in AD DS was executed with the AzFilesHybrid script and completed without errors. The Storage File Data SMB Share Contributor role was assigned to the correct group.
When trying to mount the share from a domain machine, the user receives:
net use Z: \\storageaccount.file.core.windows.net\compartilhamento /persistent:yes
System error 5 has occurred.
Access is denied.
The administrator collected the following additional information:
- The
Get-AzStorageAccountADObjectcmdlet returns the object correctly in AD DS - The tenant has active Microsoft Entra ID P2 licenses for all users
- The storage account was created 3 days ago in the Brazil South region
- The
klistcommand on the client shows that the Kerberos ticket was successfully issued for the storage account - The storage account has no network restrictions configured
klist output (summarized):
Client: usuario@contoso.com
Server: cifs/storageaccount.file.core.windows.net@CONTOSO.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags: forwardable, renewable, pre-authent
What is the root cause of the observed problem?
A) The AzFilesHybrid script registered the object correctly, but synchronization with Microsoft Entra Connect hasn't yet propagated the identity to Entra ID
B) The Microsoft Entra ID P2 licenses are conflicting with the AD DS authentication flow, as they activate conditional access policies by default
C) The Kerberos ticket was successfully issued, indicating that authentication passed; the block is at the RBAC authorization layer, which hasn't been propagated to the storage account yet
D) The object registered in AD DS lost password synchronization with the storage account after creation; it's necessary to run Update-AzStorageAccountADObjectPassword
Scenario 4 — Diagnostic Sequence
A user reports being unable to access an Azure Files share configured with Microsoft Entra Kerberos authentication. The reported symptom is access denied error when trying to mount the share via SMB from a hybrid-joined machine.
The steps below represent valid diagnostic actions, but are out of order:
- Verify that the correct RBAC role is assigned to the user or group at the share level
- Confirm that Microsoft Entra Kerberos is enabled as the identity source on the storage account
- Run
kliston the client to verify if the Kerberos ticket was issued for the storage account - Check NTFS permissions at the directory and file level within the share
- Confirm that the user's device is hybrid-joined to Entra ID
What is the correct diagnostic sequence for this symptom?
A) 2 -> 5 -> 1 -> 3 -> 4
B) 5 -> 2 -> 3 -> 1 -> 4
C) 1 -> 2 -> 5 -> 4 -> 3
D) 3 -> 5 -> 2 -> 1 -> 4
Answer Key and Explanations
Answer Key — Scenario 1
Answer: C
The decisive clue is the combination of two facts: robocopy /copyall preserves all NTFS permissions from the source server, and users can list the root directory but cannot access subdirectories. This indicates that the RBAC layer is working (root listing is possible), but the NTFS permissions inherited from the old server don't include the domain groups or users in the way Azure Files recognizes them. Azure Files applies both layers and the most restrictive one prevails.
The information about the branch office firewall is irrelevant to the diagnosis: if the firewall were blocking, the user wouldn't be able to mount the share or list the root. Alternative D is a distractor based on Entra Connect synchronization timing, which is also irrelevant because the Kerberos authentication in this scenario is issued by the local AD DS, not by Entra ID. Alternative B represents a classic misunderstanding of the layers: the Reader role covers reading at any depth of the share; the block is not RBAC.
The most dangerous distractor is D. Acting on it would lead the administrator to wait for a new Entra Connect synchronization without solving the real problem, delaying the correct diagnosis.
Answer Key — Scenario 2
Answer: C
The critical constraint in the scenario is that there are 200 active users connected to the share. Changing the identity source forces remounting of all clients, causing immediate production disruption. The maintenance window exists precisely to absorb this type of impact.
Alternative A ignores the production impact constraint. Alternative B is technically valid as a long-term solution, but hybrid-joining 200 machines to Entra ID is a complex operation that cannot be executed without planning, especially outside a maintenance window. Alternative D introduces unnecessary complexity (data migration, new storage account) when the correct solution is simpler and already has a scheduled window.
The most dangerous distractor is A, as it presents the interruption as something trivial. In production, forcing 200 clients to remount without prior notice can cause loss of work in progress and SLA violations.
Answer Key — Scenario 3
Answer: D
The most important clue is the klist result: the Kerberos ticket was successfully issued for the storage account. This eliminates any authentication problem and points to the authorization layer or the AD object credential. The object registered in AD DS authenticates to Azure Files using a password that must be synchronized between AD and the storage account. This password has validity and may be outdated or never properly synchronized after registration.
Alternative C seems logical because an issued Kerberos ticket suggests successful authentication, but the error occurs before RBAC verification: the identity mapping between the AD object and the storage account fails when the password is out of sync. Alternative A is irrelevant to this scenario because on-premises AD DS doesn't depend on Entra Connect for local Kerberos ticket issuance. Alternative B is a distractor that exploits the purposely inserted irrelevant data (P2 licenses); licenses don't interfere with AD DS authentication flow to Azure Files.
The most dangerous distractor is C. Acting on it would lead the administrator to investigate and recreate RBAC assignments that are already correct, without ever solving the real problem.
Answer Key — Scenario 4
Answer: A
The correct sequence is: 2 -> 5 -> 1 -> 3 -> 4
The correct diagnostic reasoning goes from general to specific, from configuration level to session level:
- Step 2 first: confirming that Microsoft Entra Kerberos is enabled is the prerequisite for everything. If it's not enabled, no other step is necessary.
- Step 5 next: verifying that the device has valid hybrid join validates if the client is eligible for this authentication method.
- Step 1 after: with configuration and client validated, check RBAC on the share.
- Step 3 then: running
klistconfirms if the Kerberos ticket was actually issued, validating the authentication layer in the current session. - Step 4 last: NTFS permissions are the most granular layer and should only be investigated when all previous layers are correct.
Alternative D starts with klist, which is a session diagnosis; executing it before validating the storage account configuration and client eligibility generates information without context and can lead to wrong conclusions.
Troubleshooting Tree: Configure identity-based access for Azure Files
Color Legend:
| Color | Node Type |
|---|---|
| Dark Blue | Initial symptom (entry point) |
| Medium Blue | Diagnostic question |
| Red | Identified cause |
| Green | Recommended action or resolution |
| Orange | Intermediate validation or verification |
When facing a real problem, start with the root node that describes the observed symptom and answer each diagnostic question based on what you can verify directly in the environment: the Azure portal, the results of commands like klist and Get-AzStorageAccountADObject, and the state of RBAC assignments. Each branch eliminates a hypothesis and leads to the corresponding cause or action node, avoiding corrective actions applied before the diagnosis is complete.