10.2 Cloud, On-Premises, and Hybrid Identity
Key Takeaways
- A cloud-only identity exists solely in Microsoft Entra ID and has no matching on-premises Active Directory account
- On-premises identity is Active Directory Domain Services (AD DS) on Windows Server: domains, Kerberos/NTLM, and Group Policy for forest resources
- Hybrid identity is one common user identity for authentication and authorization both on-premises and in the cloud, created by provisioning and synchronization
- Microsoft Entra Connect Sync and Microsoft Entra Cloud Sync copy users and groups into Entra; they do not by themselves decide how the password is checked
- Hybrid sign-in methods are password hash synchronization, pass-through authentication, and federation (typically AD FS) — and hybrid identity is not the same as hybrid work or hybrid cloud
Quick Answer: A cloud-only identity lives only in Microsoft Entra ID. On-premises identity is Active Directory Domain Services (AD DS) on Windows Server. Hybrid identity is one common user identity for sign-in on-premises and in the cloud, created by provisioning and synchronization with Microsoft Entra Connect Sync or Microsoft Entra Cloud Sync. Users then prove the password with password hash synchronization (PHS), pass-through authentication (PTA), or federation (AD FS).
The April 30, 2025 MS-900 outline asks you to describe cloud identity, on-premises identity, and hybrid identity concepts. Chapter 3 already used hybrid cloud (public Microsoft 365 connected to on-premises systems) and hybrid work (where people sit). This section is hybrid identity: where the account lives and how the user signs in. Those three “hybrid” words travel together in real companies. They are not the same answer.
Cloud-only identity
A cloud identity (cloud-only account) is created and managed in Microsoft Entra ID. There is no corresponding on-premises Active Directory object. Official hybrid-authentication guidance says organizations without an on-premises directory footprint typically create identities only in the cloud and do not need a hybrid identity solution.
Cloud-only is the default story for a new company that never ran a domain controller, for many Microsoft 365 Business tenants, and for identities that should not exist in the old forest (a contractor you do not want in AD DS, a break-glass admin you keep cloud-only on purpose). The user signs in with an Entra user principal name (UPN) such as adele@contoso.com. Password policy, MFA, and SSPR for that account are cloud concerns. There is nothing to write back to.
Exam signal: “we have no domain controllers and we will not build any.” The identity model is cloud-only. Do not deploy Connect “just in case.”
On-premises identity: Active Directory Domain Services
Active Directory Domain Services (AD DS) is the Windows Server directory. It gives you domains and forests, Kerberos and NTLM, Group Policy, LDAP, and domain-join for Windows PCs that live on the corporate network. Users sign in to file shares, line-of-business apps, and domain-joined PCs with that on-premises account.
AD DS is not Microsoft Entra ID. It is also not Microsoft Entra Domain Services, which is a managed cloud domain Microsoft operates when a legacy Azure workload still needs Kerberos/NTLM/Group Policy and cannot use modern Entra authentication. Entra Domain Services is a real product. MS-900 scenarios almost always mean either AD DS in your datacenter or Entra ID in the tenant, not the managed-domain special case.
Exam signal: “passwords and groups must stay authoritative in the Windows Server forest; laptops Group-Policy to a file server.” That is on-premises identity. It becomes hybrid only when you connect that forest to Entra.
Hybrid identity: one person, two environments
Official Learn definition: businesses run on-premises and cloud apps; users need access to both; managing two disconnected directories is painful. Microsoft’s identity solutions create a common user identity for authentication and authorization to all resources, regardless of location. That is hybrid identity.
Hybrid identity is accomplished through provisioning and synchronization. Provisioning creates, updates, and deletes the object when conditions change. Synchronization keeps on-premises user and group information matching the cloud. After sync, Adele is Adele in AD DS and in Entra. She does not keep two unrelated mailboxes of identity attributes.
Two Microsoft tools do that sync job:
- Microsoft Entra Connect Sync (often still said as Entra Connect / Azure AD Connect) is the long-standing on-premises sync server. It runs a full synchronization engine in your environment and is how most existing hybrid tenants were built.
- Microsoft Entra Cloud Sync is the newer cloud-managed path: you deploy one or more lightweight provisioning agents that make only outbound connections. Configuration, scheduling, and processing live in Microsoft Entra ID. Cloud Sync is Microsoft’s stated strategic direction for many new or multi-forest scenarios (including disconnected forests, typical after a merger).
Official note that saves marks: the authentication method is independent of the sync technology. Choosing Cloud Sync versus Connect Sync does not decide whether the password is checked in the cloud or on-premises. Sync creates the cloud object. A sign-in method proves the password.
You can also enable password writeback so an Entra password change or SSPR updates AD DS. Writeback is an optional hybrid feature, not the definition of hybrid identity.
Three hybrid sign-in methods
Microsoft Entra ID supports three authentication methods for hybrid identity. Two are cloud authentication (Entra handles the sign-in). One is federated authentication (Entra hands the sign-in to someone else).
Password hash synchronization (PHS) is the simplest cloud method. Connect (or the hybrid stack) synchronizes a hash of the on-premises password hash to Entra. Users type the same password they use on-premises. Passwords are never stored in clear text in Entra. Authentication happens in the cloud: Entra compares the sign-in to the stored hash. PHS typically rides the sync cycle (about every two minutes). It needs no extra auth servers. Microsoft recommends enabling PHS even if it is not your primary method, because it is a disaster-recovery path if on-premises auth dies and because ID Protection leaked-credential detection needs it. Trade-off: some on-premises account states (disabled, locked, expired password, logon hours) are not instant in the cloud; they wait for sync.
Pass-through authentication (PTA) is the other cloud method. A lightweight agent on one or more on-premises servers (Microsoft recommends more than one; three is the usual high-availability picture) validates the password directly against AD DS. The password is not stored in the cloud. Entra still orchestrates the sign-in, but the secret is checked on-premises. Choose PTA when the organization must enforce on-premises account state at the moment of sign-in — disabled, locked out, expired password, or outside permitted logon hours. Agents need outbound internet and unconstrained access to domain controllers; they do not belong in a locked-down perimeter network. PTA failover to PHS is not automatic; you switch the method if the agents cannot reach AD.
Federation, typically Active Directory Federation Services (AD FS), is not cloud authentication. Entra hands off validation to a trusted system. Users often see a redirect to the company AD FS farm (with Web Application Proxies in a perimeter network). Federation is the answer when you must keep a third-party MFA or identity provider, need DOMAIN\username style sign-in that cloud auth does not cover, or already operate a federation farm you are not ready to retire. It is the most infrastructure-heavy option: multiple AD FS servers, proxies, certificates, and health monitoring. Microsoft still tells federated customers to turn on PHS as a backup.
Comparison table
| Idea | Cloud-only | On-premises AD DS | Hybrid identity |
|---|---|---|---|
| Where the account is born | Microsoft Entra ID | Windows Server AD DS | AD DS, then synced to Entra |
| Where the user signs in | Cloud apps only (no forest) | Domain resources, file servers, domain-joined PCs | Both on-premises resources and Microsoft 365 |
| Sync tool | None | None | Connect Sync or Cloud Sync |
| How the Microsoft 365 password is proved | Entra password (or passwordless) | Not applicable to cloud apps until you go hybrid | PHS, PTA, or federation / AD FS |
| Hybrid sign-in method | Who validates the password | Extra on-premises auth kit | Exam signal |
|---|---|---|---|
| Password hash synchronization | Microsoft Entra ID in the cloud, using a synced hash | None beyond sync | Simplest; same password; leaked-credential / outage backup |
| Pass-through authentication | Entra asks an on-premises agent; agent asks AD DS | Two or three agents with outbound internet | Must honor lockout, expiry, and logon hours now |
| Federation (AD FS) | AD FS (or another trusted IdP), not Entra | AD FS farm plus perimeter proxies | Third-party MFA/IdP, DOMAIN\user, existing federation investment |
Seamless SSO can reduce extra prompts on domain-joined PCs when you use PHS or PTA. It is a convenience feature, not a fourth identity model.
Hybrid identity is not hybrid work or hybrid cloud
This is the trap Microsoft plants next to Chapter 3.
- Hybrid identity answers who the account is and how they authenticate across AD DS and Entra.
- Hybrid cloud answers where the workload runs — for example Exchange hybrid, or a file server plus OneDrive.
- Hybrid work answers where the person sits — some days in the office, some days at home.
A company can have hybrid work (laptops on kitchen tables) with cloud-only identities (no AD DS at all). A company can have hybrid cloud (some mailboxes still on-premises) only because it also built hybrid identity (Connect is required for Exchange hybrid). A company can sync identities and still run a public-cloud Microsoft 365 tenant. Do not pick “hybrid identity” because the stem mentioned remote employees. Do not pick “hybrid cloud” because the stem mentioned Entra Connect.
Device join words sit beside this topic and are not identity models: Microsoft Entra join (the PC’s identity is cloud-only) versus Microsoft Entra hybrid join (the PC is in AD DS and registered in Entra). Hybrid join is a device choice. It often appears with hybrid identity, but a hybrid-joined PC is not the definition of a hybrid user.
Realistic exam-style scenarios
Greenfield SaaS. A ten-person design studio has never owned a server. Everyone should use Microsoft 365. Cloud-only identities. No Connect.
Keep the forest. A manufacturer has 8,000 AD DS accounts, file servers, and line-of-business apps that need Kerberos. It is buying Microsoft 365. Hybrid identity with Connect Sync or Cloud Sync so people keep one account.
Simplest same password. The manufacturer wants the same password in Outlook on the web and on the shop-floor PC, with no extra auth servers. Password hash synchronization.
Honor lockout immediately. Security will not accept a disabled AD account still opening SharePoint for half an hour. Pass-through authentication, so AD DS is asked at sign-in. Keep PHS in the background as Microsoft recommends.
Existing AD FS and a third-party MFA server that only speaks federation. Federation. Do not pretend PHS hosts that third-party MFA natively.
Two disconnected forests after an acquisition. Cloud Sync is the exam-friendly modern answer for multi-forest / disconnected-forest sync. You are not asked to draw a Connect topology.
Work from home. Staff split time between office and home, but every account was born in Entra and there is no AD DS. That is hybrid work, not hybrid identity.
Exam traps
- Hybrid identity ≠ hybrid work ≠ hybrid cloud. Account and sign-in versus where people sit versus where the workload runs.
- Sync is not sign-in. Connect Sync / Cloud Sync copies objects. PHS, PTA, or AD FS proves the password.
- PHS does not send clear-text passwords. It syncs a hash of a hash.
- PTA does not store the password in the cloud. The agent asks AD DS.
- Federation is not “Microsoft validates the password in Entra.” Entra redirects to AD FS.
- Cloud-only is a valid enterprise model, not a toy. No forest required.
- AD DS is not Entra ID and not Entra Domain Services unless the stem is about a managed Kerberos domain in Azure.
- Hybrid join is a device identity, not the user-identity definition.
Official sources
- What is hybrid identity with Microsoft Entra ID? — common user identity on-premises and in the cloud; provisioning and synchronization
- Authentication for Microsoft Entra hybrid identity solutions — PHS, PTA, and federation; sync technology does not choose the auth method
- What is password hash synchronization? — hash of the AD password hash; same password for Microsoft 365
- Microsoft Entra pass-through authentication — agents validate passwords against on-premises AD DS
- What is Microsoft Entra Cloud Sync? — cloud-managed agents; disconnected forests
- Study guide for Exam MS-900 — cloud, on-premises, and hybrid identity concepts
What is hybrid identity with Microsoft Entra ID?
An organization already syncs Active Directory users into Microsoft Entra ID. It wants the simplest way for those users to open Microsoft 365 with the same password they use on-premises, without deploying extra authentication servers. Which sign-in method matches that requirement?
Security requires that a disabled, locked, or after-hours Active Directory account be denied Microsoft 365 sign-in at that moment, not after the next directory sync. Which hybrid method is designed to validate the password directly against on-premises Active Directory?
Which statement correctly separates hybrid identity from the other “hybrid” terms on MS-900?