Let's look at setting up authentication for Azure Files implemented with the SMB protocol by creating a file share and accessing it from a virtual machine. First, I'll create a file share, imaginatively called file share. Even though we're told transaction costs are higher on cooler tiers, they'll be virtually no transactions, so I'm not worried. Soft delete is currently disabled, so I'll enable it and set the retention period to one day. I'll be accessing the file share with identity-based authentication, so I will need to configure Azure Active Directory Domain Services. I'll be using a domain-joined virtual machine to access the file share. Once you've set up AD domain services, it's just a case of checking enable Azure AD DS. 

Next, we need to specify the default access for the file share. For the sake of brevity and ease of use, I'll go with enable permissions for all authenticated users, but in the interests of least privileged access, set the default role to Storage File Data SMB Share Reader. I assume that all users will at least want to see and read the file share's content. The other built-in SMB share-specific roles are contributor, which has modify permissions, and elevated contributor, which can set NTFS permissions on folders and files within the share. For RBAC permissions set within the Azure portal to work, you must ensure that under configuration, default to Azure Active Directory authorization in the Azure portal is enabled.

With the active directory configured, let's set up the file share on the VM with a user without elevated permissions. I'll grab a small script from the file share's connect context menu item. The authentication method is Active Directory, and I'll map the share to drive letter F. Click show script and copy the script. After logging into the VM, I'll open a PowerShell window and paste in the script. The script tests for a connection to the storage account over port 445 and, if successful, creates a persistent drive mapping to the F drive. Remember when I selected "Enable permissions for all authenticated users and groups" as the default for active directory authentication? If I'd selected disable permissions and not set the SMB share reader role per user, I wouldn't have permission to run this script. You might think that a user with elevated permissions could set up the share drive mapping for other users in the domain. However, this is not the case. You could set up a global mapping in a hybrid scenario with on-premises machines using a group policy, but in a cloud-only situation, it is not possible at this time.

Ok, here we have F drive mapped to the file share. When I go to create a folder within the share, naturally, as a reader, I don't have permission. Let's return to the portal and give the user the storage file data SMB share contributor role on the file share. So that's add role, select the role, and choose the user to assign the role. In a production environment, you'd been assigning these roles to groups and users to those groups.  

While that role is being assigned – it does require a few minutes to take effect – I'll log into the VM as an elevated user and look at the user the file share uses for authentication. Using the magic of video, I've already done the drive mapping. Go to server tools and open Active Directory users and computers. Under the domain, in AzureFilesConfig, we can see the user Active directory has created with the name of the storage account. The role assignment on the other user should have taken effect by now, so let's log back in as the standard user. Now I can successfully create a folder in the file share. Back in the portal, the new folder is displayed in the file share.