Azure Files share prompting for credentials on specific machines but not others

Question

I have an Azure files share configured as in the images below. I map a drive to the share on client PCs via net use. It works well on many of our systems. For example, it works on all of my ~20 AVDs. However on many other systems, it fails to map drives with an error requesting a username and password. Ive tried manually entering the username and password when prompted but it always fails authentication. Ive tried: user@domain.com domain.com\user Even azuread\user@domain.com Nothing seems to work. I have DCs in all sites/subnets, including the vnet in Azure hosting my AVDs. No matter what I try, some systems will just not map the drive. I can't figure out what is different between the systems that work, and those that dont. Any ideas?

Answer 1

@Ryan P Welcome to Microsoft Q&A Forum, Thank you for posting your query here!

For better understanding the issue: Can you please share the screenshot of the error message?

Can you share the screenshot of the exact error message?
Please cross verify the the SMB version (SMB version compatibility) and verify DNS resolution(nslookup yourfileshare.file.core.windows.net) ?

Have you followed the steps mentioned in the perquisites .
Also have you updated the password? Update the password of your storage account identity in AD DS
It typically takes about 15 minutes for an Azure AD DS deployment to complete. Verify that the health status of Azure AD DS shows Running, with password hash synchronization enabled.

Azure Files supports identity-based authentication over Server Message Block (SMB) using three different methods: on-premises Active Directory Domain Services (AD DS), Azure Active Directory Domain Services (Azure AD DS), and Azure Active Directory (Azure AD) Kerberos for hybrid identities (preview). We strongly recommend that you review the How it works section to select the right AD source for authentication. The setup is different depending on the domain service you choose. This article focuses on enabling and configuring Azure AD DS for authentication with Azure file shares.

Overview of Azure Files identity-based authentication options for SMB access

Troubleshoot Azure Files identity-based authentication and authorization issues (SMB)

Try the below mentioned cmdlet

New-SmbMapping -LocalPath z: -RemotePath \\StorageAccountName.file.core.windows.net\sharename -UserName StorageAccountName -Password "AccountPassword"

This article will help in Mapping a Network Drive to an Azure File Share Using Domain Credentials

Additional information : Supported authentication scenarios

Azure Files supports identity-based authentication over SMB through the following methods. You can only use one method per storage account.

• On-premises AD DS authentication: On-premises AD DS-joined or Microsoft Entra Domain Services-joined Windows machines can access Azure file shares with on-premises Active Directory credentials that are synched to Microsoft Entra ID over SMB. Your client must have unimpeded network connectivity to your AD DS. If you already have AD DS set up on-premises or on a VM in Azure where your devices are domain-joined to your AD, you should use AD DS for Azure file shares authentication.
• Microsoft Entra Domain Services authentication: Cloud-based, Microsoft Entra Domain Services-joined Windows VMs can access Azure file shares with Microsoft Entra credentials. In this solution, Microsoft Entra ID runs a traditional Windows Server AD domain on behalf of the customer, which is a child of the customer’s Microsoft Entra tenant.
• Microsoft Entra Kerberos for hybrid identities: Using Microsoft Entra ID for authenticating hybrid user identities allows Microsoft Entra users to access Azure file shares using Kerberos authentication. This means your end users can access Azure file shares over the internet without requiring network connectivity to domain controllers from Microsoft Entra hybrid joined and Microsoft Entra joined VMs. Cloud-only identities aren't currently supported.
• AD Kerberos authentication for Linux clients: Linux clients can use Kerberos authentication over SMB for Azure Files using on-premises AD DS or Microsoft Entra Domain Services.

Restrictions

• None of the authentication methods support assigning share-level permissions to computer accounts (machine accounts) using Azure RBAC, because computer accounts can't be synced to an identity in Microsoft Entra ID. If you want to allow a computer account to access Azure file shares using identity-based authentication, use a default share-level permission or consider using a service logon account instead.
• Identity-based authentication isn't supported with Network File System (NFS) shares.

Refer to the below mentioned thread which provides some idea on your query

https://learn.microsoft.com/en-us/answers/questions/1321644/azure-files-mount-issue-system-error-86-or-user-na
https://learn.microsoft.com/en-us/answers/questions/1281149/mapping-azure-file-share-specified-network-passwor

Please let us know if you have any further queries. I’m happy to assist you further.  

---Please do not forget to "Accept the answer” and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Answer 2

@Ryan P I'm glad that you were able to resolve your issue and thank you for posting your solution so that others experiencing the same thing can easily reference this! Since the Microsoft Q&A community has a policy that "The question author cannot accept their own answer. They can only accept answers by others ", I'll repost your solution in case you'd like to "Accept " the answer.

Issue: Issues with mapping an Azure files share to client PCs using net use. While it works on some systems, others prompt for a username and password and fail authentication despite multiple attempts with different formats. The user has domain controllers in all sites/subnets, including the vnet hosting their AVDs.

Solution: It appears that the issue stemmed from the fact that the Active Directory (AD) Computer account utilized by the storage account was not located in a container that replicates to Entra. Does this explanation seem logical, and if it does, what is the rationale behind this requirement? This by design.

---

Please remember to "Accept Answer" if any answer/reply helped, so that others in the community facing similar issues can easily find the solution.

Answer 3

I created a new ticket as the problem is more clear now. I have posted it here:

https://learn.microsoft.com/en-us/answers/questions/1635469/intermittent-kerberos-failures-when-trying-to-acce