Azure Files enabled AD DS SMB authentication Best Practices and all you need to know

02/03/2022 Update 1

There are some improvements and changes in the AzFilesHybrid module, I updated the article with this changes.

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.

Contents

General

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 (AD DS or Azure AD DS).

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.

Azure Files enabled SMB authentication overview

Preparation

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)

Join Azure Fileshare to AD DS

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:

.\CopyToPSPath.ps1
Import-Module -Name AzFilesHybrid
Connect-AzAccount
$SubscriptionId = “<your-subscription-id-here>” $ResourceGroupName = “<resource-group-name-here>” $StorageAccountName = “<storage-account-name-here>”
Join-AzStorageAccountForAuth ` -ResourceGroupName $ResourceGroupName ` -StorageAccountName $StorageAccountName ` -DomainAccountType “<ComputerAccount|ServiceLogonAccount>” -OrganizationalUnitName “

Example for a correct command:

Join-AzStorageAccountForAuth ` -ResourceGroupName $ResourceGroupName ` -StorageAccountName $StorageAccountName ` -DomainAccountType ComputerAccount  -OrganizationalUnitDistinguishedName "AzFileShares"

Please keep in mind: When using a Computeraccount as a Storageaccount Domainobject do not use a Storageaccount with more then 15 characters (sAMAccountName maxium length are 15 characters or or more precisely the Netbios name does not allow more than 15 characters

Azure Files: Error Storageaccountname has more than 15 characters

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.

Setting up Share-level permissions

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.

Enable higher security for SMB traffic with Azure Private link

Azure-Private-Link-overview-by-Microsoft-Azure-Blog

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 is only available for Azure Files Premium (not for Azure Files Standard). This increase the performance for the connection between the Client and Fileshare.

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.

Gregor Reimling