Fix Azure Files Authentication Issues: A Practical Guide to SMB Troubleshooting

Updated: 26 Jul, 2025 • 0 • min read

Table of Contents

Fix Azure Files Authentication Issues

This comprehensive guide addresses common challenges encountered when utilizing SMB Azure file shares with identity-based authentication. We will explore various issues, delve into their underlying causes, and provide practical resolutions to help you maintain seamless operations. Please note that identity-based authentication is not currently supported for NFS Azure file shares.

Understanding Identity-Based Authentication for Azure Files¶

Azure Files offers robust support for identity-based authentication, integrating seamlessly with both on-premises Active Directory Domain Services (AD DS) and Azure Active Directory Domain Services (Azure AD DS). This allows users to access file shares using their existing domain credentials, enhancing security and simplifying access management. However, misconfigurations or environmental factors can lead to authentication failures, which we will systematically troubleshoot in this guide.

Applies To¶

This troubleshooting guide primarily focuses on SMB file shares across various Azure Storage account types configured for identity-based authentication.

File Share Type	SMB	NFS
Standard file shares (GPv2), LRS/ZRS	✔️	❌
Standard file shares (GPv2), GRS/GZRS	✔️	❌
Premium file shares (FileStorage), LRS/ZRS	✔️	❌

Troubleshooting AzFilesHybrid Module Errors¶

The AzFilesHybrid PowerShell module is a critical tool for integrating Azure Files with Active Directory Domain Services. Errors during its execution often point to underlying permission issues within your Active Directory environment.

Error: “A required privilege is not held by the client.”¶

When attempting to run cmdlets from the AzFilesHybrid module, you might encounter the error message: “A required privilege is not held by the client.” This indicates that the user account executing the module lacks the necessary permissions within Active Directory.

Cause: Insufficient AD Permissions¶

This issue typically arises because the user account or service principal used to run the AzFilesHybrid module does not possess the elevated Active Directory permissions required for performing domain-joining operations or modifying AD objects. These operations demand specific administrative rights to ensure changes are made securely and correctly within the domain.

Solution¶

To resolve this, you must verify that the account has the appropriate Active Directory privileges. It is highly recommended to consult your Active Directory administrator to grant the necessary permissions. These typically include rights to create and manage computer objects or service principal names (SPNs) within the designated organizational unit (OU) for Azure Files integration.

Resolving SMB Mounting Issues¶

One of the most common issues users face is the inability to mount an Azure file share, often accompanied by specific error codes. Understanding these errors is the first step toward a successful resolution.

An “Access is denied” error, specifically System error 5, when attempting to mount an Azure file share signifies a permission-related problem. This error occurs after the initial connection to the file share is established, indicating that the client is authenticated but lacks the necessary authorizations to access the shared resource.

If end-users are attempting to access the Azure file share using Active Directory Domain Services (AD DS) or Microsoft Entra Domain Services authentication, this error frequently points to incorrectly configured share-level permissions. These permissions are distinct from NTFS file-level permissions and control who can even connect to the share itself. Without proper share-level access, users will be denied access regardless of their file-level permissions.

Solution¶

It is crucial to validate that share-level permissions are configured correctly for the users or groups attempting access.

For Active Directory Domain Services (AD DS): Ensure you have followed the guidance on Assign share-level permissions. It is important to confirm that the groups and users assigned share-level permissions are synchronized from AD DS to Microsoft Entra ID using Microsoft Entra Connect Sync or Microsoft Entra Connect cloud sync. “Cloud-only” groups are not supported for share-level permission assignments in this scenario.
For Microsoft Entra Domain Services: Refer to the instructions on Assign share-level permissions for Microsoft Entra Domain Services. Proper configuration here ensures that identities within your managed domain can correctly authenticate and gain initial access to the file share.

Troubleshooting Microsoft Entra Domain Services Authentication Issues¶

Enabling Microsoft Entra Domain Services authentication for Azure Files requires specific prerequisites within your Microsoft Entra tenant. Failure to meet these prerequisites can lead to configuration errors.

Error “AadDsTenantNotFound”: “Unable to locate active tenants with tenant ID Microsoft Entra tenant-id”¶

