Identity management in Microsoft Azure is a huge component of overall management and architecting a successful environment. It is necessary for delivering apps, data and tools needed to be productive, maintain proper group policies and permissions, and much more.
In this blog post learn about the history of Microsoft’s Active Directory, it’s evolution, and the new era of identity management in Azure Virtual Desktop utilizing Azure AD Join. This is the first in a two-part series around identity management in Azure Virtual Desktop and more broadly, Azure.
A Brief History Lesson
If you are as old as I am then you will remember the phrases Primary Domain Controller and Backup Domain Controller which went waaaaaay back to Windows NT4. In 2000, Microsoft released something called Active Directory alongside Windows 2000 (I hope lots of memories are flooding back now!).
Active Directory was an essentially a database with a schema, which consisted of all the user accounts, computer accounts, security groups and other information for the Active Directory “Domain”. This information was replicated around to other “Domain Controllers” throughout a company’s Active Directory forest and domains. This allowed users to log onto the company domain and authenticate to access other resources using Kerberos or NTLM authentication.
As part of Active Directory, Microsoft also introduced the concept of Group Policies, a way of configuring settings and applying them to centrally to all of a company’s computers which were domain-joined.
Active Directory continues to be extremely popular today, an impressive 22 years after its initial release! If you ask any enterprise company running Windows, and even most SMBs using the OS, there is a high chance they will be using Active Directory.
In October 2015, Microsoft released Azure Active Directory Domain Services (Azure AD DS) to the world. Azure AD DS is an Azure-managed PaaS (platform-as-a-service) service for Active Directory. This effectively brought Azure Directory into the cloud.
Each Azure AD DS deployment consisted of two domain controllers in the company’s specified region. These are deployed and managed by Microsoft. Alternatively, some customers deployed virtual machines (VMs) into Azure and then installed AD DS onto them. Generally, this provided more compatibility and kept operating costs around the same, but it meant introducing an additional VM to manage within one’s Azure Environment.
Enter the modern era of cloud computing and we now have a third identity management service in the Microsoft mix – Azure Active Directory (Azure AD). Azure AD was initially released to support Office 365 and work alongside Azure AD DS or AADS. Admins sync users and security groups from either of these solutions into Azure AD and then Office 365 and other Microsoft services use Azure AD to authenticate users.
However, Azure Virtual Desktop hosts still had join to Active Directory domains.
Image Credit: Microsoft
This is All Getting a Bit Complicated
Azure Virtual Desktop was released September 2019, known as Windows Virtual Desktop at the time. With Azure Virtual Desktop, users must be synced to Azure AD, and Azure Virtual Desktop hosts must be joined to either AD DS or Azure AD DS. This presented a problem as companies had to go through the process of authenticating twice: first to Azure AD to authenticate access to the Azure Virtual Desktop service, and second to authenticate against the computer account for the domain. This was known as a double logon, which inevitably begged the question, “Wouldn’t it be great if we could authenticate against only one service?”
Enter Azure AD Join
In September 2021, Microsoft released Azure AD Join for Azure Virtual Desktop hosts. This introduced the capability to Azure AD Join an Azure Virtual Desktop host, which takes away the requirement to deploy either Azure AD DS or AD DS into an Azure environment.
Before you get too excited, the users must still be synced into Azure AD from Azure AD DS or AD DS if you want to use FSLogix profiles. Many do, and will still need to deploy these for now. This is a limitation which Microsoft is working to unblock that will hopefully be remedied later this year. For now, though, it gives us the ability to Azure AD Join our session hosts and to not have line of sight of our domain controllers. Not having to have line of sight of our domain controllers means that we do not have to deploy additional network infrastructure to ensure connectivity to the domain controllers, for example, site-to-site domain controllers
What about FSLogix Profiles?
Eagle-eyed readers of this article by now will have thought, “If I have my FSLogix profile sitting on an Active Directory storage account, how is logging into my session using my Azure AD credentials going to work?”
Well…Microsoft also recently released the capability to Azure AD Join storage accounts into public preview! This means that if session hosts are Azure AD Joined, and the storage account containing the FSLogix profiles is Azure AD Joined, it will all work like magic!
The process of performing Azure AD Join is quite complicated to get to the above ideal scenario, but Nerdio makes it easy through automation – a screenshot of Nerdio Manger for Enterprise is below to illustrate. Note Azure AD Join is currently in Public Preview so please only use this in non-production environments.
Once Azure Virtual Desktop hosts and storage accounts are Azure AD Joined, admins will only ever have to authenticate against Azure AD for a seamless experience.
Note, at this moment in time, the user must be synced from Active Directory Domain Services for this to work. Azure Active Directory Domain Services is not supported currently but will be in the future.
We all also now have the capability to auto-subscribe to the Azure Virtual Desktop feed via MEM Configuration which means a true single-sign on experience is possible for our end users.
I hope you enjoyed this post! Check back in a few weeks for Part 2 in this series on identity management in Azure. We will do a technical deep dive on how Azure AD Join is configured and some other things you need to think about when using the service.
For more information, please check out the following Microsoft resources: