Active Directory Domain Service, Azure Active Directory and Azure Active Directory Domain Service Explained

Active Directory Domain Service, Azure Active Directory and Azure Active Directory Domain Service

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
  • Multi-tenant
  • 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

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. 

Azure AD and Azure AD Domain Servcies

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.

Azure Active Directory

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

Service Comparison

Below is a break down of the services, features, and limitations.  This is not all-inclusive but provides an overview of how they compare.

Summary

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. 

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.