Microsoft has a couple of options available for identity and authentication services including Active Directory Domain Services, Azure Active Directory, and Azure Active Directory Domain Services. This can lead to confusion, especially considering three of the options have “Active Directory” in the name. It also leads to the question “do we still need domain controllers?” This post reviews these three different options, outlining the functionality and comparing how they work together in Microsoft and Azure.
Video version for those who don’t want to read:
Active Directory Domain Services
First up is Active Directory Domain Services, commonly referred to as Active Directory or just AD. This service has been around since Server 2000 and has provided directory and authentication service for many organizations for the past 20 or so years. Some major characteristics of Active Directory include:
- Hierarchical directory
- Extensible schema
- Stores objects such as users, computers, groups and security principals
- Group Policy for user and device management
- Highly available, multi-master
- Supports Kerberos, LDAP, and NTLM authentication
- Based on standards such as LDAP and DNS
- Requires dedicated domain controllers
Active Directory has been around for a long time. It’s well documented and reliable. Active Directory requires dedicated servers, multiple if high availability is required. There are other requirements that increase management overhead including managing backups, patching, OS upgrades, network for replication and staff to administrate users. From that perspective, I can see how some may be interested in an alternative.
Azure Active Directory
Next is Azure Active Directory (Azure AD). If an organization uses O365 or Azure, it uses Azure AD. Azure AD is significantly different from Active Directory Domain Services and the two services complement each other. While AD support network-based authentication like Kerberos and NTLM, Azure AD supports web-based authentication such as OAuth and SAML. Characteristics specific to Azure AD include:
- Cloud-based identity solution
- Used for Office 365 and Azure user management
- Contains users, groups, applications, and security principals
- Web-based OAuth 2.0, SAML 2.0 and Open ID authentication
- Microsoft GRAPH and API management
- Flat architecture
- Not extendable
- No GPO’s
- 4 license options, free, Basic, P1 and P2
- Tennant based, tied to an enrollment
AD DS and Azure AD
Let’s pause for a minute with the overview and go over how these two directory services complement each other. Active Directory (the on-premises version) users network authentication like Kerberos and NTLM. Azure Active Directory is based on cloud authentication such as OAuth and SAML for accessing cloud-based services like O365.
Wouldn’t it be great if AD and Azure AD could synchronize so users and administrators don’t have to manage two different identities for service in the cloud and on-premises? Well, let me introduce you to AD Connect.
AD Connect is a small service that runs on an organization’s internal network that replicates ID’s and other attributes from Active Directory to Azure AD. It replicates password hashes to provide the same username and passwords for on-premises AD and Azure AD Services. It is capable of more than that, but that’s a different post.
Azure Active Directory Domain Service
Back to the third directory option, Azure Active Directory Domain Service (Azure AD DS). This is close to the traditional, on-premises AD we have been using for years, but hosted as a PaaS offering in Azure. Features of Azure AD DS include:
- Cloud-hosted PaaS
- LDAP, Kerberos and NTLM authentication
- Compatible with Windows AD DS
- Integrates with Azure AD
- No Domain or Enterprise Admin Account
- No extending the schema
- No Domain or Forest trust
- LDAP Read Only
Azure AD is the source for Azure AD DS management. Object added to and managed from Azure AD are replicated to Azure AD DS.
What happens when all three services are combined? In the configuration below, identities are created in AD, synchronized to Azure AD with AD Connect, and then Azure Active Directory Domain Served.
Why do this? Let’s say an organization has an IIS application that doesn’t support modern authentication and needs to be moved quickly to Azure without having to deploy a Domain Controller in Azure. With the model below, you can lift and shift that server into Azure without deploying an AD Server or relying on a VPN or Express route connection back to the internal network
Below is a break down of the services, features, and limitations. This is not all-inclusive but provides an overview of how they compare.
One question I get frequently is “are domain controllers still needed?” I’ve been in IT for 20 years and the qualified response is, “It Depends.”
If an organization is cloud-native with no servers on-premises and using Azure AD join along with a mobile device management solution like Intune to manage devices, Azure AD may be sufficient.
If an organization is cloud-native but has a 3rd party application that requires AD, it may be able to get away with Azure AD and Azure AD DS. The sticking point will be no Domain or Enterprise Admin. That may become hard to work around.
For the rest, companies that rely on traditional Active Directory for user management, need to extend the schema and rely on trust relationships, the will be stuck with Domain Controllers for some time to come. Azure AD DS can still be leveraged but will complement traditional Active Directory, not replace it.
Hopefully, this information helps you understand the different directory services offered by Microsoft and how they may be applied to an organization.