The topic of “Directory” is a complex one. Microsoft’s multiple directory solutions and deployment models with extremely similar sounding names make matters even more confusing.
The goal of this article is to demystify each type of directory, explain what they are used for, and make recommendations on how to appropriately select the best technology based on use-case, architecture, and cost considerations.
Active Directory Definitions
Windows Server Active Directory (AD)
(What is often called “Active Directory”)
- The familiar Active Directory role on a traditional Windows Server machine that is managed with tools like Active Directory Users and Computers, Sites and Services, Domains and Trusts, and Group Policy Management.
- Contains user, group, contact, and computer objects
- Traditional Windows desktops and servers join this AD domain
- Users and Groups can be synchronized with Azure AD using the ADConnect tool from Microsoft.
Azure Active Directory (AAD)
(Microsoft Cloud Directory service)
- Despite its similar sounding name to traditional Active Directory, this is a different service that is hosted by Microsoft and is the top-level object in Microsoft Cloud (O365, D365 and Azure).
- Contains user, group, and contact objects.
- Windows 10 and newer computers can join AAD while older operating system machines cannot.
- Can be synchronized with a Windows Server AD (see above) via the ADConnect tool so the same username and password can be used for both.
- Supports Active Directory Federation Services (ADFS) where authentication requests in the Microsoft Cloud are redirected to AD for validation and then redirected back to the cloud to access resources.
Azure Active Directory Domain Services (AAD DS)
(Microsoft’s alternative to Windows Server AD in Azure)
- An Azure hosted, Microsoft managed AD.
- Most of the same capabilities as traditional, on-premises Windows Server AD with some limitations due to lack of administrative access to the actual domain controllers (Microsoft manages that).
- Synchronizes with AAD (which is synchronized with on an on-premises Windows Server AD) and allows VMs running in Azure to join it regardless of the type of Windows OS (e.g. Windows 10/8/7 or Server 2008/2012/2016/2019).
Nerdio Hybrid AD
(Nerdio’s technology that integrates Windows Server AD and AAD)
- An Azure hosted, Managed Service Provider (MSP) managed AD that is a native extension of an existing on-prem Windows Server AD.
- Fully automated deployment from the Nerdio Admin Portal.
- All capabilities of Windows Server Active Directory with full administrative access.
- Synchronized with AAD and supports ADFS.
- Enables seamless lift–and–shift migration of on-premise, domain-joined servers without joining another domain.
- Requires site-to-site VPN to on-prem AD for initial setup.
- Requires VMs to run Windows Server as a domain controller in Azure.
Customers with a cloud-only environment
Azure AD (AAD) is required to use any of the Microsoft Cloud services (e.g. Office 365, Windows Virtual Desktop (WVD), Dynamics 365, etc.). All user authentication when accessing these cloud services begins in Azure AD.
For organizations with “cloud native” deployments the user information (e.g. username, password, group membership, etc.) resides in AAD only and is not synchronized with any other directory. If the customer does not have on-prem, line-of-business application servers and is not looking to implement virtual desktops in Azure, this AAD-only scenario may be sufficient and fairly simple.
Customers with existing servers and applications and/or virtual desktops
Most customers start out with existing LOB applications running on-prem and want to migrate these workloads to Azure, reinstall them on new VMs running in Azure, or implement virtual desktops in Azure with RDS or WVD. In all these scenarios, AAD alone is not sufficient as LOB servers and virtual desktop VMs must join an Active Directory Domain Services domain to function and be manageable.
How do you go about enabling this AD functionality in Azure?
Do-it-yourself AD in Azure
Conceptually, the easiest way is to create an Azure deployment, connect to the on-prem network with site-to-site VPN, deploy a new VM in Azure, join it to the existing AD domain via the VPN, promote it to domain controller, and configure the proper sites/subnets/etc. What you end up with is an AD deployment that spans both the on-prem network and the Azure deployment with the ability to move server VMs from on-prem to Azure without having to rejoin them to a new domain and without disrupting users’ connectivity to these VMs.
The challenge with this deployment lies in the difficulty of implementation, the need to manage new domain controllers, and the cost of additional VMs to run these domain controllers. The advantage is the easy-to-understand deployment for anyone who has managed Active Directory before and complete flexibility with full administrative access.
To address the challenges with the do-it-yourself AD in Azure method, Microsoft introduced AAD DS—not to be confused with AAD.
AAD DS is a PaaS offering in Azure that is operated, monitored, and updated by Microsoft with administrators having limited access. The advantage of AAD DS is that it does not require VMs to be deployed and managed by the MSP and it does not rely on a VPN to synchronize with an on-premises domain.
When AAD DS is deployed in an Azure subscription, Microsoft creates a pair of highly-available domain controllers and synchronizes the user data with AAD.
AAD DS is a NEW domain that has in it read-only copies of users, groups, and password hashes that reside in AAD. It synchronizes this data at 20-minute intervals. Azure VMs can be joined to this new domain and existing usernames/passwords can be used to connect to these VMs since the user credentials are synchronized with AAD, which may be synchronized with an on-prem AD using ADConnect.
Here are some key things to keep in mind with AAD DS:
- Microsoft deploys and manages an Active Directory for you, you don’t have administrative access to it but can connect to manage it with traditional AD management tools (e.g. Group Policy Management, etc.).
- AAD DS is a new domain that has your existing domain’s user objects.
- User objects that are synchronized from AAD to this new domain are read-only. They can only be modified in the source AD (if ADConnect is in use) or AAD (if the customer is cloud-only).
- When you create VMs in Azure they join this new domain. They are not part of your existing domain that’s on-prem, only the new domain that’s in Azure.
- Servers that are joined to your existing on-prem domain are not part of the new AAD DS domain—only user objects are.
- When doing a lift-and-shift migration of a server from on-prem to Azure with AAD DS enabled, you need to join the server to the new domain and then existing users can be entitled to access it. This requires making changes to the server.
- You need a “management VM” running in Azure to manage your new AAD DS domain and DNS.
- Active Directory Federation Services (ADFS) functionality, which enables single-sign on in Office 365, is not supported.
- Directory Schema extensions are not supported.
- There is no way to failover the AAD DS domain to another Azure region in case of a region outage.
- Once deployed there is no way to pause AAD DS to save on costs without deleting the deployment.
Given the many limitations, complexities and cost considerations of the previously mentioned deployments, Nerdio created an alternative deployment scenario that incorporates the best elements of each deployment option.
Nerdio Hybrid AD fully automates the process of extending an existing Windows Server AD into Azure without any of the complexities of the do-it-yourself scenario. The result is a fully functional Windows Server AD running in Azure that is fully integrated into AAD but with full administrative access and no functional limitations.
Here are some key things to keep in mind with Nerdio Hybrid AD:
- The partner deploys Nerdio Hybrid AD after creating a site-to-site VPN tunnel via the Nerdio Admin Portal. The entire deployment process is automated. The result is a domain controller VM running in Azure and manageable in the Nerdio Admin Portal.
- The extended domain can be managed using all traditional tools like ADUC, ADSS, etc. with no functional limitation due to admin level access capability.
- Nerdio Hybrid AD enables the same domain to be available both on-prem and in Azure and requires no new domains to join VMs to.
- Since the same domain with all of the same objects (e.g. users, groups, computers, etc.) is available in both on-prem and Azure environments, servers can be lift-and-shifted as they are from on-prem to Azure (or even moved back) without any changes to the servers and their domain memberships. This allows applications to be tested in the cloud without any changes to the server and provide the flexibility to move workloads back on-prem if ever needed in the future. With AAD DS, once the VM is in Azure it cannot be moved back on-prem without moving it to the other domain.
- User objects and passwords can be modified on either domain controller: on-prem and in Azure. The two environments will automatically synchronize and will be kept in-sync with AAD via ADConnect.
- ADFS, SSO, and directory schema extensions are fully supported.
- Ability to failover authentication to another Azure region during a regional outage by using ASR and turning on the replicated domain controllers in the DR region.
- Domain Controller VMs can be stopped at any time to save on costs.
What about the cost?
AAD DS is a PaaS offering and is priced on an hourly basis (although it can’t be stopped without destroying it after it has been deployed) depending on the number of objects in the directory. The basic tier starts at $110/month and goes up to $1,168/month for larger deployments. In addition to the cost of AAD DS PaaS, you must factor in a management VM in Azure that needs to have all of the AD and DNS management tools installed on it. This could be a B2ms VM that starts at $27/month (with RI and AHU) and goes up to $79/month with pay-as-you-go (PAYG) pricing.
In contrast to AAD DS, do-it-yourself AD in Azure and Nerdio Hybrid AD only require one (or two) domain controller. For most deployments it could be the same B2ms VM that ranges from $27 to $79 per month just like the AD management VM needed for AAD DS.
You may also choose to add a secondary domain controller VM to double this cost. In most situations, the cost savings with Nerdio Hybrid AD will be >$110/month as compared to AAD DS.
Cloud-only organizations that do not have virtual desktops or LOB applications running on servers should consider using AAD only without the added cost and complexity of Windows Server AD or AAD DS.
Most customers of MSPs will not be able to get by with AAD only and will need AD capability to support Azure VM workloads. Do-it-yourself Windows Server AD in Azure is complex to implement and difficult to manage. AAD DS is a good option for automating the deployment and offloading some of the backend management to Microsoft. However, it comes with significant trade-offs due to lack of admin rights, the need to rearchitect existing server deployments when moving to Azure, and additional costs.
Nerdio Hybrid AD automates the deployment of AD in Azure, simplifies management, and provides MSPs with full AD functionality without any sacrifices. This enables easy lift-and-shift migrations and leaves the door open to moving workloads back on-prem if ever needed. It is also a more cost-effective deployment method as compared to AAD DS.
For more information, contact a Nerdio expert today.