Azure AD vs Azure AD Domain Services — key differences and limitations

By Jon Pratt and Andrei Pavlitchouk

Introduction

Inside the Microsoft ecosystem, the name Active Directory is synonymous with Identity.

Any organisation that uses any Microsoft business service, Azure, Microsoft 365 etc, or that runs any sort of Enterprise software on Windows Server, will be using some version(s) of Active Directory.

At Contino, we often find ourselves talking to our clients and even our peers, about identity and access management. And what we have discovered is that people often get confused about the different versions of Azure Active Directory.

It’s not surprising, considering Microsoft has three main products under the Active Directory banner. Two were designed specifically for the cloud — Azure AD (AAD) and Azure AD Domain Services (AADDS).

In this blog we will talk about the two Azure AD versions, explain what they are, their relative strengths and weaknesses in comparison with other Active Directory products. We will also provide some examples for the different types of setups, and talk at the end about some common mistakes or pitfalls to watch out for.

What is Active Directory?

We won’t go into too much detail here, as this article is intended for people that already have a working knowledge of Active Directory services, but as a quick recap:

Active Directory Domain Services (ADDS), more commonly referred to as simply Active Directory, is a centralised identity and access management service that runs as a role on a Windows server operating system.

If you need more information, check out these resources:

Active Directory Domain Services Overview

Active Directory Domain Services — MS Learn

Deploy and manage identity infrastructure

Enter, Azure Active Directory (AAD)

Azure Active Directory is Microsoft’s modern authentication and authorisation provider designed for the cloud providing the latest industry standards.

To quote Microsoft directly “Azure Active Directory is a cloud-based identity and access management service. This service helps your employees access external resources, such as Microsoft 365, the Azure portal, and thousands of other SaaS applications. Azure Active Directory also helps them access internal resources like apps on your corporate intranet network, along with any cloud apps developed for your own organisation.”

It is important to note that Azure Active Directory is not Active Directory, they are fundamentally different. Azure AD provides complementary capabilities that traditional Active Directory cannot do and vice versa.

To learn the complete difference between Active Directory and Azure AD, see Compare Active Directory to Azure Active Directory.

Like everything on Azure, AAD is constantly being improved and updated. For latest information see What’s new in Azure Active Directory.

Key features of AAD include

• Communication via REST over the internet
• Authentication using cloud based protocols — OpenID, oAuth2, SAML, WS-Fed
• Support for MFA, authenticator apps, FIDO keys etc
• Single identity provider for all SaaS or PaaS services
• Mobile device management
• Conditional Access Policy
• ID protection services
• Privileged ID Management (PIM)

Azure Active Directory Domain Services

Azure Active Directory Domain Services is a PaaS solution, providing managed domain services such as domain join, group policy, lightweight directory access protocol (LDAP), and Kerberos/NTLM authentication. This allows the use of essential domain services, without the need to deploy, manage and patch domain controllers in the cloud. Put simply, it is a managed domain.

With a managed domain, you must define a unique namespace (domain name) such as aaddscontino.io. Note that this is a prerequisite to enable forest level trusts, as names have to be unique.

If any organisation that has on-premises Active Directory Domain Services, uses Azure (so has Azure AD) and when deployed a Azure AD Domain Services managed domain, they would look like this:

For every Azure AD Directory Services instance, Azure deploys two Domain Controllers, into a dedicated virtual network, in a single region. This deployment is known as a replica set. There can be one, peered with other virtual networks, or can be multiple replica sets providing local login for applications, protecting if a region goes down.

Microsoft shares the responsibility with the client to manage the domain (controllers), with Azure AD Domain Services being a PaaS solution. All updates, backups, monitoring for these virtual domain controllers are vendor responsibility. As a result the overall administrative overhead of the environment is reduced for the client.

How does Azure AD Domain Services synchronise identities?

The managed domain has a one-way automatic sync from Azure AD. Azure AD provides the centralised set of users, groups and credentials. This is shown as (1) in the diagram below.

In a hybrid environment with on-premises Active Directory, Azure AD Connect synchronises identity information with Azure AD, which is then synchronised to the Azure Active Directory Domain Services managed domain. This is shown as (2) in the diagram below.

Azure AD DS replicates identity information from Azure AD, so it works with Azure AD tenants that are cloud-only, or synchronised with an on-premises Active Directory environment. The same set of Domain Services features exists for both environments.

• If you have an existing on-premises Active Directory environment, you can synchronise user account information to provide a consistent identity for users. To learn more, see How objects and credentials are synchronised in a managed domain.
• For cloud-only environments, you don’t need a traditional on-premises Active Directory environment to use the centralised identity services of Azure AD Domain Services.

You can expand a managed domain to have more than one replica set.

• Replica sets can be added to any peered virtual network in any Azure region that supports Azure AD Domain Services.
• Additional replica sets in different Azure regions provide geographical disaster recovery for legacy applications if an Azure region goes offline.

For more information, see Replica sets concepts and features for managed domains.

Forest concepts for Azure AD Domain Services

As explained, Azure AD Domain Services provides a sign-on experience for legacy, on-premises and line of business applications. Users, groups, password hashes of on-premises and cloud users are synchronised to the Azure AD Domain Services managed domain.

