Academmia

Directory services in Azure: Microsoft Entra ID and Microsoft Entra Domain Services

az-900•mixed•

Azure architecture and services

Directory services in Azure: Microsoft Entra ID and Microsoft Entra Domain Services

Short Summary

In this lesson, I compare Microsoft Entra ID and Microsoft Entra Domain Services. I’ll learn what each service is for and how they relate to Active Directory Domain Services (AD DS). I’ll also practice choosing the right service based on what an app or workload expects.

Learning Objectives

By the end of this lesson, you will be able to:

  • Define Microsoft Entra ID and describe what it is used for.
  • Describe Microsoft Entra Domain Services and the problem it solves.
  • Differentiate Microsoft Entra ID from Active Directory Domain Services (AD DS).
  • Choose the right service for common “cloud apps vs. domain workloads” scenarios.
  • Identify access controls and admin permissions you still need to configure.

Core Concepts

A directory service stores identity information (users, groups, and related attributes) and helps systems answer two questions:

  • Who are you? (authentication)
  • What are you allowed to do? (authorization)

In the AZ-900 identity topic, the two “directory service” names you’ll see most often are Microsoft Entra ID and Microsoft Entra Domain Services.

Microsoft Entra ID

Microsoft Entra ID (formerly Azure Active Directory (Azure AD)) is a cloud-based Identity and Access Management (IAM) service. I use it to:

  • Manage users, groups, and app registrations in the cloud
  • Handle sign-in (authentication)
  • Provide Single Sign-On (SSO) to cloud apps (for example, Microsoft 365 and many Software as a Service (SaaS) apps)
  • Apply access rules like Conditional Access (for example, “require Multifactor Authentication (MFA) from outside the office”)

A key mindset shift: Entra ID is not a “Windows domain in the cloud.” It’s built for cloud identity and cloud app access.

Active Directory Domain Services

Active Directory Domain Services (AD DS) is the traditional “Windows domain” model. It typically involves domain controllers (DCs) and features many Windows and legacy apps expect, such as:

  • Domain join
  • Group Policy
  • Lightweight Directory Access Protocol (LDAP)
  • Kerberos authentication
  • NT LAN Manager (NTLM) authentication

This matters because it’s very common to assume “Entra ID = AD DS, just hosted by Microsoft.” That’s not how it works.

Microsoft Entra Domain Services

Microsoft Entra Domain Services (formerly Azure AD Domain Services (Azure AD DS)) provides managed AD DS-style domain capabilities in Azure, such as domain join, Group Policy, LDAP, and Kerberos/NTLM authentication—without you deploying, managing, or patching domain controllers yourself.

Two details that help me keep it straight:

  • Domain Services creates a managed domain backed by Microsoft-managed domain controllers in an Azure region.
  • It integrates with Entra ID and synchronizes users/groups/credentials one-way from Entra ID into the managed domain (so apps and VMs can use AD DS-style features without running my own DCs).

A simple rule of thumb

  • If the scenario is about users signing in to cloud apps and access control for those sign-ins, think Microsoft Entra ID.
  • If the scenario is about VMs or legacy apps needing domain join, LDAP, or Kerberos/NTLM, think Microsoft Entra Domain Services.

And a final reminder: using these services doesn’t automatically “do security for me.” I still decide and configure the access rules and admin permissions that match the business requirement.

Practical Understanding

Practical Situation 1: When you see “SSO to SaaS apps,” think Entra ID

A company uses Microsoft 365 and multiple SaaS applications and wants users to sign in once and access everything. They also want centralized user and group management in the cloud.

How to think about it: This is classic cloud identity and app access control. Microsoft Entra ID is the cloud directory that provides authentication and SSO for cloud apps and services.

Common misunderstanding: “Because it’s called a directory, it must be a domain controller.” Entra ID is a cloud IAM service, not an AD DS domain controller.

Practical Situation 2: When you see “domain join + LDAP/Kerberos,” think Entra Domain Services

A team is moving a legacy application to Azure. The application expects a traditional domain environment and relies on domain join and LDAP, plus Kerberos/NTLM authentication.

How to think about it: These are AD DS-style requirements. Microsoft Entra Domain Services provides managed domain capabilities in Azure so the workload can use domain join and classic protocols without running domain controllers yourself.

Common misunderstanding: “Entra ID alone will satisfy LDAP and Group Policy needs.” Entra ID focuses on cloud identity and cloud app access; AD DS-style domain features point to Entra Domain Services (or AD DS you manage yourself).

Practical Situation 3: When you see “cloud apps + legacy domain apps,” think “use both, for different jobs”

A company wants Entra ID for cloud app sign-in and SSO, but they also need domain capabilities for some workloads they’re moving to Azure.

How to think about it: This is a split-responsibility setup. Entra ID remains the foundation for cloud identities and cloud app access. Entra Domain Services can be used for Azure workloads that need managed domain features.

Common misunderstanding: “One of these services replaces the other.” They solve different problems and can be used together when you have both cloud-app and domain-based needs.

Practical Situation 4: When you see “Conditional Access” or “admin permissions,” assume you must configure it

A security requirement says: “Only allow sign-in from compliant devices” or “Only admins can manage identity settings.” The company is using Entra services and assumes those rules are automatic.

How to think about it: Entra gives me the tools, but I still define the rules. For Entra ID, that means configuring Conditional Access policies and assigning administrative roles. For Domain Services, that also means controlling who can administer the managed domain (for example via the appropriate admin group) and who can manage domain-joined resources.

Common misunderstanding: “Managed service means security policy is handled for me.” Managed reduces infrastructure work, not responsibility for access rules and permissions.

Common Pitfalls

  • Mistake: Confusing Microsoft Entra ID with Active Directory Domain Services (AD DS). Correction: Entra ID is cloud IAM for identities and cloud app access; AD DS is the traditional domain model with domain controllers and classic domain protocols/features.

  • Mistake: Treating Microsoft Entra ID as a drop-in replacement for AD DS. Correction: “Drop-in replacement” would imply domain join, Group Policy, LDAP, and Kerberos/NTLM are covered the same way; Entra ID is designed for cloud sign-in and app access, not full domain services.

  • Mistake: Assuming Microsoft Entra Domain Services is the same as Entra ID. Correction: Entra Domain Services provides managed AD DS-style features for Azure workloads; Entra ID provides cloud identity, authentication, and SSO for apps.

  • Mistake: Expecting access policies and admin permissions to be configured automatically. Correction: I still define Conditional Access policies (Entra ID) and assign admin permissions/roles/groups so only the right people can manage identity and domain-related settings.

  • Mistake: Choosing a directory service based only on “where the app runs” (cloud vs. on-prem) instead of “what the app expects.” Correction: The deciding factor is usually the authentication model: cloud app sign-in/SSO vs. domain-based requirements like LDAP/Kerberos and domain join.

  • Mistake: Assuming Domain Services gives me the same level of control as running my own AD DS domain controllers. Correction: Domain Services is a managed domain. That’s the point: Microsoft manages the domain controllers, and some deep domain admin capabilities are intentionally not available.

Check Your Understanding

  1. Explain (in your own words) the difference between “cloud identity for apps” and “domain services for computers and legacy apps.”
  2. Write a one-sentence rule you would use to decide between Entra ID and Entra Domain Services.
  3. Think of one real app you use (work or personal). Does it need SSO to a cloud service, or does it “expect a Windows domain”? Why?
  4. Describe a scenario where using both Entra ID and Entra Domain Services makes sense.
  5. List two examples of configuration you still need to do even when using Entra services (think policies and permissions).

Further Reading