Yes, a very long-winded title! Our Principal Consultant Toby Skerritt takes a look at AD authentication over SMB for Azure file shares.
The ability to set Active Directory based permissions on Azure Storage Account file shares has been one of the most heavily requested features of the platform. It’s now available in preview, and although there are a few manual processes to contend with, configuration is reasonably straightforward.
Another benefit of this service beyond ACL managed file shares is that Windows Virtual Desktop and the FSLogix profile management tool can take advantage of this new function in order to store and retrieve user profiles in a secure fashion, with appropriate permissions applied to prevent unauthorised access to user profile folders or their contents. Adopting this service for FSLogix profiles is tested later in this blog.
Initial Configuration and Prerequisites
Firstly, it is important to ensure that you meet the prerequisites listed in the configuration article linked below:
From a high-level perspective, the key prerequisites are:
- Ensure you have Azure AD connect configured to synchronise your target user accounts or groups to AAD.
- Make sure you have an account to hand with appropriate permissions to modify storage accounts in your target Azure subscription.
- Create your storage account in a supported region. If you accidentally create a file share in an unsupported region, the script will helpfully inform you of this when you run Join-AzStorageAccountForAuth command.
- Ensure you have decided on a target OU for the local identity. For this, I created a specific AzStorageAccounts OU.
- Download the AzFilesHybrid module to the machine from which you will run the PowerShell commands. I used a local Domain Controller for this.
Creating the Azure File share
I chose to create one of the new FileStorage specific storage accounts which are available on the premium tier, mainly because I had not configured one before!
Although these are billed according to provisioned size rather than used size as with other storage accounts, they provide guaranteed IOPS and bandwidth which scales dynamically based on the provisioned capacity of the share.
Enabling Active Directory Permissions
The module files were unzipped to the location C:\AzFilesHybrid as you can see in the below screenshots, then the required commands were run from an administrative PowerShell window.
Importing the module:
Authenticating to Azure and selecting the required subscription:
Configuring the storage account for hybrid permissions. Note that the OrganizationalUnitName parameter only supports the specific OU name, not the Distinguished Name. Hopefully this will change in a later release. UPDATE: the parameter OrganizationalUnitDistringuishedName is also supported.
The result of a successful command. ProvisioningState is listed as Succeeded
Confirming the Configuration
Successful completion can be validated by running the below commands from the configuration article.
The DirectoryServiceOptions query should return AD, and the ActiveDirectoryProperties query should return the relevant domain details. Both queries will return blank results if the configuration is not complete.
The Computer Account identity object gets created in the target OU specified in the Join-AzStorageAccountForAuth command.
In Azure, the storage account will now display this handy GUI addition, showing that AD-based identity is enabled and including the name of the associated domain. AAD DS based access is disabled and greyed out, as this cannot be used in conjunction with AD based access.
Users or groups should be given RBAC access to the appropriate share, using one of the new SMB access roles available in Azure.
Configuring Folder Permissions
To configure the required folder permissions, connect to the new share using the access key to set AD based Windows permissions. I used the PowerShell script available from the storage account in the Azure web console to quickly mount the drive on my PC.
From here, use the icacls command to set any required permissions on the root of the share – don’t use the Windows Folder permissions GUI for setting permissions on the root of the share. For setting permissions on sub-folders, you can use either icacls or the Windows Folder permissions GUI.
Access to the new share can then be tested by browsing to the share, or by mapping a drive using the net use command as your test AD user.
Make sure not to use the connection command available from the Azure file share for testing, as this will create a persistent connection using the storage account key, bypassing AD based authentication.
For testing, two shared folders have been created in the root directory; “User Access” with Full control for our test AD user, and “Admin Access” with explicit deny permissions for this AD user.
I logged into a Windows Virtual Desktop as my test AD user to check functionality. After mapping drives to the separate shares, you can see that my access to the admin share is limited by Windows permissions. I have no read access to the Admin share, whereas I can browse and edit the user share, which is exactly what I was hoping to achieve.
Using Azure Fileshares for FSLogix Profiles
The same principle shown above can be applied to FSlogix user profile disks by applying the permission guidance to an Azure file share.
For testing, I created two users and configured the appropriate FSLogix GPOs to store the user profile disks in our new file share. Both users were give identical Azure share and root folder permissions.
With profiles written to hybrid Azure file shares, domain user only have access to their own profile folder and cannot read other user profile folders as shown below.
We have been waiting a long time for the ability to apply domain ACLs to Azure file shares. The functionality is finally here, and it works very well.
For any organisations experiencing storage constraints with their on-premise or IaaS file servers, or for those considering implementing Windows Virtual Desktop, Active Directory authentication over SMB for Azure file shares is a solution that should provide a great experience.
I hope you found this blog informative and useful! You can connect with Toby on LinkedIn linkedin.com/in/toby-skerritt-560b811a
About the Author: Toby Skerritt
Toby has been with Foundation IT for 10 years and is our Principal Consultant. In addition to his 10-year stint, he is an End User Compute / Azure Virtual Desktop specialist who loves music, technology and Southampton FC.