The Azure Files Teams announced the availability of joining Azure Fileshares to AD DS since February 2020. This brings a lot of new possibilites, like to move Fileservers directly to a hosted SMB solution or deploy WVD Profiles directly on Azure Fileshares.
Microsoft did a lot of work to bring this solutions to live, but there are some challenges and pitfalls to activate and maintain the service. In this article I will go in a short way over all related considerations for Azure Fileshares AD DS authentication. Please note this article only focus to enable Azure Files for Active Directory Domain Services – not Azure AD or Azure AD DS.
- 1 General
- 2 Preparation
- 3 Join Azure Fileshare to AD DS
- 4 Computer or Service account and the references of password expiration
- 5 Setting up permissions
- 6 Enable higher security for SMB traffic with Azure Private link
- 7 Higher performance for Azure Files with SMB multichannel
- 8 Links
Azure Files is based on Azure Storage Accounts and is one of four services available on Storage Accounts. Azure Files supports integrated authentication for Active Directory Domain Services or Azure Active Directory Domain Services, when the Fileshare (in general) the Storage Account is joined as a member the Domain. First of all the Storage Account can only be a member of one directory service.
Enablement and using of Azure Files AD DS authentication over SMB is really useful for Domain accounts that are exist in the local AD DS and are synced over Azure AD Connect to the Azure AD. Accounts that are not synced can use the Azure Fileshare with integrated permission or can use the SA credentials, but this is not part of this article.
Using AD DS authentication over SMB for Azure fileshares the Fileshare, or in general the Storage account in that the Fileshare reside, needs to be member of the AD DS. Before we start to join the Azure Fileshare to the Domain, some additional recommendations.
Create and use a separate Organizational Unit for Azure Fileshares. This is a recommendation for several reasons:
- Separated and central place for Azure Fileshares
- Allows the use of own GPOs and prevents configuration settings by other GPOs
- Disable password expiration for a specific OU when using a Computer object, when using a Serviceaccount set the password to “Never expire”
In order to connect Azure Fileshare to the domain, some requirements are recommended:
- Use a Client that is joined in AD DS
- Login to the Client with a Domainaccount that are synced to Azure AD
- The account must have rights to create Computer- or Serviceaccount- Objects in AD DS
- The account must have Storage account owner or contributor rights in Azure RBAC
- Download the latest AzFilesHybridModule from GitHub and extract the ZIP Archiv
- Internet access for missing modules (like Az module)
There are two ways possible to join a Azure Fileshare (or the underlying Storage Account) to a AD DS. With the first way we need an account with Owner or Contributer rights at the Storage account in Azure.
In this article we will use the first (preferred way) to join the Azure Fileshare to the AD DS. The 2nd way is well suited without the need for a synchronized account with increased rights.
- Install and execute the AzFilesHybridModule on a domain-joined device with user credentials that have permissions to create Computer or Service accounts (when Az Module and NuGet not available on the machine this will also installed)
- The accounts needs Owner or Contributor rights on the Azure Storage account
- Start a Powershell windows with admin rights and run the following Powershell commands in the folder that contains the enzipped files:
Import-Module -Name AzFilesHybrid
$SubscriptionId = “<your-subscription-id-here>” $ResourceGroupName = “<resource-group-name-here>” $StorageAccountName = “<storage-account-name-here>”
Join-AzStorageAccountForAuth ` -ResourceGroupName $ResourceGroupName ` -StorageAccountName $StorageAccountName ` -DomainAccountType “<ComputerAccount|ServiceLogonAccount>” -OrganizationalUnitDistinguishedName “
Computer or Service account and the references of password expiration
The Fileshare can join the Domain as an Computer- or Service account. This two account types has some notes in the password expiration and going deeper in the AD DS default configuration.
First of all the Default password settings can only be set at the Domain level. It is possible to set different settings for user and groups but not at OU level. This changes are not working for computer accounts.
Second one the default password expiration for a Computer account in a AD DS is set to 30 days (default setting). The important think to note is: Computer accounts handle password updates completly different than User accounts. When the password is older than the domain policy, the computer will not block from using the AD DS or with other words the Password for Computer accounts never expires. Read more how AD DS Computeraccounts handle password updates.
Right now I prefer to use the Computeraccount to join the Storage account to the AD DS. But this is up to you, please keep in mind, when using Service accounts to configure the password expiration policy.
Setting up permissions
When using Fileshares on Windows Server there are two access models. The first is the Fileshare permission which means, which users or groups can reach the Fileshare with given rights. The second one are the ACL permission directly on the Folder or File level. The permissions from both are evaluated and the lowest permission level is granted.
For Azure Fileshares are the following three roles available, in difference to a hosted Fileshare on a Windows Server:
It makes sense to create an Azure AD group and give it the appropriate Storage File Data SMB Share permissions so that users can access the file shares with the given permissions.
Setting up the NFTS ACL permissions
After setup the Fileshare permissions for Azure Files via Azure RBAC, the second needed permissions are the NFTS permissions. This can be setup directly on the client, where the Fileshare is joined. Please keep in mind to use a User with appropriate permissions on the Fileshare level and on the Windows Server to set the correctpermissions.
When using Azure Fileshares from outside the Azure Network, the traffic flows over the Internet. Each Azure Fileshare deployment enable SMB encryption as a default setting and do not allow client communication without encryption.
When using Azure Files as an replacement for local Fileservers it is not ideal that the traffic flows over the Internet. It is possible to move the traffice inside the corporate network and route them over an existing VPN connection between the branch and Azure. To secure traffic and keep it within the private network use Azure Private Link. Take a look at my article about setup Azure Private Link in an earlier article.
Higher performance for Azure Files with SMB multichannel
Per default SMB only use a single channel for communication. With the new Azure Files SMB multichannel preview it is possible to enable multichannel communication for SMB. This increase the performance for the connection between the Client and Fileshare. Unfortunately the preview is currently paused. As soon as it is available again, I will note this here.
I hope this gives you good insights in planning for Azure Fileshares as an replacement for Fileservers or for other solutions such as WVD profile shares. Please feel free to reach me for questions, for feedback or leave a comment when the article is useful.
- Microsoft Docs – Overview of enablement for Azure Files SMB authentication over AD DS
- Microsoft Docs – Enable AD DS authentication to Azure Fileshares
- Microsoft Docs – Overview of Azure Files identity based authentication options for SMB
- Microsoft Docs – SMB security enhancements
- Microsoft Docs – Planning for Azure files deployment
- AzFilesHybridModule source on GitHub
- Keep SMB traffic within the private network with Azure Private Link
- How AD DS password settings work for Computer accounts