This article is contributed. See the original author and article here.

Introduction


Hello everyone, this is Andrew Coughlin and I am a Customer Engineer at Microsoft focusing on Azure IaaS.  In this blog I will be discussing an issue I came across while working with one of my customers. 


I was working with a customer to setup Active Directory authentication for Azure Files over smb for a storage account in their environment.  Below shows a generic layout of how the domain is setup.  The domain had a single forest with multiple domains inside that forest:


 


AndrewCoughlin_0-1617796048972.jpeg


 






















Domain



Resource Type



contoso.local



Domain controllers



corp.contoso.local*



users, workstations, groups, domain controllers



infra.contoso.local*



servers, service accounts, domain controllers



*AD Connect Sync is configured


 


The storage account was going to be joined to infra.contoso.local, and admin account the user was logged into the workstation running the commands was part of the corp.contoso.local domain. 


 


Prerequisites



  • Ensure these steps have been completed before setting up the storage account.

  • Create a storage account as documented here, then create a Azure File Share as documented here.


 


Troubleshooting Steps


We started following the documentation as noted here, for setting up Authentication for Active Directory Domain Services authentication over SMB for Azure file shares.  However, when we ran the Join-AzStorageAccountForAuth, it would fail with the following error message:


 


AndrewCoughlin_1-1617796049026.png


 


While reviewing the error message I noticed something strange, it is looking at corp.contoso.local, instead of infra.contoso.local, even though we specified the OU that the storage account should be joined to.  The reason behind this is because the admin account we are logged into the system with is part of corp.contoso.local.   After doing some research I then noticed there was a -Domain switch in the Join-AzStorageAccountForAuth. 


 


We then ran the command with the -Domain “infra.contoso.local” switch and once completed we received a success status which showed the storage account had been joined.


 


AndrewCoughlin_2-1617796049034.png


 


Next, we want to verify the storage account had been joined and checked the OU that I specified in the join command and confirmed the storage account was in the correct OU.


 


AndrewCoughlin_3-1617796049038.png


 


Then we proceeded with the rest of the steps as outlined in the documentation.


 


Conclusion


If you have ran into this issue, I hope you find this blog helpful and reduces the time in troubleshooting this error when joining a storage account to your Active Directory Domain.  Thank you for taking the time to read this blog and have a great day!


 


Disclaimer


The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.

Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.

%d bloggers like this: