azureblog.co.uk
← cd ~/posts

Converting synced users to cloud-managed: Source of Authority is GA

You can now switch an individual Active Directory-synced user to be managed in the cloud, without deleting and recreating it. A big step towards shrinking on-premises AD.

2 min read⚠ checked 28 Jan 2026Entra ID · Hybrid identity · What's new
Part 2 of 5 in Shrinking hybrid identity
On this page
  1. Where it helps
  2. Things to check first
  3. Doing it with Graph
  4. A wave plan

Moving away from on-premises Active Directory has always had an awkward step in the middle. A user synced from AD is mastered in AD. To make them cloud-only, you used to have to break sync, and it often went wrong.

Active DirectorySync engineEntra IDAdminUser exists in AD andsyncs as normal1Switch source ofauthority to cloud2Same object, same ID, sameaccessSync sees the flag andstops writing this user4Attributes now editedin Entra or by HRprovisioning5
What changes when you convert a synced user.

Source of Authority (SOA) conversion for users is now generally available. It switches an individual synced user from AD-managed to cloud-managed, keeping the same Entra object, its access and its history.

Where it helps

  • Cloud-first staff. Users who never touch on-premises resources don't need to be mastered in AD.
  • Shrinking AD gradually. Move users across in waves instead of a big-bang cutover.
  • Fewer hybrid dependencies. Every user mastered in the cloud is one less thing tied to your sync server.

AD-mastered

Before

  • Attributes edited in AD
  • Changes reach Entra on the next sync
  • Deleting in AD deletes in Entra
  • Password managed on-premises (with PHS)

Cloud-mastered

After

  • Attributes edited in Entra, Graph or HR provisioning
  • Object ID, licences, groups and history kept
  • AD object no longer drives the cloud user
  • Password and methods managed in the cloud
Before and after conversion.

Things to check first

  • On-premises access. If the user still needs file shares, legacy apps or resources, check how they'll authenticate after the switch.
  • Attribute ownership. After conversion, attributes are edited in Entra or by HR-driven provisioning, not in AD. Make sure your joiner/mover/leaver processes know that.
  • Groups. Group SOA conversion is a related option. Look at which groups can move to the cloud alongside their members.
  • Pilot. Convert a few IT accounts first and live with them for a while.

Doing it with Graph

Conversion is driven by the user's onPremisesSyncBehavior setting in , so you can script waves of users once the pilot is done. Check the current Learn page for the exact permissions and sync client versions required, since your sync engine has to understand the flag.

The usual order is: confirm the user is in scope of a sync client that supports the flag, set it on the user, then check the next sync run skips the object without errors.

A wave plan

  • Wave 0: IT staff test accounts, live with them for two weeks
  • Wave 1: cloud-only teams with no on-premises resource access
  • Update joiner, mover and leaver steps so nobody edits these users in AD
  • Decide what happens to the old AD object: disable, move to a holding OU, or keep for resource access
  • Report on converted users monthly, so you know your remaining AD footprint
Does the user notice anything?

Not if they only use cloud resources. Their account, mailbox, group memberships and sign-in stay the same.

Can I switch back?

The setting can be reversed, but plan as if it's one-way and pilot first. Reversing means AD becomes authoritative again and will overwrite cloud changes on the next sync.

What about Exchange hybrid?

Mailbox attributes managed through on-premises Exchange tooling need a plan. Check Microsoft's guidance for Exchange attributes before converting mailbox users at scale.

Sources

This post was last checked against Microsoft's documentation over six months ago. The approach should still hold, but check the linked sources for anything that has changed before you act on it.

Next in Shrinking hybrid identity · part 3 of 5Hybrid join without Entra Connect: hybrid join using Entra Kerberos →

Related posts