When trying to enable Microsoft Entra Domain Services authentication for Azure Files on a storage account, you might encounter the error “AadDsTenantNotFound”. This error specifically indicates a missing prerequisite within your Azure environment.

Cause¶

The “AadDsTenantNotFound” error occurs because Microsoft Entra Domain Services has not been provisioned or enabled on the Microsoft Entra tenant associated with the subscription where your storage account is deployed. Azure Files relies on an active Microsoft Entra Domain Services instance to provide the necessary domain controller functionality for authentication.

Solution¶

To rectify this, you must enable Microsoft Entra Domain Services on the Microsoft Entra tenant linked to the subscription where your storage account resides. This process typically requires administrator privileges within the Microsoft Entra tenant to create and configure a managed domain. If you are not the tenant administrator, coordinate with them to follow the step-by-step guidance for creating and configuring a Microsoft Entra Domain Services managed domain. Once enabled, allow sufficient time for the service to provision before attempting to enable authentication on your storage account again.

Resolving Inability to Mount Azure File Shares with AD Credentials¶

When users cannot mount Azure file shares using their Active Directory credentials, a systematic diagnostic approach is essential. This involves validating various components of your AD integration and client configuration.

Self-Diagnostics Steps¶

Verify AD DS Authentication Enablement: First and foremost, ensure that you have meticulously followed all steps to enable Azure Files AD DS Authentication on your storage account. A misstep in the initial setup can prevent any authentication attempts from succeeding.
Test with Storage Account Key: Attempt to mount the Azure file share using the storage account key instead of AD credentials. If the share fails to mount even with the storage account key, it suggests a more fundamental connectivity issue (e.g., firewall, network routing) rather than an authentication problem. For such cases, downloading and running AzFileDiagnostics can be highly beneficial. This tool helps identify incompatible client configurations, offers prescriptive guidance, and collects diagnostic traces for further analysis.
Utilize Debug-AzStorageAccountAuth: For in-depth AD configuration validation, the Debug-AzStorageAccountAuth cmdlet from AzFilesHybrid v0.1.2+ is invaluable. This cmdlet performs a series of checks against your AD configuration using the currently logged-on AD user.

To run the cmdlet:
- Sign in to Azure PowerShell interactively as an AD user holding owner permissions on the target storage account.
```
Connect-AzAccount
```
- Execute the Debug-AzStorageAccountAuth cmdlet, replacing placeholders with your resource group and storage account names.
```
$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"

Debug-AzStorageAccountAuth `
    -StorageAccountName $StorageAccountName `
    -ResourceGroupName $ResourceGroupName `
    -Verbose