Whilst there is too much technical detail to add to this article, it is useful to understand that there are user forest and resource forest types in Azure AD Domain Services, see Resource forest concepts and features for Azure Active Directory Domain Services for a full explanation on the concepts, and use cases.

Limitations & things to consider when selecting a Active Directory technology:

Active Directory

• Needs to run on Windows Server — vm cost and licence costs.
• Each logical location / region of the network needs at least two domain controllers to be deployed, patched and monitored. Complexity increases with scale.
• Domain Controllers need to be able to replicate, and add to the administrative overhead.
• Enterprise software often depends on the legacy protocols provided by Active Directory.

Azure Active Directory

• Unable to use Kerberos/NTLM which might be required by enterprise applications.
• Unable to make LDAP/LDAPs requests to the directory service.
• Unable to use GPO’s to centrally manage servers.
• No Domain join in the traditional sense for Windows Servers.
• No Schema Extensions.
• No Forest trusts, one tenant per organisation.
• Best features cost money (CA, PIM, Identity threat protection).
• Only Azure AD joins for Windows 10 devices.

Azure Active Directory Domain Services

• No GPO replication from on-premises
• No Hybrid Azure AD Join
• No Enterprise or Domain Admin
• No Active Directory Certificate Services Support
• No Schema extension
• No Forest Trust
• Not Available outside of the virtual network in which it was deployed. Peering or replica sets required for geographically distributed Azure environments.
• No MSIX app attach support
• LDAP write back only within the managed domain (cannot update AAD or AD)
• Can get expensive depending on the size of domain (number of objects) and the amount of replica sets needs for highly available IAM services.

Comparing the different types of Active Directory, side by side:

Some Common Use Cases

Azure AD

• Used for Azure, Microsoft 365 and Dynamics 365.
• Provides modern SSO capability for products,
• Centralised IDP for 1000’s of other services in use in modern enterprise (Slack, Workday, Trello, Salesforce, Asana)
• Provides authentication services for an organisation’s own cloud applications.
• Provides AAD App Proxy
• Provides AAD Identity Protection

Azure AD with Azure AD Domain Services

• Organisation that is only using Azure Active Directory but needs a legacy application to work with the environment.
• A line of business application that needs to run on a server, which requires kerberos.
• A cloud product such as MSIX app attach on Azure Virtual Desktop that needs Kerboros to function.
• An organisation that wants to join its IaaS servers to a traditional domain service, and wants to use group policies for management and secure configuration.
• Azure AD Domain services could be a replacement If you don’t want the application to communicate with the on-premises Active Directory environment.
• There may be security or regulatory issues with syncing password hashes to the cloud from an on-premises environment.

Active Directory Domain Services, Azure AD & Azure AD Domain Services

• This is most likely scenario for organisations that are heavily vested in the Microsoft ecosystem.
• AD will sync (via AD connect) to Azure AD, and then Azure AD to Azure AD Domain Services.
• One key benefit in this scenario is the reduction in administrative overhead, with the Azure DC’s as a managed service.
• This scenario could be part of a roadmap that leads to the eventual removal of all on-premises infrastructure.
• Could be part of a hybrid environment with the organisation intending to run data centre and public cloud services, and that needs to stretch its IAM services with minimal additional overhead.

Some common mistakes that we have seen:

Thinking all AD types are the same

• Azure AD Domain Services is part of Azure AD. This does exist under the tenant but it is a separate resource.
• Azure AD is not AD domain services — any org that thinks it can just use Azure AD services, especially if that org has a legacy NT domain is incorrect.
• Azure AD Domain Services is close to traditional Active Directory Domain Services, but it is not exactly the same, there are limitations as has been touched on in this article. See Frequently asked questions (FAQs) about Azure Active Directory (AD) Domain Services for additional details.

Assuming that “in the cloud” means highly available.

• Assuming Azure AD Domain Services has high availability in the region by default. Replica sets need to be created to ensure high availability.
• An organisation not understanding the cost. To have 2 or more Azure AD Domain Services Enterprise SKU instances, cost needs to be scrutinised and approved.

Not making the right choice of SKU

• Picking the wrong SKU can have a negative impact such as cost. Azure AD Domain Services has three SKUs, with different recommended object counts (for performance) and other features, trusts, backup frequency etc.
• Whilst any SKU can support any total number of objects, performance of a high object Azure AD will be much worse on Free over Standard or Enterprise. Microsoft provides clear guidelines via Azure Active Directory Domain Services pricing.

Not taking advantage of PaaS if possible.

• Running VM’s to run AD DS inside Azure can be a lot of work. Patching, securing, monitoring etc all falls on the client operations teams. It also increases the attack surface in an environment. That’s why the PaaS Azure AD Domain Services is a good option.
• Organisations that have stringent security or regulatory requirements that might limit the ability to sync identities to the cloud can take advantage of Azure AD Domain Services by using the resource forest type and creating a one-way forest level trust.

In summary

Hopefully this gives you a better understanding of the difference between Azure Active Directory and Azure AD Domain Services.

Azure Active Directory provides the ability to manage and secure identity across PaaS and SaaS products and services. With Azure Active Directory Domain Services you retain the ability to support enterprise, on-premise, line of business applications that require the functionality that Azure AD cannot provide.

It is important to understand that one Active Directory product will likely not be enough.

A combination of two or more Active Directory products will need to be considered in order to meet the business needs.