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 https://docs.microsoft.com/en-us/azure/storage/files/storage-files-introduction. 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: https://docs.microsoft.com/en-us/azure/active-directory-domain-services/compare-identity-solutions
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: https://docs.microsoft.com/en-us/azure/active-directory-domain-services/tutorial-create-instance. 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: https://docs.microsoft.com/en-us/azure/storage/files/storage-how-to-create-file-share . 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!
Technical Blog 
methodical
LikeLiked by 1 person
Thanks!
LikeLike
Thank you!
LikeLike
solid state
LikeLike
Avon
LikeLike
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?
LikeLike
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.
LikeLike
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.
Thanks!
LikeLike
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?
LikeLike
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 https://docs.microsoft.com/en-us/azure/storage/files/storage-files-identity-auth-active-directory-domain-service-enable, 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.
LikeLike
My apologies for misleading. Thank you for posting the link as well
LikeLike
Hat
LikeLike
Legacy
LikeLike
Is that a question or just a statement that you feel the subject matter is legacy?
LikeLike
vertical
LikeLike
Thanks for the article. Do you happen to know whether it is possible to use this approach when there is already an on-premises AD, with AAD Connect in place? Or would we need to remove the existing AAD Connect before standing up AADDS?
LikeLiked by 1 person
There is no need to remove the existing sync with on-premises. Although Azure AD DS can have the same domain you use on-premises they actually have individual syncs with Azure AD. As long as your on-premises AD has no network connection to the network your Azure AD DS is provisioned you are fine. If have done some YouTube videos on the subject which you can have a watch of if it helps: https://YouTube.com/iamitgeek
LikeLike
Thanks – so would a PC that needs to connect to the Azure Files need to be joined to the Azure AD DS – or just joined to Azure AD?
LikeLiked by 1 person
Thanks – so would a PC that needs to connect to the Azure Files need to be joined to the Azure AD DS – or just joined to Azure AD?
LikeLiked by 1 person
So the storage account can be joined to your on-premises domain as well which sounds like it would be the correct configurations for your scenario (which is not covered in this blog). This only explains how to use cloud only accounts which is why it uses Azure AD DS
LikeLike
The end game is to get rid of the on-premises AD, so move the computers to be Azure AD joined, but still need to access the Azure Files, so effectively ending up with it all being cloud-only.
LikeLike
Ahh I see…then definitely Azure AD DS would be the correct move. You can join your storage account to Azure AD DS and utilise the same account and login details you use on-premises until you remove Active Directory
LikeLike
As I thought – thanks. So for a PC that is removed from on-prem AD, and instead is Azure AD joined, with a user signing in as their 365 account, what in terms of vNet, private endpoints, etc. needs to be in place for them to access Azure Files remotely?
LikeLike
So there different ways you can map the Azure File Share…you can use either AD DS authentication or SAS token authentication… https://docs.microsoft.com/en-us/azure/storage/files/storage-how-to-use-files-windows this link will explain how to map to Windows 10 and the different supported versions
LikeLike
Hello, very interested in this post since we have 1,500 Windows 10 devices managed by Intune and users have Cloud-Only accounts, so our hope was to extend Azure ADDS out so these users could access Azure File shares from their Windows 10 devices.
I think you have answered a similar question previously, but as we also have Azure ADDS supporting a small fleet of Windows IaaS servers in Azure, you’re saying that I follow this guide and I can then present a public endpoint file share to a users device that is Azure-AD joined if I map that share to the IaaS server? Then to the user, there is no real world difference for them accessing this share via NTFS (SAS Keys are pointless with an immature user base). Sorry if I’m covering old ground, I just wanted to be crystal clear here.
LikeLike
Thanks for the comment! So this post might be slightly outdated and there will be more or different steps that you may need to follow but essentially in theory yes that should work
LikeLike