```

This powerful cmdlet performs the following sequential checks, providing guidance for any detected failures:

CheckADObjectPasswordIsCorrect: Verifies that the password configured on the Active Directory identity representing the storage account matches the storage account’s kerb1 or kerb2 key. If a discrepancy is found, you can use Update-AzStorageAccountADObjectPassword to synchronize the password.
CheckADObject: Confirms the existence of an Active Directory object representing the storage account and ensures it has the correct Service Principal Name (SPN). An incorrectly set SPN will prevent Kerberos authentication. The debug cmdlet will suggest the Set-AD cmdlet to fix this.
CheckDomainJoined: Validates that the client machine attempting the mount is correctly joined to the Active Directory domain. Domain membership is a prerequisite for Kerberos authentication.
CheckPort445Connectivity: Assesses if port 445, essential for SMB connectivity, is open between the client and the Azure file share. Firewall rules or network security groups often block this port, leading to connectivity issues.
CheckSidHasAadUser: Determines if the security identifier (SID) of the logged-on AD user is synchronized to Microsoft Entra ID. This is crucial for share-level permission assignments that rely on Microsoft Entra identities. You can specify -UserName and -Domain to check a specific AD user.
CheckAadUserHasSid: Checks if a given Microsoft Entra user has an associated SID, confirming synchronization from AD. This check requires the -ObjectId parameter for the Microsoft Entra user.
CheckGetKerberosTicket: Attempts to obtain a Kerberos ticket required for connecting to the storage account. If ticket retrieval fails, examining the error code from klist get cifs/storage-account-name.file.core.windows.net can provide diagnostic clues.
CheckStorageAccountDomainJoined: Confirms that Active Directory authentication is enabled on the storage account and that its AD properties are correctly populated. If not, refer to instructions for enabling AD DS authentication.
CheckUserRbacAssignment: (Supported on AzFilesHybrid v0.2.3+) Verifies that the AD identity possesses the appropriate Azure Role-Based Access Control (RBAC) assignment for share-level permissions. Missing assignments necessitate configuring the share-level permission.
CheckUserFileAccess: (Supported on AzFilesHybrid v0.2.3+) Checks if the AD identity has the necessary directory/file permissions (Windows ACLs) within the file share. This check requires the -FilePath parameter, specifying the path to the file or directory you’re debugging access to.
CheckKerberosTicketEncryption: (Supported on AzFilesHybrid v0.2.5+) Confirms that the storage account is configured to accept the encryption type utilized by the Kerberos ticket. Misconfiguration here can prevent successful authentication.
CheckChannelEncryption: (Supported on AzFilesHybrid v0.2.5+) Assesses if the storage account is configured to accept the SMB channel encryption type employed by the client.
CheckDomainLineOfSight: (Supported on AzFilesHybrid v0.2.5+) Verifies that the client machine has unimpeded network connectivity to the domain controller. DNS resolution and network path issues can lead to authentication failures.
CheckDefaultSharePermission: (Supported on AzFilesHybrid v0.2.5+) Checks if the default share-level permission for all authenticated identities is configured. This can be a quick way to grant broad access.
CheckAadKerberosRegistryKeyIsOff: (Supported on AzFilesHybrid v0.2.9+) Confirms that the Microsoft Entra Kerberos registry key is disabled. If enabled, it needs to be turned off by running reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 0 from an elevated command prompt, followed by a machine reboot.

You can also filter the checks to run a subselection. For instance, to specifically examine share-level RBAC permissions:

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"

Debug-AzStorageAccountAuth `
    -Filter CheckSidHasAadUser,CheckUserRbacAssignment `
    -StorageAccountName $StorageAccountName `
    -ResourceGroupName $ResourceGroupName `
    -Verbose

Or to debug file-level permissions for a mounted share:

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"
$FilePath = "X:\example.txt" # Assuming share is mounted as X:

Debug-AzStorageAccountAuth `
    -Filter CheckUserFileAccess `
    -StorageAccountName $StorageAccountName `
    -ResourceGroupName $ResourceGroupName `
    -FilePath $FilePath `
    -Verbose

Resolving Inability to Mount Azure File Shares with Microsoft Entra Kerberos¶

Microsoft Entra Kerberos authentication enables hybrid users to access Azure file shares without requiring line-of-sight to a traditional domain controller. However, specific configurations are necessary for this to function correctly.

Self-Diagnostics Steps¶

Verify Microsoft Entra Kerberos Enablement: Begin by ensuring that you have meticulously followed the steps to enable Microsoft Entra Kerberos authentication for your storage account. This includes proper setup of the Azure AD application.
Utilize Debug-AzStorageAccountAuth for Microsoft Entra Kerberos: The Debug-AzStorageAccountAuth cmdlet, available in AzFilesHybrid v0.3.0+, also supports diagnostics for storage accounts configured with Microsoft Entra Kerberos authentication.

To run the cmdlet:
- Sign in to Azure PowerShell interactively as an AD user who has owner permission on the target storage account.
```
Connect-AzAccount
```
- Execute the Debug-AzStorageAccountAuth cmdlet:
```
$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"

Debug-AzStorageAccountAuth -StorageAccountName $StorageAccountName -ResourceGroupName $ResourceGroupName -Verbose
```

This cmdlet performs a sequence of checks tailored for Microsoft Entra Kerberos:

