Purpose:
The purpose of this post is to walk through the experience of configuring a Windows client to map a drive to an Azure File Share, with the User Experience that they are used to. The process is documented in a multi-part article on Microsoft Docs. This post is meant to summarize the experience of going through this process and offer some guidance on areas that may be confusing. The steps to complete this task along with notes on the experience will be listed below.
Assumptions:
Knowledge of creating Azure Storage Accounts, Azure File Shares, and Synchronizing on-premise Active Directory user accounts to Azure AD with Azure AD Connect is assumed. It is also assumed that you have inserted data into the Azure File Share with a supported tool, like Azure File Sync, AzCopy, Windows Explorer, etc. Depending on the security posture needed for a production environment, this configuration would likely have tighter access controls. For our demonstration purposes, this configuration is being used for functionality and convenience.
Steps:
- Join the Azure Storage Account containing the file share to AD (https://docs.microsoft.com/en-us/azure/storage/files/storage-files-identity-ad-ds-enable)
Run "Join-AzStorageAccountForAuth" cmdlet to join Storage account to Azure AD as shown here:
$ResourceGroupName = "My-Resource-Group-Name"
$StorageAccountName = "My-Sub-Name"
$Domain = "My-FQDN"
Import-Module -Name AzFilesHybrid
Join-AzStorageAccountForAuth `
-ResourceGroupName $ResourceGroupName `
-StorageAccountName $StorageAccountName `
-DomainAccountType "ComputerAccount" # Default is set as ComputerAccount `
-Domain $Domain
- Sync AD Users that need to map the drives to Azure AD using Azure AD Connect.
Note: These accounts cannot be privileged accounts in Active Directory because Azure AD Connect will not sync those accounts to Azure AD.
- Synchronize/Rotate Azure Storage Account AD Computer Object Password to your Azure Storage Account (https://docs.microsoft.com/en-us/azure/storage/files/storage-files-identity-ad-ds-update-password).
Note: If you omit this process, your AD users will NOT be able to access the Azure File Share as intended
Connect-AzAccount -Environment "AzureCloud" #Adjust as-necessary
$ResourceGroupName = "My-Resource-Group-Name"
$StorageAccountName = "My-Sub-Name"
Ipmo AzFilesBybrid
Update-AzStorageAccountADObjectPassword `
-RotateToKerbKey kerb2 `
-ResourceGroupName $ResourceGroupName `
-StorageAccountName $StorageAccountName
- Assign share permissions: Assign Azure Storage Share Level Access roles ("SMB Roles") to sync'd AD Users (https://docs.microsoft.com/en-us/azure/storage/files/storage-files-identity-ad-ds-assign-permissions)
Note: There are three built-in Azure SMB Roles that can be used to control access at the Azure File Share Level. These are share-level permissions; NTFS permissions do NOT control access at the Azure File Share level.
- Administratively Modify/Assign NTFS permissions (Only If Needed): The following scenarios will determine your path to assigning NTFS permissions:
- Your permissions are fine and do not need modified: Skip to Step 8
- Your permissions need to be changed and you have an AD Sync'd user that has the permissions to make the needed changes via mapped drive: Skip to Step 8
- Your permissions need to be changed and you do NOT have a Sync'd user that has NTFS permissions to do it, follow the code block below: Keep in mind that this method of mapping is using the storage account key and not a user account so proceed with caution.
$StorageAccountName = "My-Sub-Name"
$AzureFileShare = "My-Share-Name"
$connectTestResult = Test-NetConnection -ComputerName "$StorageAccountName.file.core.windows.net" -Port 445
if ($connectTestResult.TcpTestSucceeded)
{
net use X: "\\$StorageAccountName.file.core.windows.net\$AzureFileShare" /user:Azure\<StorageAcctName> '<StorageAccessKey>'
}
else
{
Write-Error -Message "Unable to reach the Azure storage account via port 445. Check to make sure your organization or ISP is not blocking port 445, or use Azure P2S VPN, Azure S2S VPN, or Express Route to tunnel SMB traffic over a different port."
}
- If you used Step 5: Set ACL's on File system in Azure Share (https://docs.microsoft.com/en-us/azure/storage/files/storage-files-identity-ad-ds-configure-permissi...)
- If you used Step 5: Remove Drive Mapping Using Storage account key. If you used the script from above, you can use the following script to remove the drive mapping as the storage account key. This step is necessary so that you are able to successfully map the drive with your user account, as described in step 8.
Note: It is not recommended to keep the drive mapped with the Storage Account Key.
net use X: /DELETE
- Map a drive to your Azure File Share using your AD user account (Windows Explorer, Command-Line, PowerShell, etc.)
- Once the drive is mapped, make any necessary NTFS ACL Changes as-needed.
- Troubleshooting: If you encounter issues with this process, try the following tools for troubleshooting/debug information:
- https://docs.microsoft.com/en-us/azure/storage/files/storage-troubleshoot-windows-file-connection-pr...
- Specifically, the following PowerShell command can expose many things that could be causing problems:
Connect-AzAccount -Environment "AzureCloud" #Adjust as-necessary
$ResourceGroupName = "My-Resource-Group-Name"
$StorageAccountName = "My-Sub-Name"
Ipmo AzFilesBybrid
Debug-AzStorageAccountAuth -StorageAccountName $StorageAccountName -ResourceGroupName $ResourceGroupName -Verbose
References:
Overview - On-premises AD DS authentication to Azure file shares | Microsoft Docs
Enable AD DS authentication to Azure file shares | Microsoft Docs
Control access to Azure file shares - on-premises AD DS authentication | Microsoft Docs
Control what a user can do at the file level - Azure file shares | Microsoft Docs
Mount Azure file share to an AD DS-joined VM | Microsoft Docs
Update AD DS storage account password | Microsoft Docs
