Last Update: Sep 04, 2024 | Published: Dec 28, 2018
In this post, I will clarify what this new permissions feature for Azure Files shares, powered by Azure AD Domain Services, offers, supports, and does not support.
Microsoft added the Azure Files service to general purpose (now GPv1 in addition to GPv2) storage accounts to provide a means for creating SMB shares in the cloud. Normally, when people hear “Azure Files” they imagine end user shares that magically reside in The Cloud without an actual file server; this is partly correct.
Azure Files does allow you to create a share from the capacity of a general purpose storage account. However, these shares are not for end users. They are for other systems that would otherwise require a file server or file server cluster to run as more expensive virtual machines. For example, you can replace a file server/share that is used to store configuration data for a legacy line-of-business application that is being migrated to the cloud, or use an Azure Files share as shared SMB 3.0 storage for a cluster running in Azure virtual machines.
Note that a service that uses Azure Files shares and does facilitate end-user access is Azure File Sync. Yes; users are accessing a share in Azure Files, but they do it via their on-premises file server, which is connected to Azure File Sync, and that is connected to the share.
While a service such as Azure File Sync can store permissions in Azure File shares, the shares have been unable to implement those permissions. If I created a share in Azure Files that was two be used by some application servers running in Azure, then there would be no file/folder permissions – either the machines could connect to the share or they could not.
The first thing to know is that Azure allows us to create an identity for some Azure resources, such as virtual machines; this is known as a managed service identity. This identity can be used to assign permissions – ideally the identity would be a part of a group and you would assign permissions to a group.
Azure Active Directory Authentication over SMB for Azure Files (that is memorable!) is a new preview feature that allows us to assign permissions to the contents of an Azure Files share for more granular control. Now we can, in preview, use more granular controls than just block/allow on the share.
The name of the feature doesn’t imply one of the requirements – this service is powered by Azure AD Domain Services, a cost in addition to Azure AD (free, or any other license). Your virtual machine(s) will join this domain, and the identity and any groups will be made available to Azure Files via Azure AD.
The share does not have a UI for permissions. Instead, you will have to:
Don’t make any assumptions! Azure AD Authentication over SMB (the short name of this feature) has a number of limitations, some which are temporary, and some that might take more time to work on.
Microsoft is very clear about some things:
Azure AD authentication over SMB is not supported for Linux VMs for the preview release. Only Windows Server VMs are supported.
Azure AD authentication over SMB is not supported for on-prem machines accessing Azure Files using either AD or AAD credentials.
Azure AD authentication is available only for storage accounts created after September 24, 2018.
You will only be able to use Azure AD Authentication over SMB to control system access to shares in Azure Files. You cannot use it directly with end users. And you will need a relatively new storage account to access this feature.
There is another concern too – do not mix the usage of these shares. For example, if a share is being used by Azure File Sync, don’t use it directly with end users, or other systems. If someone or something makes a change directly in an Azure Files share, then that change might take 24 hours to sync to on-premises servers. Note that:
Azure Active Directory Domain Services Authentication over SMB for Azure Files, to call it what I think it should have been called if we want to use a “descriptive approach” to naming, is quite crude. But this is a cloud service, so it’s wrong to judge the long-term future of a service by a preview release or V1.0 – if there is adoption, it might have rapid improvement. I think that this feature will be misunderstood by many (Azure AD is already misunderstood as a classic domain in the cloud for on-premises devices/users) but correctly used by the few that need it.