CheckPort445Connectivity: Ensures that port 445 is open for SMB communication. As with AD DS authentication, this is a fundamental requirement.
CheckAADConnectivity: Verifies connectivity to Microsoft Entra ID. SMB mounts with Kerberos authentication depend on the client’s ability to reach Microsoft Entra ID. A failure here often indicates a network issue, such as firewall restrictions or VPN configuration problems.
CheckEntraObject: Confirms the existence and correct configuration of the service principal name (SPN) for the storage account within Microsoft Entra ID. An improperly configured SPN may necessitate disabling and re-enabling Microsoft Entra Kerberos authentication.
CheckRegKey: Validates that the CloudKerberosTicketRetrieval registry key, which is crucial for Microsoft Entra Kerberos authentication, is correctly enabled on the client machine.
CheckRealmMap: Checks if the user has configured any realm mappings that would attempt to join the account to a Kerberos realm other than KERBEROS.MICROSOFTONLINE.COM. Such mappings can interfere with Microsoft Entra Kerberos.
CheckAdminConsent: Ensures that the Microsoft Entra service principal has been granted admin consent for the Microsoft Graph permissions necessary to retrieve Kerberos tickets. Without this consent, the authentication flow cannot complete.
CheckWinHttpAutoProxySvc: Verifies the status of the WinHTTP Web Proxy Auto-Discovery Service (WinHttpAutoProxySvc), which must be running for Microsoft Entra Kerberos authentication.
CheckIpHlpScv: Checks the status of the IP Helper service (iphlpsvc), another prerequisite service that must be running.
CheckFiddlerProxy: Detects if a Fiddler proxy is active, as it can interfere with or prevent Microsoft Entra Kerberos authentication.
CheckEntraJoinType: Confirms that the client machine is either Microsoft Entra domain joined or hybrid Microsoft Entra domain joined. This is a fundamental prerequisite for Microsoft Entra Kerberos.

Similar to the AD DS diagnostics, you can use the -Filter parameter to run a specific subset of these checks.

Issues with Windows ACLs Configuration via File Explorer¶

Configuring directory and file-level permissions (Windows ACLs) is a critical step for granular access control. However, Windows File Explorer may present challenges in certain scenarios.

Symptom¶

You might encounter the following symptoms when attempting to configure Windows ACLs using File Explorer on a mounted file share:

Upon clicking Edit permission under the Security tab, the Permission wizard fails to load or appears unresponsive.
When attempting to select a new user or group, the domain location displayed in the picker is incorrect or does not show the intended Active Directory Domain Services (AD DS) domain.
In environments with multiple AD forests, you might receive the error message: “The Active Directory domain controllers required to find the selected objects in the following domains are not available. Ensure the Active Directory domain controllers are available, and try to select the objects again.”

Solution¶

Due to these potential issues with File Explorer, it is generally recommended to configure directory/file level permissions using icacls instead. The icacls command-line utility provides a reliable and robust method for managing Windows ACLs, bypassing the graphical interface limitations that might occur.

Displaying UserPrincipalName (UPN) in File Explorer¶

File Explorer sometimes presents Security Identifiers (SIDs) instead of more user-friendly UserPrincipalNames (UPNs) for file or directory owners.

Symptom¶

File Explorer displays the security identifier (SID) of a file or directory owner rather than their corresponding UserPrincipalName (UPN). This can make it difficult to quickly identify the owner of a resource, particularly in environments with many users.

Cause¶

This behavior occurs because File Explorer attempts to call a Remote Procedure Call (RPC) API directly to the server (Azure Files) to translate the SID into a UPN. Unfortunately, Azure Files does not support this specific RPC API for SID-to-UPN translation directly from the file share. Consequently, the UPN cannot be displayed by File Explorer.

Solution¶

On a domain-joined client, you can use the following PowerShell command to view all items within a directory along with their owners, including their UPNs, providing the clarity that File Explorer lacks:

Get-ChildItem <Path> | Get-ACL | Select Path, Owner

Replace <Path> with the actual path to your mounted Azure file share or a specific directory within it.

Addressing Errors with `Join-AzStorageAccountForAuth` Cmdlet¶

The Join-AzStorageAccountForAuth cmdlet is essential for integrating your storage account with Active Directory Domain Services for authentication. Errors during its execution can indicate underlying issues with your AD infrastructure or command syntax.

Error: “The directory service was unable to allocate a relative identifier”¶

This specific error message during the execution of Join-AzStorageAccountForAuth is highly indicative of a problem within your Active Directory environment related to the Relative ID (RID) Master FSMO role.

Cause¶

This error typically occurs if a domain controller holding the RID Master Flexible Single Master Operations (FSMO) role is unavailable, offline, or was improperly restored from a backup without proper synchronization. The RID Master is responsible for allocating unique security identifiers (SIDs) to new objects created in the domain. If it cannot perform this function, new objects (like the storage account’s computer object) cannot be created.

