Azure Files with ADDS Authentication - Can't connect from most on-premise devices

Daan Poleij 11 Reputation points

Hi all,

We have been in a POC for Azure Files with ADDS authentication for a while, yet I still come across a lot of errors where I can't seem to get a hold of.

The environment is as follows.

3x DC (2x On-premise, 1x Azure)
Storage account with a file share
Private DNS Zone with a Private Endpoint
Site to Site VPN between on-premise and Azure
AD Connect configured
Storage account AD Domain joined

Edited DNS configurations as follows,
Added as a new Forward Lookup zone, with a A record inside which refers to the Private IP of the private endpoint associated with the share.
For the on-premises DNS servers a Conditional forwarder of "", with the private ip address of the DC thats located in Azure.
For the Azure DNS server a conditional forwarder of "", with the Azure Private DNS address, ""

The traffic seems to flow over the vpn, and other data is correctly being pushed through. But it isn't possible to mount the File share except for one server, that is the secondary DC that is located on-premise.

The subnet that resides in Azure starts with 10.192.x.x
The subnet that resides on-premise is 192.168.x.x

From the DC in Azure I can connect to the share, which seems logical because they are in the same subnet.
From 1 DC on-premise I can connect to the share, from the other DC on-premise I get the error "The specified network password is not correct" while I used the same credentials for the other DC's.

Anyone able to point me out in the right direction to fix this or maybe came across this issue while configuring the Azure Files solution? Would love to hear from you guys, thanks in advance.

Azure Files
Azure Files
An Azure service that offers file shares in the cloud.
1,043 questions
Azure Storage Accounts
Azure Storage Accounts
Globally unique resources that provide access to data management services and serve as the parent namespace for the services.
2,297 questions
0 comments No comments
{count} vote

5 answers

Sort by: Most helpful
  1. Daan Poleij 11 Reputation points

    No problem at all!

    "Also make sure you have the proper role assigned to the 1 DC."

    What do you actually mean with this question? There isn't a specific role I have to assign to a DC right? If this is about the Storage RBAC permissions, these have already been assigned.

    The resolving also works as it should. When doing nslookup for the following it correctly returns an private ip,
    nslookup "storageaccount"

    The networking part seems to be correctly setup if I am correct.

    1 person found this answer helpful.
    0 comments No comments

  2. Sumarigo-MSFT 40,716 Reputation points Microsoft Employee

    @Daan Poleij Firstly, apologies for the delay in responding here and any inconvenience this issue may have caused.

    Azure Files supports identity-based authentication over Server Message Block (SMB) through two types of Domain Services: on-premises Active Directory Domain Services (AD DS) and Azure Active Directory Domain Services (Azure AD DS). We strongly recommend you to review the How it works section to select the right domain service for authentication. The setup is different depending on the domain service you choose. These series of articles focus on enabling and configuring on-premises AD DS for authentication with Azure file shares:

    Also make sure you have the proper role assigned to the 1 DC.

    Enable Azure Active Directory Domain Services authentication on Azure Files

    After re-verify the pre-requites, permission and following the above article, If you are still facing the same issue, I would love to work closer on this issue you can reach me via AZCommunity[AT] with a link to this Issue as well as your subscription ID and we can help get a support ticket opened for this issue. Please mention "ATTN subm" in the subject field. We would like to work closer with you on this matter.

    Additional information: We managed to make this work by following the documentation below:

    Tip: you have to make the * resolve for the AD authentication to work

    Thank you for your patience and co-operation! Looking forward for your reply!

    Kindly let us know if the above helps or you need further assistance on this issue.


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

    0 comments No comments

  3. cjm888 1 Reputation point


    Did you resolve this issue as I am experiencing similar issue ?

    I can connect to the Azure file share from on premise via the internet "storageaccount" but when i try via the privatelink I am prompted and cant connect.

    I followed a couple of user guides and I can't see why its failing.

    Running the Test-Netconnection command returns the correct details.

    I haven't got a DC in the Azure Vnet just on prem DC's I have a lookup zone and conditional forwards setup on my on prem DC's.

    The issue is on both on prem clients and azure vnet clients.

    0 comments No comments

  4. Richard Celedon 1 Reputation point

    We have kind of the same issue, we currently have only 1 Azure VM acting as Domain controller.

    Facing the same issues you're experiencing, some on-prem computers can connect with the privatelink, however they sometimes lose access and then getting "The specified network password is not correct" when trying to remap, solution has been re-join to domain, re-sync the AD Connect installed on DC, Reset Account for that computer in Active Directory Users and Computers, but some of the computers won't connect at all using their AD credentials, we have to map them using the Storage Account key and manually editing in the Credential Manager for Windows.

    I've already tried most of fixes found on internet regarding this but unfortunately is not working at its 100% as it should, Microsoft says "seamless" transition but this has been like a hell.

    0 comments No comments

  5. Marc Milard 0 Reputation points

    I had the same problem

    To solve it :

    • log in to your domain controller
    • Open Active Directory Users and Computers
    • Find the Computer account related to your storage account
    • Right click / Properties / Attribute editor
    • Update attribute : ServicePrincipalName

    You should see a value like: cifs/<storageaccount>

    Add cifs/<storageaccount>

    • Close the popups selecting OK
    • On your faulty computer, try to access again using the privatelink
    • It could take time to propagate (few minutes)

    Worked for me.

    0 comments No comments