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!