Solution¶

To resolve this, you must confirm that all Domain Controllers within your environment are running, available, and functioning correctly. Specifically, ensure the domain controller holding the RID Master FSMO role is online and healthy. If the role holder experienced an issue, you might need to perform FSMO role transfer or seizure procedures as per Active Directory best practices.

Error: “Cannot bind positional parameters because no names were given”¶

This error suggests a problem with how the Join-AzStorageAccountForAuth command is being executed.

Cause¶

This error is most likely triggered by a syntax error within the Join-AzStorageAccountForAuth command itself. It can also occur if an outdated version of the AzFilesHybrid module is being used, which might not correctly interpret the supplied parameters or might lack support for the specific command syntax you are using.

Solution¶

Carefully review the command for any misspellings or syntax errors. Ensure that all parameters are correctly named and positioned. Additionally, verify that the latest version of the AzFilesHybrid module is installed. You can download the most recent version from the official GitHub releases page. Updating the module often resolves compatibility issues with newer Azure PowerShell versions or Azure Files features.

Enhancing Security with AES-256 Kerberos Encryption¶

Azure Files continually improves its security posture. The adoption of AES-256 Kerberos encryption for on-premises AD DS authentication significantly enhances the security of your file share access.

Azure Files on-premises AD DS Authentication Support for AES-256 Kerberos Encryption¶

Azure Files now supports AES-256 Kerberos encryption for AD DS authentication, starting with the AzFilesHybrid module v0.2.2. AES-256 is the recommended encryption method due to its stronger security, and it has been set as the default encryption method since AzFilesHybrid module v0.2.5. If you initially enabled AD DS authentication using an older module version (lower than v0.2.2), an update is necessary to leverage this improved encryption standard.

To update and enable AES-256 encryption, follow these steps:

Download the latest AzFilesHybrid module from its official releases page.
Execute the following PowerShell script, replacing the placeholders with your resource group and storage account names.
```
$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"

Update-AzStorageAccountAuthForAES256 -ResourceGroupName $ResourceGroupName -StorageAccountName $StorageAccountName
```
This cmdlet will rotate the Kerberos keys for your storage account, which is a necessary step to transition to AES-256 encryption. This key rotation does not require you to regenerate both passwords unless you explicitly wish to do so.

Managing Storage Account Key Access After Role Changes¶

Understanding how role assignments interact with storage account keys is crucial for maintaining a strong security posture. Even after a user’s role is removed, they might retain access if keys are not properly managed.

User Identity Formerly Having the Owner or Contributor Role Assignment Still Has Storage Account Key Access¶

The Owner and Contributor roles for a storage account grant the ability to list the storage account keys. These keys provide full, unauthenticated access to all data within the storage account, including file shares, blobs, tables, and queues. Furthermore, they offer limited access to Azure Files management operations through legacy management APIs. If you modify role assignments and remove users from Owner or Contributor roles, they might still retain access if they previously acquired and saved these storage account keys.

Solution 1: Rotate Storage Account Keys¶

To mitigate this security risk, you can easily remedy the situation by rotating the storage account keys. It is best practice to rotate the keys one at a time, allowing for a gradual transition of access from the old key to the new one. Azure storage accounts provide two types of shared keys:

Storage Account Keys: These are the primary keys that offer super-administrator level access to all data within the storage account. Rotating these invalidates any previously acquired keys.
Kerberos Keys: These function as a shared secret specifically for Windows Server Active Directory scenarios, enabling Kerberos authentication between the storage account and the domain controller.

To specifically rotate the Kerberos keys of a storage account (relevant for AD DS authentication), refer to the instructions on Update the password of your storage account identity in AD DS. This action ensures that any cached or saved Kerberos keys become invalid.

Configuring API Permissions for New Applications¶

After enabling Microsoft Entra Kerberos authentication, an Azure AD application is registered in your tenant. Granting admin consent to this application is a crucial post-configuration step to ensure it has the necessary permissions to function.

Set the API Permissions on a Newly Created Application¶

