The recent case which landed to my desk is all about Azure AD Domain Services (AAD DS). With customers I have been working with it has been quite rarely in use.
When start planning to migrate traditional/legacy workloads from on-premises to cloud and there is hybrid environment in place one of the main tasks are provide necessary authentication protocols and connectivity to realm for applications.
Before AAD DS was introduced the following options were available (and quite often admins still choose one of them):
- Deploy a site-to-site VPN connection between workloads running in Azure Infrastructure Services and the corporate directory on-premises.
- Extend the corporate AD domain/forest infrastructure by setting up replica domain controllers using Azure virtual machines.
- Deploy a stand-alone domain in Azure using domain controllers deployed as Azure virtual machines.
All of these approaches suffer from high cost and administrative overheard, referring to Microsoft:
Administrators are required to deploy domain controllers using virtual machines in Azure. Additionally, they need to manage, secure, patch, monitor, backup, and troubleshoot these virtual machines. The reliance on VPN connections to the on-premises directory causes workloads deployed in Azure to be vulnerable to transient network glitches or outages. These network outages in turn result in lower uptime and reduced reliability for these applications.
When Azure AD Domain Services was in preview mode I wrote a blog about it (November 2015). Things have changed a bit since then but main functionality is same.
What is Azure AD Domain Services
Basics:
- First of all, it is a stand-alone domain, not exact copy of you Azure AD and it’s not an extension of on-premises AD.
- Administrator does not need to manage, patch, or monitor domain controllers for this managed domain.
- There is no need to manage AD replication to this domain.
- Since the domain is managed by Azure AD Domain Services, administrators does not have Domain Administrator or Enterprise Administrator privileges on this domain.
Basically it’s an alternative solution in the cloud for workloads which needs services like domain join, group policy, LDAP, Kerberos/NTLM authentication. Some would say legacy stuff, but there are quite many applications out there which still needs these protocols for authentication purposes.
It’s a service where OS and HW level is fully maintained by Microsoft (deploy, manage and patch domain controllers), Customer is responsible from a service (PaaS thinking) and maintains application itself which in this case is Domain Services.
It’s available for both cloud-only and hybrid identity organizations.
Cloud Organizations
In cloud-only mode all identities, groups etc. are naturally managed only in cloud. Even organization is in cloud only mode there might be need to deploy IaaS VMs to Azure virtual network. If these VMs needs services like domain join, LDAP read, LDAP bind, NTLM and Kerberos authentication, and Group Policy admin can enable Domain Services to this same virtual network.
When enabled, all accounts and groups from Azure AD tenant are available in new AAD Domain Services. Bright side is that end-user can use corporate credentials to logon to the servers in the virtual network.
Hybrid Organizations
Most of the organizations I have worked with have a mix of cloud and on-premises resources. Quite many organizations are moving (or want at least) legacy applications to the cloud. Doing so, Domain Services is good alternative solution for more traditionally approaches.
From architectural point of view case is quite similar than in cloud-only scenario. Virtual network is needed for VMs and Azure AD Domain Services is available (associated) to this dedicated virtual network. Because we are talking about hybrid identity scenario all Identities, groups, etc. are synced from the on-premises AD via AAD Connect to Azure AD and still from AAD to Domain Services. With this solution users can logon to VMs with corporate credentials.
Password synchronization is mandatory for hybrid organizations to use Azure AD Domain Services.
Identity Model
There are several options to manage identities in Azure AD Domain Services depending deployment model. If you are using cloud-only identities Domain Services identities can be in cloud or also created directly to DS. Naturally, selected option is matter of identity management life-cycle processes and tools in use.
If using Hybrid Identity scenario options are same as in cloud mode except on-premises AD can be location for identities.
Summarize of options for account management are (even in Hybrid scenario):
- Create accounts to on-premises and sync them to AAD (hybrid)
- Create accounts to Azure AD (hybrid & cloud only)
- Create accounts directly to AAD Domain Services (hybrid & cloud)
Summary
AAD DS is alternative solution for more traditional approaches to provide legacy authentication protocols from the cloud to applications. Before making a decision I recommend reading these articles.
Azure AD Domain Services vs AD in IaaS
Part II coming up quite soon where I dig into deployment of AAD DS, stay tuned!
Sam's Corner 