In This Article
Azure Files offers shared storage for applications using the standard SMB 3.0 protocol. Microsoft Azure virtual machines and cloud services can share file data across application components via mounted shares, and on-premises applications can access file data in a share via the File storage API. Applications running on Azure virtual machines can also mount a File storage share to access file data, just as a desktop application would mount a typical SMB share. Any number of Azure virtual machines or roles can mount and access the File Storage share simultaneously.
Microsoft also introduced Azure File Sync which is a new service that will allow you to centralize your file shares in Azure Files, whilst maintaining the compatibility of an on-premises file server with all the flexibility and performance benefits provide. Any protocol installed on the Windows Server can access the Azure file share, including SMB, NFS, and FTPS. For more information about Azure File Sync and how to get started, please check the following step-by-step guide.
Last year, Microsoft announced the General Availability (GA) of Azure Active Directory Domain Services (Azure AD DS) authentication for Azure Files. By enabling integration with Azure AD DS, you can mount your Azure file share over SMB using Azure AD credentials from Azure AD DS domain joined Windows VMs with NTFS ACLs enforced. For more details about this announcement, please check the following document.
Besides Azure Active Directory Domain Services (Azure AD DS) based authentication support for Azure Files, one of the most requested features on user voice that we all want is to enable Active Directory NTFS ACLs either for AD hosted on-premises or in the cloud. The Azure Files team was actively busy working on extending the authentication support to Active Directory (AD). And finally, Microsoft just announced the public preview support for Active Directory (AD) authentication over SMB for Azure Files.
In this blog post, I will share with you how to enable local Active Directory authentication for Azure Files, as well as how Azure File Sync can leverage the AD authentication and maintain those ACLs.
Azure Files AD Authentication
When you enable Active Directory Authentication for Azure Files, your AD domain-joined machines whether they are on-premises or in Azure can mount Azure Files using your existing AD credentials. Please note that the AD identities that are used to access Azure Files must be synced to Azure AD with Azure AD Connect to enforce share level NTFS file permission. The NTFS/ACLs on files and directories carried over from your existing file server(s) to Azure Files. This offers seamless integration with your existing AD domain environment that you used for many years.
This will open so many opportunities where your existing users can access Azure file shares directly from their Windows 10 clients joined to Azure AD with a single sign-on experience, without any change to the credentials in use. You can also host the user Profiles in Windows Virtual Desktop (WVD) using Azure Files.
Before we start enabling Active Directory authentication for Azure Files, let’s look at the prerequisites that are required:
- You need to have an existing AD environment or create a new one and then sync it to Azure AD. As mentioned earlier, the AD environment could be hosted on-premises or in the cloud. The important piece is synchronizing the identities to Azure AD with Azure AD Connect. If you have not synced your Active Directory to Azure AD yet, please follow the guidance here to determine your preferred authentication method and choose the Azure AD Connect setup option.
- You need to have at least one machine domain joined with the Active Directory domain.
- You can use an existing Azure file share or create a new one. For more information about creating a new Azure file share, please check the following document. For optimal performance, Microsoft recommends that you create the storage account in the same region as the VM from which you plan to access the file share.
- Azure Files authentication with local Active Directory Domain Services is available in all Azure Public and Government regions.
- Last, you need to verify that Azure Files connectivity is working by mounting an Azure file share using your storage account key. For more information about mounting an Azure File share locally on your machine, please check the following guide from Microsoft.
Enable AD Authentication for Azure Files
The process of enabling your Active Directory authentication for Azure Files is to join the storage account that you used to create the file share to your Active Directory. When you enable AD authentication for the storage account, it applies to all new and existing Azure file share(s).
Assuming you already have all the prerequisites in place, take now the following steps:
- Download the new Azure files hybrid PowerShell module from GitHub here and unzipped locally on your machine by running the following commands:
$Url = 'https://github.com/Azure-Samples/azure-files-samples/releases/download/v0.2.3/AzFilesHybrid.zip' Invoke-WebRequest -Uri $Url -OutFile "D:\AzFilesHybrid.zip" Expand-Archive -Path "D:\AzFilesHybrid.zip"
- Next, you need to import the PowerShell module as described in step 3 on a machine that is domain joined to your Active Directory using an AD account that has enough permission to create a service logon account or computer account. Microsoft recommends using a service logon account instead of a computer account. When you import the PowerShell module, this account will be created automatically in your domain.
- Open Windows PowerShell session on a domain-joined machine and then run the following commands:
- This module requires Azure PowerShell (Az module version 2.8.0+ and the Az storage version 1.8.2-preview+). You can install and import the latest Azure Module by running the following command: Install-Module -Name Az -AllowClobber -Scope CurrentUser
- This module also requires .NET Framework versions 4.7.2 or higher. Please upgrade to the latest .NET Framework available here.
- Change the execution policy to unblock importing AzFilesHybrid module: Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope CurrentUser
- Navigate to where AzFilesHybrid is unzipped and stored and run to copy the files into your module path: .\CopyToPSPath.ps1
- Import the AzFilesHybrid PowerShell module. If you received an error while importing the module, please delete the Az.Storage folder which is located under C:\Program Files\WindowsPowerShell\Modules and C:\Users\<username>\Documents\WindowsPowerShell\Modules. Then close Windows PowerShell, open it again, and then import the module one more time: Import-Module -Name AzFilesHybrid -Verbose
- Login to Azure with an account that has a storage account “Owner” or “Contributor” role assigned: Connect-AzAccount
- Select the target Azure subscription where the storage account is provisioned: Select-AzSubscription -SubscriptionId <subscription-id>
- Finally, register the target storage account in Azure with your Active Directory environment by specifying the domain name, the domain account type (ServiceLogonAccount or ComputerAccount), and the target OU name where the service/computer account will be created:
join-AzStorageAccountForAuth -ResourceGroupName "<resource-group-name>" -Name "<storage-account-name>" -Domain "localdomain.net" -DomainAccountType ServiceLogonAccount -OrganizationalUnitDistinguishedName "ou-name-attribute-value"
- If you switch to Active Directory Users and Computers, you can see the new Service Logon Account is created under the specified Organizational Unit Name.
- To confirm that the feature is enabled, you can run the following PowerShell commands to see the storage account that has Kerberos key now, as well as the directory service of the selected service account, and the directory domain information if the storage account has enabled AD authentication for file shares:
- Get the target storage account:
$storageacccount = Get-AzStorageAccount -ResourceGroupName "<resource-group-name>" -Name "<storage-account-name>" $storageacccount | Get-AzStorageAccountKey -ListKerbKey | Format-Table Keyname
- List the directory service of the selected service account:
- List the directory domain information if the storage account has enabled AD authentication for file shares:
- Get the target storage account:
Please note that if you are enforcing a password expiration policy in your AD environment, the new AD login account that was created in the previous step will be also expired, thus will affect your Azure file share authentication as well. To avoid this situation, you have two options:
- Update the password for the service account before the maximum password age is expired and then update the AD account password for the Azure storage account by running the following PowerShell command:
Update-AzStorageAccountADObjectPassword -RotateToKerbKey kerb2 -ResourceGroupName "<resource-group-name>" -StorageAccountName "<storage-account-name>"
- Or simply make sure the password does not expire for that particular account.
Set SMB ACLs on Azure File Share
Next, you need to assign access permissions to an identity. To access Azure Files resources with AD credentials, an identity (a user, group, or service principal) must have the necessary permissions at the share level. This process is similar to specifying Windows share permissions, where you specify the type of access that a particular user has to a file share.
With the new AD authentication for Azure Files, Microsoft introduced three Azure built-in roles for granting share-level permissions to users:
- Storage File Data SMB Share Reader allows read access in Azure Storage file shares over SMB.
- Storage File Data SMB Share Contributor allows read, write, and delete access in Azure Storage file shares over SMB.
- Storage File Data SMB Share Elevated Contributor allows read, write, delete and modify NTFS permissions in Azure Storage file shares over SMB.
You can use the Azure portal, PowerShell, or Azure CLI to assign the built-in roles to the Azure AD identity of a user for granting share-level permissions.
To assign an RBAC role to an Azure AD identity, using the Azure portal, follow these steps:
- In the Azure portal, go to your file share.
- Select Access Control (IAM).
- Select Add a role assignment.
- In the Add role assignment blade, select the appropriate built-in role (Storage File Data SMB Share Reader, Storage File Data SMB Share Contributor) from the Role list. Leave Assign access to at the default setting: Azure AD user, group, or service principal. Select the target Azure AD identity by name or email address.
- Select Save to complete the role assignment operation.
For more information on how to assign the built-in roles to the Azure AD identity of a user for granting share-level permissions using PowerShell, or Azure CLI, please check the following document from Microsoft.
Verify access permissions over SMB
To verify the access permissions over SMB, you can log in to any domain-joined VM with a user who has already access to the Azure file share and then mount the share using the net use command below. Remember to replace the placeholder values with your own values. Because you’ve been authenticated to your domain, you don’t need to provide the storage account key, the AD credentials, or the Azure AD credentials.
net use <desired-drive-letter>: \\<storage-account-name>.file.core.windows.net\<share-name>
I logged in with my user account who has full permission on the Azure file share, I was able to mount the share and access the file as shown in the screenshot below.
These ACLs can be set directly on the share or could be part of Azure File Sync.
Now if I log in with a different user named Joe, I will be able to mount the Azure file share, however, I won’t be able to open and read the file as shown in the screenshot below since I don’t have permission to do that.
Secure access to the storage account
Imagine you want to build this scenario end to end, we have a storage account with a public endpoint. As shown in the example above, I am accessing this service over a public endpoint. I would recommend restricting access to your corporate IP address range.
This can easily be achieved by adding your public IP address range to the firewalls and virtual networks section of your Azure storage account. This will take a matter of seconds to configure.
As a first step to use firewalls and virtual networks to secure your storage account is ok, but we are still accessing the share over a public endpoint. Remember also we have a private link connection, so I might have a virtual network (VNET) and I may use a private link to create an IP address in that virtual network, and then maybe I’ve got ExpressRoute connecting to my on-premises network into that virtual network using private peering and it uses the endpoint to the file share. This will give you a truly private connection to your Azure files share with full control. This also gets around the potential issues of SMB port 445 being blocked by your ISP. Microsoft did recently published good VPN documentation as an alternative to using port 445.
Azure File Sync AD authentication
Azure File Sync full AD is already supported without any extra steps. If you are always accessing the Azure File Share through a file server with a sync agent, then you don’t need to follow the steps mentioned above. Full AD support is automatic via the file sync agent.
The good news is, if you want to access the file share directly in Azure which is part of Azure File Sync, those ACLs will be maintained without any extra step on your part. You can now access the azure files directly if you wanted to, it’s phenomenal this is now just really a transparent authentication authorization ACLs on Azure files just with a regular active directory which could be housed on-premises, it could be hybrid domain controllers in IaaS VMs, it could be all in Azure it doesn’t matter but now I can have a completely transparent experience for the end-user.
If you are using file sync, then you probably want to use it everywhere, including via IaaS Azure File Sync VM instead of going direct to the Azure File Share. This is because AFS can only do immediate sync when the changes happen via a sync agent. The changes made directly to the Azure file share can take up to 24 hours+ to sync down to the sync agents because, at the time of this writing, Microsoft does not do real-time change detection in the file share. However, you can leverage the Invoke-AzStorageSyncChangeDetection to sync back the changes on-premises, but this will work for small data sets. Keep in mind that this will fail after 10K objects.
As described in this article, I’m connected directly to Azure files, I can access the ACLs just using my SMB connection and they are enforced that’s kind of the key point so this could be a pure serverless now file share capability, and I should point out that it’s not super important because I’m actually in a different region so the client domain-joined machine is in US South Central the file share was in US West Central so it is working across regions because they’re SMB3+ so it can be serverless or it could be part of Azure file sync and I can still go ahead and access that share.
There are other things you can build on this, the key point now is you can use your existing Active Directory-based ACLs on Azure Files, you don’t need Azure Active Directory Domain Services (Azure AD DS) authentication for Azure Files, please note that you cannot use both (Active Directory-integrated authentication and the Azure AD Domain Services hybrid identity at the same time), if you can do Active Directory authentication as described in this article, this is much better than using the Azure AD DS option.
Thank you for reading my blog.
If you have any questions or feedback, please leave a comment.