Once Microsoft Entra Kerberos authentication is enabled, you must explicitly grant admin consent to the newly registered Microsoft Entra application within your tenant to finalize the configuration. This consent allows the application to access Microsoft Graph permissions required for Kerberos ticket retrieval.

You can configure these API permissions through the Azure portal by following these steps:

Navigate to Microsoft Entra ID in the Azure portal.
From the left pane, select App registrations.
In the right pane, choose All Applications.
Locate and select the application whose name matches [Storage Account] $storageAccountName.file.core.windows.net.
In the left pane, select API permissions.
At the bottom of the page, select Add permissions.
Finally, select Grant admin consent for “DirectoryName” (your Microsoft Entra tenant name) to apply the permissions.

Potential Errors When Enabling Microsoft Entra Kerberos Authentication for Hybrid Users¶

Enabling Microsoft Entra Kerberos authentication for hybrid user accounts can sometimes lead to specific errors related to Microsoft Entra ID policies and application management.

In certain organizational settings, Microsoft Entra administrators may disable the ability for users (even those with sufficient permissions) to grant admin consent to Microsoft Entra applications directly. This is a security measure to centralize control over application permissions.

Symptom¶

You might encounter a scenario where the option to “Grant admin consent” is greyed out or inaccessible within the Azure portal, similar to the following conceptual image:

mermaid graph TD A[User attempts to Grant Admin Consent] --> B{Is Grant Consent Disabled by Policy?}; B -- Yes --> C[Option is greyed out/inaccessible]; B -- No --> D[Consent granted successfully]; C --> E[Contact Microsoft Entra Admin];

Cause¶

This behavior is a result of a Microsoft Entra tenant-wide policy that restricts who can grant consent to applications.

Solution¶

If you face this issue, you must contact your Microsoft Entra administrator. They have the necessary permissions to grant admin consent to the new Microsoft Entra application on your behalf. To identify your administrators, you can typically navigate to Microsoft Entra ID > Roles and administrators, then look for roles like Cloud application administrator or Global Administrator.

Error - “The request to Azure AD Graph failed with code BadRequest”¶

This error can indicate issues with application management policies or existing applications.

Cause 1: Application Management Policy Preventing Credentials from Being Created¶

You might encounter this specific BadRequest error if the following conditions are met:

Your organization is utilizing the beta or preview feature of application management policies.
A tenant-wide policy has been configured (by you or an administrator) with:
- No start date, or a start date prior to January 1, 2019.
- A restriction on service principal passwords, either disallowing custom passwords entirely or setting a maximum password lifetime of less than 365.5 days.

Currently, there is no direct workaround for this specific combination of policy settings that prevents the creation of credentials required for Microsoft Entra Kerberos. Reviewing and potentially adjusting these policies with your Microsoft Entra administrator may be necessary.

Cause 2: An Application Already Exists for the Storage Account¶

Another reason for this BadRequest error is if you had previously enabled Microsoft Entra Kerberos authentication through older, manual limited preview steps. These steps might have left a stale application registration that conflicts with the newer, automated process.

Solution¶

To resolve this, you need to delete the existing, manually created application. This allows the new experience to automatically create and manage a fresh application. The following PowerShell script can be executed by the customer or their IT administrator:

$storageAccount = "exampleStorageAccountName" # Replace with your storage account name
$tenantId = "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee" # Replace with your Microsoft Entra tenant ID
Install-Module Microsoft.Graph
Import-Module Microsoft.Graph
Connect-MgGraph -TenantId $tenantId -Scopes "User.Read","Application.Read.All"

$application = Get-MgApplication -Filter "DisplayName eq '${storageAccount}'"
if ($null -ne $application) {
   Remove-MgApplication -ObjectId $application.ObjectId
}

After initiating the connection to Microsoft Graph (Connect-MgGraph), ensure you sign in to the Microsoft Graph Command Line Tools application on your device and grant the necessary permissions to the app when prompted.

Error - Service Principal Password has Expired in Microsoft Entra ID¶

If you previously configured Microsoft Entra Kerberos authentication using the older, manual limited preview steps, the password for the storage account’s service principal was set to expire approximately every six months. Once this password expires, users will be unable to obtain Kerberos tickets to access the file share, leading to access failures.

Solution¶

To mitigate this, you have two primary options:

