Active Directory in Azure: AD vs Azure AD vs Entra ID vs AAD DS
Active Directory does run in Azure — just not in the one form most people assume when they search for it. Untangle on-prem AD, the cloud identity service Microsoft now calls Entra ID, and the managed-domain-controllers product hiding behind a near-identical name, and the confusion clears in one sitting.
New to cloud? CAMPUX is a free, build-first course. Start here →
Active Directory works in Azure in three distinct ways, and conflating them is the single most common identity mistake we see in the bootcamp: cloud-native identity (Microsoft Entra ID, formerly Azure AD / AAD), managed domain controllers (Microsoft Entra Domain Services, formerly Azure AD DS), or your own domain controllers running on Azure virtual machines.
You searched "Active Directory Azure," "AAD Azure," or something close, and landed on a page about Entra ID. That is not a mistake — it is the naming soup Microsoft cooked over a decade of rebrands. There are four different things people mean when they say "Active Directory" near the word Azure, and mixing them up is the single most common identity confusion we see in the bootcamp. When someone on your team says "Azure AD" or "AAD," they mean Entra ID. Here is the whole soup, sorted, then the direct answer to whether AD itself works in the cloud.
AD vs Azure AD vs Entra ID vs AAD DS: the four things, sorted
Every AD-flavored name Microsoft has shipped fits in one of these four rows. Find the one you were actually searching for:
| Name | What it is | Protocols | Where it runs | When you use it |
|---|---|---|---|---|
| Windows Server Active Directory (AD, AD DS) |
The classic on-prem directory: domain controllers, OUs, Group Policy | Kerberos, NTLM, LDAP | Your own servers (or VMs you run) | Domain-joined Windows machines and legacy apps inside your network |
| Microsoft Entra ID (formerly Azure AD / AAD) |
The cloud identity service — the one your Microsoft 365 and Azure portal logins use | OAuth 2.0, OpenID Connect, SAML | Microsoft-managed SaaS; nothing for you to host | Sign-in, SSO, MFA, and Conditional Access for cloud and web apps |
| Microsoft Entra Domain Services (formerly Azure AD DS / AADDS) |
Managed domain controllers hosted in Azure, fed from your Entra ID tenant | Kerberos, NTLM, LDAP | Azure, as a paid managed service | Lifted-and-shifted servers or legacy apps that must domain-join or bind LDAP in the cloud |
| Microsoft Entra (the family name) |
The umbrella brand: Entra ID plus Permissions Management, External ID, Verified ID, and more | Varies by product | Microsoft cloud | Marketing and licensing docs — "Entra" alone means the product family, not a service |
Two of those rows do Kerberos and LDAP; two do not. That single detail resolves most of the arguments. The rest of this page unpacks each row, starting with the direct answer to whether AD itself runs in Azure at all.
Does Active Directory work in Azure?
Yes, in three different ways — and picking the wrong one is expensive. If people just need to sign in to cloud and web apps, you do not need Active Directory in Azure at all: Entra ID is the cloud-native answer, and it is already there with your subscription. If a legacy workload genuinely needs Kerberos or LDAP in Azure, Entra Domain Services gives you managed domain controllers — covered in full below. And if you need full control — schema changes, forest trusts, real Domain Admin — you can simply run your own domain controllers on Azure VMs, connected to on-prem over VPN or ExpressRoute; that is ordinary AD DS that happens to live in the cloud, with all the patching still on you.
Most real organizations do none of these exclusively. They keep AD on-prem as the source of truth and sync identities up to Entra ID with Microsoft Entra Connect, so one account works in both worlds. That hybrid pattern has its own moving parts — sync scope, password hash sync versus pass-through authentication, what happens during a migration — covered in hybrid identity with Entra Connect.
It is not on-prem Active Directory
This is the confusion that trips up everyone coming from a Windows shop, so be clear about it. Entra ID — the cloud service most people mean when they say "Azure AD" or "AAD" — is not a cloud-hosted copy of the Active Directory Domain Services (AD DS) you ran on a domain controller. The name overlaps; the technology does not. AD DS is built around domains, organizational units, Group Policy, and Kerberos — it joins Windows machines to a domain and pushes configuration down to them. Entra ID does none of that in the same way. It has no OUs, no GPOs, and it is not a domain controller. It is identity for the cloud and the web: it speaks OAuth 2.0, OpenID Connect, and SAML, and it authenticates people and workloads to HTTP-based applications. If you genuinely need Kerberos or LDAP in the cloud for a legacy app, that is a different, separate product (Microsoft Entra Domain Services, next) — not Entra ID itself.
| Microsoft Entra ID | Active Directory (AD DS) | |
|---|---|---|
| Manages | Cloud & web identities | Domain-joined Windows machines |
| Protocols | OAuth 2.0, OpenID Connect, SAML | Kerberos, NTLM, LDAP |
| Structure | Flat directory of users, groups, apps | Domains, OUs, forests |
| Policy | Conditional Access | Group Policy (GPO) |
| You run | Nothing — Microsoft-managed SaaS | Your own domain controllers |
| Devices join by | Entra join / registration | Domain join |
On-prem Active Directory Domain Services manages domain-joined Windows machines with OUs, Group Policy, and Kerberos. Entra ID manages cloud and web identities with tokens, OAuth, and modern protocols. They often run side by side and sync users between them, but they are not the same service and one does not replace the other.
Entra ID vs Entra Domain Services (Azure AD DS)
This is the pairing that generates the "AAD vs AADDS" searches, and the names could hardly be more confusable. Microsoft Entra Domain Services — formerly Azure AD Domain Services, AAD DS, AADDS — is not Entra ID, and it is not the on-prem AD DS you run yourself. It is a paid managed service that stands up two actual domain controllers inside an Azure virtual network for you. Microsoft patches them, backs them up, and keeps them replicated; you never get Domain Admin on them, and you never RDP into them. User accounts flow into the managed domain one way, synced from your Entra ID tenant — you do not create users in AAD DS directly.
What you get in return is the legacy protocol surface Entra ID deliberately does not have: Kerberos, NTLM, LDAP bind and read, domain join, and a subset of Group Policy. That matters in exactly one situation — you are moving old servers or applications into Azure and they refuse to work without a domain. A lifted-and-shifted Windows VM that must domain-join, a line-of-business app that authenticates over LDAP, a service that assumes Kerberos: those cannot talk OAuth to Entra ID, and rewriting them may not be on anyone's budget. AAD DS is the honest answer there, and pretending Entra ID alone will cover it wastes weeks.
The decision rule we teach: modern app, use Entra ID; legacy protocol requirement in the cloud, use Entra Domain Services; big estate with existing domain controllers, consider extending your own AD onto Azure VMs instead — AAD DS has real limits (no schema extensions, no forest trusts in most configurations, no Domain Admin) that make it a fit for self-contained legacy workloads, not a full replacement for a serious on-prem forest. Check current Microsoft Learn docs before you commit; the feature edges move.
Is Azure AD the same as Entra ID?
Yes — the same product, renamed. Microsoft rebranded the whole Azure AD family to Entra in July 2023, and nothing functional changed: your tenant ID, application IDs, licenses, and the API endpoints (login.microsoftonline.com, graph.microsoft.com) are all as they were. When a script, an exam question, or a five-year-old Stack Overflow answer says Azure AD or AAD, read it as Entra ID. That is one line of a longer story — why Microsoft did it, what happened to the PowerShell modules, and the terms that still say "Azure AD" years later — and it gets its own page, because it answers a different question than this one: Azure AD vs Entra ID: what actually changed.
What it actually does
Entra ID is an identity provider. It answers two questions, every time, for every sign-in. Who are you (authentication) and what are you allowed to reach (authorization). It holds the directory of users, groups, and applications for your organization, and it is the thing that checks a password, prompts for a second factor, and hands back a token that other services trust. Every Entra directory starts with a domain like contoso.onmicrosoft.com, and you add your own custom domains on top. If you pay for Microsoft 365 or an Azure subscription, you already have an Entra tenant whether you asked for one or not — every tenant is automatically an Entra tenant.
It is the front door for the whole Microsoft cloud. One identity, checked once, that the Azure portal, Microsoft 365, and thousands of SaaS apps all agree to trust.
Where you meet it as a cloud engineer
You do not admire Entra ID from a distance — you touch it on ordinary workdays. Three places come up constantly. First, RBAC principals: when you grant someone access to a resource group, the user or group you assign the role to lives in Entra ID, and the role decides what they can do (see Owner, Contributor, and Reader). Second, app registrations and service principals: when an application or pipeline needs to authenticate to Azure, it gets an identity in Entra ID — that is the difference between a managed identity and a service principal. Third, Conditional Access: the policies that say "require multi-factor authentication from outside the office" are Entra ID rules that run at sign-in (start with Conditional Access basics). Identity is the control plane; you are configuring it whether you realize it or not.
What is Entra ID used for
Beyond the abstract "identity provider" label, here is the concrete list of jobs Entra ID does in a real organization:
- Single sign-on to Microsoft 365, the Azure portal, and thousands of SaaS apps — one login, reused everywhere.
- MFA and Conditional Access — proving identity with a second factor, and deciding when to demand it (see Conditional Access vs MFA).
- User and group management — the directory of accounts and groups you assign licenses and access to.
- App registrations and service principals — identities for your own apps, scripts, and pipelines to authenticate with.
- B2B guest access — inviting partners and contractors in with their own credentials, no second account.
- Device identity — registering or joining laptops and phones so Conditional Access can check whether a device is managed.
If you use Microsoft 365 email, sign into the Azure portal, or click "Sign in with Microsoft" on a third-party site, Entra ID is the service handling it.
What is an Entra tenant
A tenant is your organization's dedicated instance of Entra ID — one isolated directory that holds your users, groups, and app registrations and nobody else's. Every tenant has a globally unique tenant ID (a GUID) and a default domain like contoso.onmicrosoft.com. Most organizations run exactly one tenant, and your Azure subscriptions and Microsoft 365 all trust that single tenant for sign-in. You can see which tenant you are in from the directory switcher at the top of the Microsoft Entra admin center or Azure portal; switching tenants means signing into a completely separate directory.
Microsoft Entra External ID
Microsoft Entra External ID is the part of Entra built for identities that are not your employees. It covers two cases that used to be separate products. The first is B2B collaboration — inviting a partner or contractor as a guest so they sign in with their own work or Microsoft account and you never manage a password for them. The second is customer identity (CIAM), the successor to Azure AD B2C: sign-up and sign-in for the external users of an app you build, with social logins and custom-branded pages. Same identity platform, pointed outward instead of at staff.
Microsoft Entra Verified ID
Microsoft Entra Verified ID is Microsoft's implementation of verifiable credentials — digital, cryptographically signed proofs a person holds and presents, like a tamper-evident version of a badge or diploma. An issuer (an employer, a school) signs a credential; the holder keeps it in a wallet; a verifier checks the signature without calling back to the issuer. It is a niche feature you will not touch on day one, but it shows up in identity roadmaps, so know that it is decentralized-identity tooling, not a core sign-in feature.
Microsoft Entra Connect
Microsoft Entra Connect (formerly Azure AD Connect) is the sync agent you install on-premises to bridge a legacy Active Directory to Entra ID. It copies users and groups up to the cloud on a schedule so people use the same identity in both places, and with password hash sync or pass-through authentication they sign into cloud apps with their existing on-prem password. This is what makes a hybrid identity setup work — on-prem AD stays the source of truth for accounts while Entra ID handles cloud sign-in. There is also a lighter agent, Entra Cloud Sync, for simpler topologies.
The three hybrid sign-in methods
Entra Connect copies who exists up to the cloud, but that is not the same as deciding where the password gets checked. That second decision is the sign-in method, and a hybrid tenant has three choices. This is the table worth memorizing, because it is the whole topic and it shows up in both exams and design reviews.
| Pass-through authentication | Password hash sync | Federation (AD FS) | |
|---|---|---|---|
| Where the password is checked | On-premises AD, in real time, via an agent | In the cloud, against a synced hash | On-premises, by your AD FS farm |
| Does password material reach the cloud? | No | Yes — a hash of the password hash | No |
| Infrastructure you run | Entra Connect plus a lightweight agent (three recommended) | Entra Connect only | Entra Connect plus AD FS servers, proxies, certificates, load balancers |
| Survives an on-premises outage? | No — sign-ins fail unless hash sync is enabled as backup | Yes — the cloud validates on its own | No — the farm must be up |
| Leaked-credential detection | Not on its own | Yes | Not on its own |
| Operational weight | Low | Lowest | High |
| Microsoft's stance | Fine when on-premises validation is required | Recommended default | Legacy — migrate off where you can |
Hash sync asks the cloud to check the password. Pass-through asks the closet server. Federation asks a whole farm you now have to babysit.
Pass-through authentication is the one people find hardest to picture, and the mechanism is smaller than the name suggests. You install a small Windows service on a server inside your network that can reach a domain controller, and it makes an outbound connection to Entra which it holds open. No inbound firewall ports, no public endpoint, nothing exposed to the internet — a detail interviewers like to hear unprompted.
At sign-in, Entra collects the username and password, encrypts the password with the agent's public key, and drops the request into a queue the agent is already listening on. The agent decrypts it and hands it to Active Directory the ordinary way. AD says valid or not — including whether the account is locked, disabled, expired or outside its permitted sign-in hours — and the agent relays that verdict back. The password is validated at home and discarded; it is never written to Entra.
A single agent is a single point of failure: if that server reboots for patches, cloud sign-ins stall. Microsoft recommends at least three authentication agents on separate servers. This is the thing teams get wrong most often — they pilot with one agent, ship it, and discover the fragility during the first patch night. It is also why many tenants enable password hash sync alongside pass-through as a fallback, so an on-premises outage degrades sign-in rather than stopping it.
The Microsoft Entra admin center
The Microsoft Entra admin center (entra.microsoft.com) is the dedicated portal for managing identity — users, groups, app registrations, Conditional Access, and licensing all live here. It is the identity slice of the Azure portal pulled into its own console. You can still reach the same blades from the Azure portal, but the admin center is where identity work is meant to happen now.
Entra ID and the Microsoft Authenticator app
The Microsoft Authenticator app is one of the second factors Entra ID checks during sign-in. When a Conditional Access policy or Security Defaults demands MFA, Entra sends a push to the app and you approve it (or type the matching number), or you read a rotating one-time code from it. The app is the client; Entra ID is the service that registers it against your account and decides when to challenge it. It can also do passwordless sign-in, where the app replaces the password entirely rather than adding to it.
The tiers, briefly
Entra ID comes in three editions, and the free one does more than you expect: core directory, SSO, and MFA are already there with any Microsoft cloud subscription. P1 adds Conditional Access and group-based licensing; P2 adds the risk-based features — Identity Protection and Privileged Identity Management — for admin and other high-risk accounts. So if someone asks whether you need an Entra ID P2 license, the honest answer is: only if you want Identity Protection or Privileged Identity Management, because everything up to and including targeted Conditional Access lives at P1. The full buying breakdown, with the feature table and the mixed-licensing play most organizations actually use, is its own page: Entra ID P1 vs P2 — which license do you actually need.
The takeaway
Active Directory works in Azure, but not as a single thing — it is three products wearing overlapping names. Microsoft Entra ID (formerly Azure AD / AAD) is the cloud identity service that proves who you are and decides what you can reach across the Azure portal, Microsoft 365, and thousands of SaaS apps; it is not a cloud version of on-prem Active Directory Domain Services — no OUs, no Group Policy, no domain controller. When a legacy workload in Azure genuinely needs Kerberos or LDAP, the answer is the third product, Microsoft Entra Domain Services, not Entra ID stretched past its design. Keep the four names in the table straight, learn where Entra ID sits (RBAC principals, app registrations, Conditional Access), and you understand the layer every other Azure permission ultimately hangs from.
Questions people also ask
Is Azure AD the same as Microsoft Entra ID?
Yes. In 2023 Microsoft renamed Azure Active Directory to Microsoft Entra ID, and the only thing that changed is the name. The service, tenants, features, APIs, endpoints, sign-in URLs, licensing, and pricing all stay the same. When a script, exam, or colleague says Azure AD, they mean Entra ID — you are looking at one product with two labels.
What does AAD mean in Azure?
AAD is the old abbreviation for Azure Active Directory, Microsoft's cloud identity service — renamed Microsoft Entra ID in 2023. It is not on-premises Active Directory, and it is not Azure AD Domain Services (AAD DS); those are two separate products covered in the table above. When you see AAD in a script, doc, or exam question, read it as Entra ID.
What is the difference between Active Directory and Azure Active Directory?
Active Directory Domain Services runs on-premises and manages domain-joined Windows machines with organizational units, Group Policy, and Kerberos. Azure AD — now Microsoft Entra ID — is a cloud identity service that authenticates people and apps over OAuth, OpenID Connect, and SAML. AD is domain-centric and lives on your servers; Azure AD is identity-centric and runs as a managed cloud service. They often sync and run side by side.
Is Entra ID a domain controller?
No. Entra ID is a multi-tenant cloud service, so there are no domain controllers for you to deploy or maintain, and it does not do Group Policy or Kerberos the way a domain controller does. If you need actual managed domain controllers in Azure for a legacy app, that is a separate product called Microsoft Entra Domain Services, not Entra ID itself.
Does Entra ID replace on-prem Active Directory?
Not directly. Entra ID handles cloud and web identity, while on-prem Active Directory still manages domain-joined machines, Group Policy, and Kerberos-based apps inside your network. Most organizations run both and sync users between them with Entra Connect. One does not swap in for the other; they cover different jobs and commonly operate together in a hybrid setup.
What is Azure Active Directory Domain Services?
Azure Active Directory Domain Services — now called Microsoft Entra Domain Services — is a paid Azure service that runs managed domain controllers for you, with accounts synced one way from your Entra ID tenant. It provides Kerberos, NTLM, LDAP, and domain join so legacy applications can run in the cloud without you hosting domain controllers. It is a separate product from both Entra ID and on-prem Active Directory.
Does Active Directory work in the cloud?
In three ways. Entra ID is the cloud-native identity service for modern sign-in and needs no domain controllers. Microsoft Entra Domain Services provides managed domain controllers in Azure when a legacy app needs Kerberos or LDAP. And you can run your own domain controllers on Azure VMs for full control. Most organizations keep AD on-prem and sync identities to Entra ID with Entra Connect.
What is Microsoft Entra ID used for?
Entra ID is used for single sign-on to Microsoft 365, Azure, and SaaS apps; for MFA and Conditional Access; for managing users, groups, and licenses; for giving apps and pipelines their own identities through app registrations; for inviting external partners as B2B guests; and for registering devices. In short, it is the identity and access layer for everything in the Microsoft cloud.
Do I need an Entra ID P2 license?
Only if you want Identity Protection (risk-based Conditional Access) or Privileged Identity Management (just-in-time admin roles and access reviews). Core directory, SSO, and MFA are free; targeted Conditional Access needs P1; the risk and privileged-access features are what push you to a P2 license. Pick the tier by the feature you actually need.
What is a Microsoft Entra tenant?
A tenant is your organization's dedicated, isolated instance of Entra ID — one directory holding your users, groups, and apps, identified by a unique tenant ID and a default domain like contoso.onmicrosoft.com. Every Azure subscription and Microsoft 365 plan trusts one tenant for sign-in, and most organizations run exactly one.
What is Microsoft Entra Connect?
Entra Connect (formerly Azure AD Connect) is an on-premises sync agent that copies users and groups from a legacy Active Directory up to Entra ID, so people use one identity in both places. With password hash sync or pass-through authentication they sign into cloud apps with their existing on-prem password. It is what makes a hybrid identity setup work.
What is Azure AD pass-through authentication?
Pass-through authentication is a hybrid sign-in method that validates a user's password directly against your on-premises Active Directory through a lightweight agent, so no password material is stored in the cloud. The agent holds an outbound connection to Entra, receives the encrypted password at sign-in, checks it with AD, and relays the verdict back. It is one of three options alongside password hash sync and federation. Run at least three agents, since a single one is a single point of failure.
What is the difference between pass-through authentication and password hash sync?
Password hash sync copies a hash of the password hash into Entra and lets the cloud validate sign-ins on its own, which means sign-in keeps working during an on-premises outage and leaked-credential detection works. Pass-through authentication keeps validation on-premises in real time, so no password material reaches the cloud and account lockouts and sign-in-hour restrictions apply immediately, but sign-ins fail if your agents or domain controllers are down. Microsoft recommends hash sync as the default and pass-through where on-premises validation is a requirement.