Mapping drive letter to Azure Files - Network password is not correct

Question

I've created a new managed domain in Entra Domain Services and configured a one-way trust between my on-prem AD and the new managed domain. I tested this by creating a VM in the managed domain and successfully logged into it using my on-premise admin account.

I then created a storage account and a couple of shares, enabling identity-based access using the managed domain trust. Via Access Control I'm able to see I'm an Owner.

The thing I'm running into is that on one machine I can map the network drive, but on another machine I can't. The only difference I can think of is that on my desktop I'd initially mapped the network drive using a Storage Access Key and the PowerShell script prior to setting up the managed domain. I have rebooted the machine since then, but I have no issues mapping the drive just using the "net use" command.

On the laptop it consistently tells me that my network password is incorrect. Since I'd originally used the PowerShell script on my desktop, I decided to try that on the laptop. I reran the PowerShell script using the key and it mapped successfully. After deleting the mapping I can run net use fine without an issue, so I presume it's just using the key from before.

I'm not sure what I need to look at here. My ultimate goal is to just be able to map a network drive via login script for users as we transition their data from an on-premise file share to an Azure file share.

Answer 1

Presumably you're referring to Entra Kerberos authentication - as described in https://learn.microsoft.com/en-us/azure/storage/files/storage-files-identity-auth-hybrid-identities-enable?tabs=azure-portal%2Cintune

If so, this should not rely on the storage account key at all (you should remove it from the Credentials Manager on the computer you are creating a drive mapping from to verify this in a reliable manner). The user accounts must be hybrid. For additional prerequisites, refer to the Microsoft Learn article referenced above

---

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

Answer 2

Hello Joe,

Are both machines joined to the new managed domain?

Where are those machines deployed at? (Azure?)

Are you using private endpoint for Azure Files?

Have you looked into the Credential Manager to see under Windows Credentials if the Storage Access Key is stored there?

When doing using net use to map to the share are you using DOMAINNAME\username where the DOMAINNAME is the Entra Domain Services as noted: https://learn.microsoft.com/en-us/azure/storage/files/storage-files-identity-mount-file-share#mount-the-file-share-from-a-non-domain-joined-vm-or-a-vm-joined-to-a-different-ad-domain

Have you tried running the running the Az File Diagnostics: https://github.com/Azure-Samples/azure-files-samples/tree/master/AzFileDiagnostics/Windows

Answer 3

Well, I'm wondering if this is the issue:

It shows the default share-level permissions are Disabled. However, I'm unable to turn them on. If I go in and set something:

I get the following error when clicking Save:

I had the same issue when I tried enabling Microsoft Entra Domain Services. I found a post elsewhere that showed the Azure PowerShell script to run to enable EDS on the storage account, so I was able to get around it.

I can't find an answer for this one, though. I used the Co-Pilot assistance and it provided the following script to use:

az storage account update --name myfileshare --resource-group FileShares --set api-version=2023-01-01

The script fails however, saying that the resource group 'FileShares' could not be found, but that is the resource group name.

I even tried removing the resource group from the command, at which point it says that storage account myfileshare isn't found.

EDIT It apparently isn't the only issue, as I created a new storage account/file share and it allowed me to enable the Default share-level permissions, but I still have the same problem. :/

Answer 4

After further testing, I can get this to work, however:

• I need to reset the password of the account in my AD/Entra domain. I presume this forces the hash sync to the managed domain. This isn't the end of the world, as we could force all users to change their passwords before implementing Azure File Shares.
• The larger issue is that it is still requiring me to enter credentials. For example, I had to enter my credentials as either username@manageddomain.com or manageddomain\username. I could not connect using my logged-in credentials of onpremdomain\username.

My expectation was that the entire point of using the Entra Domain Services w/ trust relationship was so users could use their existing accounts. Maybe I was mistaken?

The scenario I'm looking to accomplish is this:

• Have Azure File Shares set up that are using security based on our on-prem/Entra ID synced user accounts and groups (all user accounts are hybrid, but we will likely have some groups that are cloud-only as we deploy more shares).
• Have users connect to these shares using their existing login scripts (to start), eventually moving to GPO to map the drives for them.
• Not require the users to enter credentials to connect to the drives.

Answer 5

Hi @Joe Grover

To connect to Azure File Shares using existing on-premises or Entra ID accounts without requiring users to enter credentials, you need to ensure that the accounts are properly synchronized and configured. Here are few suggestions to follow.

1. Password Hash Synchronization: Resetting the password of the account in your AD/Entra domain does indeed force the password hash to sync with the managed domain. This is necessary for users to authenticate without issues.
2. Credential Format: When connecting to Azure File Shares, users may need to provide their credentials in the format of either username@manageddomain.com or manageddomain\username. If they cannot connect using their logged-in credentials from the on-premises domain, it suggests that the trust relationship or synchronization may not be fully functioning as expected.
3. GPO and Login Scripts: You can set up Azure File Shares to use security based on your on-premises/Entra ID synced user accounts and groups. Users can connect using existing login scripts initially, and later you can implement Group Policy Objects (GPO) to map the drives automatically.
4. Trust Relationship: The expectation that users can use their existing accounts is valid, but it requires proper configuration of the trust relationship and synchronization settings. Ensure that your Azure File Shares are associated with the same Microsoft Entra tenant as your managed domain.
5. Permissions: Make sure that the necessary permissions are assigned to users who need to access the shares, including Azure role-based access control (RBAC) roles and NTFS permissions.

By following the above steps, you can solve your issue. Please follow the below Microsoft documentations for more information
https://learn.microsoft.com/en-us/azure/storage/files/storage-files-faq#security-authentication-and-access-control
https://learn.microsoft.com/en-us/azure/virtual-desktop/troubleshoot-authorization#troubleshoot-azure-files-authentication-with-active-directory
https://learn.microsoft.com/en-us/entra/identity/domain-services/troubleshoot-sign-in#domain-services-doesnt-have-the-password-hashes

Please feel free to contact if the issue persists, we will be glad to assist you closely.

---

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.