Every account in your directory arrived from somewhere, and where it came from decides where you are allowed to change it. That single fact, which Microsoft now calls source of authority, explains more about the daily friction of identity management than any other, and it is the right place to start once the tenant itself is standing.
This is the second article in the Entra ID series. The first was about the shape of a well-run tenant in the current year. This one is about the objects inside it: the users and their origins, the machinery that creates them, and the direction of travel that is slowly pulling the whole model toward the cloud.
Three origins, one governing question
Identities enter an Entra tenant three ways. A cloud-only account is born in Entra and mastered there, with nothing upstream of it. A synchronized account is sourced from on-premises Active Directory and projected into the cloud by a sync engine, which means its attributes are authored on-premises and the cloud copy is downstream. A guest is created by invitation as a real object in your directory, but it carries no credentials of its own; it authenticates against its home organization, and your tenant holds only a reference that points elsewhere. The verbatim framing in the documentation is worth keeping in mind: a user object is created for business guests in the same directory you use for employees, but they authenticate with their home organization and your tenant merely checks their eligibility to collaborate.
Source of authority is the concept that ties these together, and it is now a named, first-class property rather than a mental model you have to supply yourself. For a synchronized object, Active Directory holds the source of authority, which is precisely why an attribute you edit in the cloud is overwritten on the next sync cycle. The object is not really yours to change there; you are editing a shadow. Understanding this saves an enormous amount of wasted effort, because the reflex to fix a synced user in the Entra portal is the reflex to fix a reflection in a mirror.
Editing a synced user in the cloud is the reflex to fix a reflection in a mirror.
The sync engine is now a decision with a deadline
For years there was effectively one way to synchronize identities, the server-based Entra Connect Sync, and the only question was how to configure it. That is no longer true. The cloud-native Entra Cloud Sync, driven by lightweight agents rather than a synchronization server, is now Microsoft’s stated strategic direction for hybrid identity, and in July 2026 Microsoft began a phased, tenant-by-tenant transition toward it. Organizations are being notified individually through the Message Center, Connect Health, and email as their transition window arrives, and the sequencing is deliberate: the earliest waves are tenants whose needs Cloud Sync already meets in full, while organizations that rely on advanced synchronization features or carry very large directories are explicitly not in the first groups.
The honest current-state reading is that Cloud Sync is the recommended path for a straightforward new deployment but is not yet a universal default, because real feature gaps still route certain scenarios to Connect Sync. Hybrid Entra join and device synchronization, complex attribute-based sync rules, cross-forest object references, and the largest directories remain Connect territory. So the practical guidance for a tenant being set up now is to start on Cloud Sync unless you can name a specific feature that forces the older engine, and if you inherit a Connect Sync deployment, to treat migration as a scheduled project rather than an emergency, because your window will be assigned to you.
One currency detail belongs in any plan that keeps Connect Sync alive in the near term. Connect Sync versions retire on a rolling twelve-month cycle, and, separately, a service-side hardening change stops synchronization working entirely on September 30, 2026 for any deployment below the minimum supported build it requires. An out-of-date sync server is not a cosmetic problem; it is a hard stop with a date on it. Confirm your version against the live version-history page before that date rather than after.
How hybrid users prove who they are
Synchronizing an account and authenticating it are separate decisions, and the authentication one has a clear recommended answer. Microsoft’s baseline is to enable password hash synchronization alongside whatever sign-in method you run, because it gives you a cloud-resident way to authenticate that survives an on-premises outage, and because it feeds leaked-credential detection that pass-through and federated models cannot. Where devices are not Entra-joined, seamless single sign-on paired with password hash synchronization is the recommended shape. Federation through AD FS is positioned as the complex exception, more work to operate and to troubleshoot, and the documented direction is unambiguous: migrate off AD FS to cloud authentication, with password hash synchronization as the target.
The reason this matters beyond simplicity is that cloud authentication is the gate to everything modern. Entra multifactor authentication, Conditional Access, Identity Protection risk signals, and the governance features later in this series all assume the authentication is happening in the cloud. A tenant still federated to AD FS is holding its identity plane one layer removed from all of it, and the modernization work is less about retiring a server than about moving the authority for authentication to where the controls live.
The slow migration of authority to the cloud
The most interesting change in hybrid identity is not a new sync engine; it is that the direction of authority has started to reverse. Microsoft now offers source-of-authority conversion, which lets you move the mastering of specific users or groups from Active Directory to Entra. Convert a group and the cloud becomes the place you edit its membership, while Connect Sync respects the conversion and stops synchronizing that object from on-premises. Applied to users, the same idea is framed as Active Directory minimization: edit the user in the cloud, remove the on-premises object, and govern the identity with the cloud tooling. This is the exit ramp from hybrid, taken one object at a time rather than in a single migration.
There is a security argument underneath the convenience one, and Microsoft has now built it into the platform. Beginning June 1, 2026, Entra ID blocks any attempt by Connect Sync or Cloud Sync to hard-match a new Active Directory user object to an existing cloud-managed Entra user that holds a Microsoft Entra role. The purpose, stated plainly in the documentation, is to prevent an attacker from taking over a privileged cloud account by manipulating attributes of a user object in Active Directory. That safeguard exists because in a hybrid model, compromise flows upward: whoever controls the on-premises object controls its cloud reflection, privileged roles included. The cleaner your privileged accounts are of any on-premises lineage, the smaller that attack surface becomes, which is why the cloud-only admin identities recommended in the first article are not a stylistic preference but a containment boundary.
Two writeback details round out the current picture. Group writeback version two in Connect Sync is deprecated and unsupported, and writing cloud security groups back to Active Directory is now Cloud Sync’s job, with the constraint that those written-back groups contain only synchronized or cloud-created security members. Device writeback is being retired as a pattern in favor of cloud Kerberos trust, which the endpoint series covered in its Windows Hello family. Both point the same way: the on-premises directory is being asked to hold less, and the cloud to hold more.
Where this leaves you
The practical shape of a well-founded identity plane in the current year is a small number of clear decisions. Know the origin of every account, because origin is authority and authority is where you manage it. Prefer cloud-only for anything privileged, so that no on-premises object sits upstream of a role. Run password hash synchronization regardless of sign-in method, and treat any remaining AD FS federation as a migration you have not finished yet. Start new synchronization on Cloud Sync, keep Connect Sync current if a feature gap still requires it, and know your assigned transition window is coming. And treat source-of-authority conversion as the tool that lets you retire on-premises dependence deliberately, one object at a time, rather than all at once.
Origins tell you where an identity is controlled. The next question is how the directory that holds them is shaped, because the structure you give the tenant is the substrate every access decision will be written against. That is where we go next.
Entra ID
‹ Previous: [E 1] Entra ID in 2026: Getting Started and the Baseline You No Longer Set
Next: [E 3] Tenant Foundations and the Shape of the Directory ›
