How to secure Azure Files with Azure AD account permissions

Salaam, Namaste, Ola and Hello!

For those who are new to my blog welcome, and to those returning a big thanks! It has been a while since I did a more technical blog so hopefully you will enjoy this one!

Today’s post is based on a recent experience I had which involved a customer who are fully SaaS Microsoft Cloud (Office 365, SharePoint Online, Azure AD and Intune for MDM). They had a requirement where they wanted to use an on-premises Windows based file share but wanted to utilize their existing Azure AD cloud only accounts to set permissions to the folder structure, as you do when you have an on-premises Active Directory Domain.

The Windows Server was a 2016 Virtual Machine hosted in Azure (IaaS), however it was not part of any domain as Azure AD does not allow you to ‘add devices to the domain’ but enroll them, which was not going to help in this scenario.

When investigating this I thought the best way to implement this was going to be an ‘Azure Files’ share Azure Files offers fully managed file shares in the cloud that are accessible via the industry standard Server Message Block (SMB) protocol and can be mounted to an on-premises Windows server as a file share. However this still did not solve the permissions side of my issue, as in its default state you cannot assign Azure AD permissions to an Azure Files share.

The solution…implement Azure Active Directory Domain Services into the tenant. This would then sync with Azure AD, and I could then add the Windows Server 2016 to the ‘Domain’ in the traditional way you would if on-premises.

Difference between Azure AD and Azure AD Domain Services: The traditional Windows share supports authentication on a ‘managed domain’ which is not what Azure AD is. Azure AD does not generate or store password hashes in the format that is required for NTLM or kerberos authentication, and this is where Azure AD Domain Services comes into the picture, as this stores password hashes in the same way an on premises Active Directory domain controller would.

There are obviously a lot more differences between the two, but the ones that are relevant to this issue were above. For a full break down and comparison of Azure Identity Services I recommend reading through this article:

Identity Management

Azure Active Directory Domain Services was very easy to setup but first required an Azure subscription within the IaaS (Infrastructure as a Service) part of Azure where as Azure AD and Office 365 sit on the SaaS (software as a Service) part of Microsoft Cloud. I followed this guide when configuring Azure AD DS: The customer already had an existing Azure AD tenant, so I was able to configure the Azure AD DS instance to the same default domain.

I found the configuration the easy part of this solution. The final part however required user input, which was to change there login passwords. A cloud-only user account is an account that was created in your Azure AD directory using either the Azure portal or Azure AD PowerShell cmdlets.

For cloud-only user accounts, users must change their passwords before they can use Azure AD DS. This password change process causes the password hashes for Kerberos and NTLM authentication to be generated and stored in Azure AD. You can either expire the passwords for all users in the tenant who need to use Azure AD DS, which forces a password change on next sign-in, or instruct them to manually change their passwords

Once this task was completed, I was able to add the Sever to the new AD DS domain as it sat within the same network (vnet) sub-net as the Azure AD DS instance and assign permissions to the Azure AD accounts to ensure the same security permissions that were in SharePoint Online were replicated to the Windows based file share! You can utilize an on-premises virtual machine, but this would require a Site-to-site VPN between your on-premises infrastructure and Azure to allow the virtual machine to communicate with the Azure AD DS instance.

From a cost perspective, Azure Active Directory Domain Services is £80 for up to 2500 identity objects which includes user accounts, groups and computers so its probably more cost effective to provision this than a VM Domain Controller in Azure as when you add the monthly VM cost along with licenses it can rack up.

Once the Identity Management and VM stage is completed, its time to provision and configure the Azure Files. Creating the Azure File share is straightforward enough, but step by step instructions can be followed here: . Once this has been created you need go into the configuration under settings and enable ‘Azure Active Directory Domain Services’ under the ‘Identity-based access for file shares’ section.

Now you need to give the relevant permissions to a user or group the necessary permissions at the share level. The Azure built-in groups for granting share level permissions are:

  • 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 then mount the file share onto the Windows VM and assign the standard NTFS permissions via explorer as you would in an on-premises environment.

That concludes this post, I hope you enjoyed it and I would love to know what you thought so please feel free to leave a comment in the comments section or tweet me. Until next time, ‘IamITGeek’ over and out!

15 thoughts on “How to secure Azure Files with Azure AD account permissions

  1. I may not be following your post correctly, but did you mount the file share on the VM and then have users access it from there via a traditional server mapped drive, or were users still mounting the Azure File Share directly on their PC?

    The implementation I’m trying to do is to have NTFS file permissions, but still have individual users at remote sites (or at home) be able to directly connect the Azure Files share. Is that possible?


    1. So in my case I mounted it as a network drive and used Azure AD and Azure AD Domain services so I could utilise ntfs permissions. Then the users mapped that as a network share yes.

      I believe you should be able to map/mount the Azure File share directly to the Windows 10 pc, and then user would probably need to authenticate with there Azure AD credentials. Need to make sure you configure the Azure Files to integrate with Azure AD DS.


      1. Okay, I wanted to make sure I was understanding how you were doing it since it seemed a little bit different than my use case. I was just testing and my NTFS permissions aren’t being respected when I use the default connection command/script provided in Azure (which has it’s own user/pass string, which is probably why). I tried mapping the drive through explorer and manually entering credentials (it did prompt for them), but it wouldn’t take any credentials, even global administrators. I did enable the Identity Based Access For File Shares in the configuration. I’ll keep fooling with it.



      2. So do you have Azure AD and Azure AD domain services? If so you need to change passwords for all accounts so it can convert the password from hash (used by Azure AD) to kerberos (used by Azure AD DS). That maybe your issue?


  2. Doesn’t seem like I can respond in the same comment thread, but thought I’d leave this here in case xomeone else hits this looking for the same thing. Per, the “Azure AD DS authentication over SMB with Azure file shares is supported only on Azure VMs running on OS versions above Windows 7 or Windows Server 2008 R2.” So, as I read it, it can’t be authenticated to with regular credentials directly on an end-user’s PC, thus eliminating NTFS permissions. In my understanding, the only way to utilize permissions is the way you did it here in your article.


    1. My apologies for misleading. Thank you for posting the link as well


    1. Is that a question or just a statement that you feel the subject matter is legacy?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this:
search previous next tag category expand menu location phone mail time cart zoom edit close