Rotate the service principal password: Manually rotate the service principal password in Microsoft Entra ID every six months. This requires proactive management.
Disable and Reconfigure Microsoft Entra Kerberos: A more permanent solution is to disable Microsoft Entra Kerberos, delete the old application, and then reconfigure it using the current, automated method. This ensures the new experience manages the application’s credentials.

Before disabling Microsoft Entra Kerberos, it is crucial to save the domain properties (specifically domainName and domainGUID). You will need these during reconfiguration if you intend to continue configuring directory and file-level permissions using Windows File Explorer. If you forget to save these properties, you can still configure directory/file-level permissions using icacls as a workaround.

Follow these steps:

Disable Microsoft Entra Kerberos on your storage account.
Delete the existing application using the PowerShell script provided above in “Cause 2: An application already exists for the storage account.”
Reconfigure Microsoft Entra Kerberos via the Azure portal using the latest process.

Once reconfigured, the new experience will automatically create and manage the application, including its credential rotation, alleviating the manual expiration issue.

Error 1326 - The username or password is incorrect when using private link¶

When attempting to mount a file share via net use or other methods while connecting to a storage account through a private endpoint/private link using Microsoft Entra Kerberos authentication, the client might be prompted for credentials, and upon entering them, the credentials are rejected.

Cause¶

This issue typically arises because the SMB client attempts to use Kerberos but fails. It then falls back to NTLM authentication, which Azure Files does not support for domain credentials in this scenario. The primary reason Kerberos fails is that the private link FQDN (Fully Qualified Domain Name) is not registered with the existing Microsoft Entra application for your storage account. Kerberos requires the SPN (which is derived from the FQDN) to be correctly registered for ticket acquisition.

Solution¶

The solution involves adding the private link FQDN to your storage account’s Microsoft Entra application before attempting to mount the file share. This ensures that the Kerberos authentication process can correctly resolve and acquire a ticket for the private link endpoint.

You can add the required identifierUris to the application object using the Azure portal:

Open Microsoft Entra ID in the Azure portal.
From the left pane, select App registrations.
Select All Applications.
Find and select the application named [Storage Account] $storageAccountName.file.core.windows.net.
In the left pane, select Manifest.
Important: Copy and paste the existing content of the manifest to a safe place (e.g., a text editor) as a backup before making any changes.

Edit the json manifest. For every identifierUris entry that contains <storageAccount>.file.core.windows.net, add a corresponding entry with <storageAccount>.privatelink.file.core.windows.net.

Example: If your current identifierUris look like this:

"identifierUris": [
    "api://<tenantId>/HOST/<storageaccount>.file.core.windows.net",
    "api://<tenantId>/CIFS/<storageaccount>.file.core.windows.net",
    "api://<tenantId>/HTTP/<storageaccount>.file.core.windows.net",
    "HOST/<storageaccount>.file.core.windows.net",
    "CIFS/<storageaccount>.file.core.windows.net",
    "HTTP/<storageaccount>.file.core.windows.net"
],

You should modify the identifierUris field to include the private link entries:

"identifierUris": [
    "api://<tenantId>/HOST/<storageaccount>.file.core.windows.net",
    "api://<tenantId>/CIFS/<storageaccount>.file.core.windows.net",
    "api://<tenantId>/HTTP/<storageaccount>.file.core.windows.net",
    "HOST/<storageaccount>.file.core.windows.net",
    "CIFS/<storageaccount>.file.core.windows.net",
    "HTTP/<storageaccount>.file.windows.net",

    "api://<tenantId>/HOST/<storageaccount>.privatelink.file.core.windows.net",
    "api://<tenantId>/CIFS/<storageaccount>.privatelink.file.core.windows.net",
    "api://<tenantId>/HTTP/<storageaccount>.privatelink.file.core.windows.net",
    "HOST/<storageaccount>.privatelink.file.core.windows.net",
    "CIFS/<storageaccount>.privatelink.file.core.windows.net",
    "HTTP/<storageaccount>.privatelink.file.core.windows.net"
],

8. Review the content carefully for syntax errors and select Save to update the application object.
9. Update any internal DNS references (e.g., in your private DNS zone) to point to the private link’s IP address.
10. Retry mounting the file share.

Error AADSTS50105¶

When attempting to obtain a Kerberos ticket for an Azure file share, you might encounter the error AADSTS50105. The accompanying message typically indicates:

“Your administrator has configured the application ‘Enterprise application name’ to block users unless they are specifically granted (assigned) access to the application. The signed in user ‘{EmailHidden}’ is blocked because they are not a direct member of a group with access, nor had access directly assigned by an administrator. Please contact your administrator to assign access to this application.”

Cause¶

This error occurs if the “Assignment required” setting is enabled for the corresponding enterprise application in Microsoft Entra ID. While this setting typically restricts access to applications to only assigned users or groups, Azure Files does not populate entitlements (user assignments) within the Kerberos ticket that is returned to the requestor for this specific authentication flow. Therefore, even if a user or group is assigned to the application, the Kerberos ticket does not reflect this assignment, leading to rejection.

Solution¶

To resolve this, you must not select the Assignment required option for the Microsoft Entra application associated with your storage account. This setting should be disabled for the Azure Files Kerberos authentication scenario to allow successful ticket acquisition. Refer to the Microsoft Entra documentation on Error AADSTS50105 - The signed in user is not assigned to a role for the application for more details on this error and its implications.

We hope this practical guide has helped you resolve common Azure Files SMB authentication issues. If you have any further questions or encounter new challenges, please feel free to leave a comment below or reach out to Azure support for assistance. Your feedback helps us improve!¶

Fix Azure Files Authentication Issues: A Practical Guide to SMB Troubleshooting

Understanding Identity-Based Authentication for Azure Files¶

Applies To¶

Troubleshooting AzFilesHybrid Module Errors¶

Error: “A required privilege is not held by the client.”¶

Cause: Insufficient AD Permissions¶

Solution¶

Resolving SMB Mounting Issues¶

Error 5: “Access is denied” when Mounting an Azure File Share¶

Cause: Incorrect Share-Level Permissions¶

Solution¶

Troubleshooting Microsoft Entra Domain Services Authentication Issues¶

Error “AadDsTenantNotFound”: “Unable to locate active tenants with tenant ID Microsoft Entra tenant-id”¶

Cause¶

Solution¶

Resolving Inability to Mount Azure File Shares with AD Credentials¶

Self-Diagnostics Steps¶

Resolving Inability to Mount Azure File Shares with Microsoft Entra Kerberos¶

Self-Diagnostics Steps¶

Issues with Windows ACLs Configuration via File Explorer¶

Symptom¶

Solution¶

Displaying UserPrincipalName (UPN) in File Explorer¶

Symptom¶

Cause¶

Solution¶

Addressing Errors with Join-AzStorageAccountForAuth Cmdlet¶

Error: “The directory service was unable to allocate a relative identifier”¶

Cause¶

Solution¶

Error: “Cannot bind positional parameters because no names were given”¶

Cause¶

Solution¶

Enhancing Security with AES-256 Kerberos Encryption¶

Azure Files on-premises AD DS Authentication Support for AES-256 Kerberos Encryption¶

Managing Storage Account Key Access After Role Changes¶

User Identity Formerly Having the Owner or Contributor Role Assignment Still Has Storage Account Key Access¶

Solution 1: Rotate Storage Account Keys¶

Configuring API Permissions for New Applications¶

Set the API Permissions on a Newly Created Application¶

Potential Errors When Enabling Microsoft Entra Kerberos Authentication for Hybrid Users¶

Error - Grant Admin Consent Disabled¶

Symptom¶

Cause¶

Solution¶

Error - “The request to Azure AD Graph failed with code BadRequest”¶

Cause 1: Application Management Policy Preventing Credentials from Being Created¶

Cause 2: An Application Already Exists for the Storage Account¶

Solution¶

Error - Service Principal Password has Expired in Microsoft Entra ID¶

Solution¶

Error 1326 - The username or password is incorrect when using private link¶

Cause¶

Solution¶

Error AADSTS50105¶

Cause¶

Solution¶

We hope this practical guide has helped you resolve common Azure Files SMB authentication issues. If you have any further questions or encounter new challenges, please feel free to leave a comment below or reach out to Azure support for assistance. Your feedback helps us improve!¶

Post a Comment

Addressing Errors with `Join-AzStorageAccountForAuth` Cmdlet¶