Why and How to Move User Source of Authority from Active Directory to Microsoft Entra ID

Modern cloud-first Identity & Access Management (IAM) strategies require reducing on-premises dependencies while strengthening security, governance, and agility. A foundational milestone in this journey is shifting the Source of Authority (SOA) for user identities from Active Directory Domain Services (AD DS) to Microsoft Entra ID.

With the General Availability (GA) of object-level Source of Authority (SOA) switching, organizations can transition individual synchronized on-premises Active Directory users to cloud-managed identities. This change removes the dependency on Active Directory synchronization and establishes Microsoft Entra ID as the authoritative source for user identity and lifecycle management, enabling a phased and low-impact move toward a cloud-only identity model.

In this blog, we’ll unpack:

• What SOA means for users
• Why converting SOA matters (technical + business drivers)
• Preparing your environment
• How to configure user SOA conversion

If you haven’t already, I recommend reading my earlier blog post on changing the Source of Authority (SOA) for on-premises Active Directory groups: How to Change Active Directory Group Source of Authority to Microsoft Entra ID. While the underlying concepts are related, switching SOA for users introduces additional considerations and distinct value drivers.

What Is User Source of Authority?

The Source of Authority of a user object refers to where that identity is owned and governed:

• On-Prem SOA (classic hybrid) – user object attributes are mastered in AD DS and synchronized to Entra ID via Connect Sync / Cloud Sync.
• Cloud SOA – Entra ID is the authority; changes are made in the cloud and synced upstream from cloud provisioning rather than from AD

With user SOA conversion, organizations can:

• Edit user identities entirely in Entra ID
• Remove the dependency on maintaining those objects in AD
• Leverage advanced cloud features such as Entra ID Governance and lifecycle workflows
• Prepare for cloud-only HR provisioning models
• Adopt modern access controls like Conditional Access and passwordless authentication without on-prem dependencies 

Why Convert User SOA?

Business & Security Benefits

Cloud-native governance: Shift identity lifecycle control to Entra ID Governance with automation, entitlement management, and audit trails

Simplified hybrid footprint: Less reliance on AD DS reduces operational overhead and attack surface.

Better compliance & reporting: Cloud SOA helps with auditing, retention policies, and zero-trust reporting

Future-proof architecture: Enables cloud HR provisioning pipelines (SAP/Workday → Entra ID directly).

Technical Considerations

Feature enablement: Some modern IAM controls depend on cloud governance

Reduced sync complexity: Sync rules and operations become simpler when AD is no longer the master.

Advanced authentication: Leverage cloud authentication methods (FIDO2, passwordless) without federated dependencies. 

Important: For user SOA conversion to succeed technically, affected users must not have dependencies on on-prem applications that require password-based authentication or federated auth (e.g., AD FS).

Preparing Your Environment for User SOA

Before switching user SOA to Microsoft Entra ID, validate application dependencies, authentication methods, and any remaining reliance on on-premises AD or Exchange. The flow below helps determine whether users and groups are ready to move to the cloud or if apps must be modernized first.

Check Sync & Identity Landscape

• Ensure users are currently synchronized with Microsoft Entra ID using Entra Connect Sync or Cloud Sync.
• Confirm all required attributes (e.g., mail, manager, department) are synced and visible as directory attributes or Graph extensions.
• Confirm that no user attributes are being managed by other on-premises Microsoft services outside of Active Directory Domain Services (AD DS).
• For example, users whose attributes (such as userCertificate) are maintained by Active Directory Certificate Services (AD CS) should not be considered for SOA conversion.

Active Directory Cleanup

• Move users targeted for SOA conversion into a dedicated OU to isolate changes post-conversion.
• Remove reference-valued attributes (e.g., group memberships that won’t apply post-move) that aren’t supported for SOA conversion

Exchange & Provisioning Changes

If your environment uses an Exchange Hybrid configuration, additional preparation is required before switching the Source of Authority (SOA) of user accounts to the cloud.

• Ensure all user mailboxes are fully migrated to Exchange Online.User SOA should not be switched while any mailbox remains on-premises.
• After migration, users must be fully manageable in Microsoft 365 with no dependency on the on-prem Exchange server for mailbox or attribute updates.
• Point MX and Autodiscover records to Exchange Online, not the on-prem Exchange Server.
• Clear SCP values from on-prem Exchange servers to ensure Outlook clients use DNS-based Autodiscover instead of querying on-prem Exchange.
• Remove inbound and outbound connectors created by the Hybrid Configuration Wizard (HCW) if they are no longer required.
• Remove Organization Relationships, Federation Trusts, and OAuth trusts between on-prem Exchange and Exchange Online.
• Ensure user attributes are no longer updated via on-prem Exchange tools.
• Allow a final sync cycle so Exchange Online holds the authoritative and latest mailbox state before switching user SOA to cloud

Key rule: User SOA must only be switched after Exchange Hybrid is functionally retired for those users.

HR / Identity Provisioning

• If you source users via HR systems (Workday, SuccessFactors, MIM), update provisioning configs to target Microsoft Entra ID directly for SOA converted users.

Configuring User SOA Conversion

SOA conversion is not a simple toggle  it’s a controlled lifecycle transition. 

Once your environment is fully prepared, the SOA transition itself should be treated as a controlled sequence, not a one-click operation. The goal is to ensure identity data remains consistent while ownership cleanly moves to Microsoft Entra ID.

Step 1: Decide What Moves First

Start by identifying the users and groups whose Source of Authority will be moved to Microsoft Entra ID.
These objects must already be synchronized using Microsoft Entra Connect Sync or Cloud Sync.

Always begin with a pilot users to validate functionality and verify application sign-in and access behavior before rolling it out more broadly.

💡 Important: Always switch the SOA of groups first, followed by users.
This avoids broken references and permission inconsistencies later.

Step 2: Stop Upstream Provisioning into Active Directory

If these users are being provisioned into AD from an external system (for example, Workday → AD, MIM → AD, or similar), remove them from that provisioning scope.

At this stage:

• AD should no longer receive identity updates for these objects
• Entra ID should still reflect the latest synced state

Step 3: Let Sync Catch Up

Allow the next sync cycle to complete and confirm:

• User and group data matches between Active Directory and Microsoft Entra ID
• No pending attribute changes are in flight

This step is critical ,it ensures a clean handoff point before SOA is changed.

Since this is a lab environment and there’s no external system or MIM in place, I’ll skip steps 2 and 3.

Step 4: Freeze On-Prem Changes

Once data parity is confirmed:

• Stop making any direct changes to these users or groups in AD
• AD should now be treated as read-only for these objects

Assume ,From this point forward, AD is no longer the system of record.

Step 5: Switch the Source of Authority

Proceed with switching the SOA of the selected users to Microsoft Entra ID.

This action marks the official transition:

• Ownership moves to the cloud
• Entra ID becomes the authoritative directory for these identities

To proceed, the following requirements apply:

• Hybrid Administrator role is needed to read and update a user’s SOA via Microsoft Graph.
• Application Administrator or Cloud Application Administrator is required to grant user consent for Microsoft Graph permissions.
• Apps calling the onPremisesSyncBehavior API must have User-OnPremisesSyncBehavior.ReadWrite.All permission.
• A minimum Microsoft Entra Free license is sufficient for SOA conversion.
• Entra Connect Sync: minimum version 2.5.76.0 (version 2.5.79.0 required for Contact SOA).
• Cloud Sync: minimum version 1.1.1370.0.

Open Graph Explorer and sign in as an Application Administrator or Cloud Application Administrator.
Go to Profile → Consent to permissions, search for User-OnPremisesSyncBehavior, and grant consent.

Let’s check the current SOA status of the test user. Since we haven’t updated it yet, the isCloudManaged value should be false.

Use the following request and replace {ID} with the test user’s object ID:

GET https://graph.microsoft.com/v1.0/users/{ID}/onPremisesSyncBehavior?$select=isCloudManaged

You can also confirm this in the Entra ID portal: the user properties are read-only because the account is synced from on-premises AD, and any attempt to modify the user directly in the cloud will fail.

You can now update the user’s SOA to make it cloud-managed.
In Microsoft Graph Explorer, run the following request for the target user (replace {ID} with the user’s object ID):

PATCH https://graph.microsoft.com/v1.0/users/{ID}/onPremisesSyncBehavior

{

  "isCloudManaged": true

}

Step 6: Validate Cloud Ownership

Let’s validate the change using Graph Explorer 

In the Entra ID admin center, you can now modify the user properties because the account is cloud-managed after the SOA conversion.

Review Audit Logs to confirm the SOA change event is recorded

Also, if you check the on-premises Entra ID Connect Sync Service Manager, you’ll see the user attribute BlockOnPremisesSync is now set to true.

Step 7: Keep Sync in Scope (Yes, Really)

Even after SOA is switched, continue to keep these objects in scope for Connect or Cloud Sync.

Why?

• These users and groups may still reference AD-managed objects such as:
• Devices
• Contacts
• AD-managed groups

Removing them from sync entirely can break those references.

Step 8: Reverse the Provisioning Direction(If you have HR systems integrated)

Now that AD is no longer authoritative:

• Update your identity lifecycle so that user changes flow directly into Microsoft Entra ID
• Create a new provisioning configuration using the Provisioning API or cloud HR connectors

• Start provisioning these users from:

• HR systems
• Cloud identity sources
• Other SaaS applications→ Directly into Entra ID

How to Roll Back SOA Update

Before rolling back, ensure the user has no cloud dependencies:

• Remove the user from any SOA-transferred groups.
• Remove those groups from access packages.

During the next sync cycle, the sync client will take ownership of the object again.

To revert the SOA back to on-premises, run the following in Microsoft Graph Explorer (replace {ID} with the user’s object ID):

PATCH https://graph.microsoft.com/v1.0/users/{ID}/onPremisesSyncBehavior

{

  "isCloudManaged": false

}

Bonus Tip: Maintaining hybrid access after SOA transfer

After transferring SOA to the cloud, some on-premises attributes are still required for accessing on-prem resources. These attributes exist on the cloud user object and should not be deleted if on-prem access is needed:

• onPremisesDistinguishedName
• onPremisesDomainName
• onPremisesSamAccountName
• onPremisesSecurityIdentifier
• onPremisesUserPrincipalName

If users must continue accessing on-premises resources, maintain these attributes manually using Microsoft Graph.

Enable hybrid access with passwordless authentication

If you’ve transferred SOA but still want users to access both cloud and on-prem resources, don’t fully remove them from Active Directory. Instead, introduce Cloud Kerberos Trust–based passwordless authentication.

Using Windows Hello for Business or FIDO2 security keys, users can:

• Access on-premises resources and cloud resources (for example, Azure Files via Microsoft Entra Private Access)
• Benefit from built-in MFA, improving security
• Be protected by Conditional Access policies for on-prem resources

⚠️ For this scenario to work, the user account must remain in Active Directory.

 

Conclusion: Cloud-First Identity Starts with SOA

Converting User Source of Authority from on-prem AD to Microsoft Entra ID represents a critical step in cloud identity transformation. It not only reduces on-prem dependencies but also unlocks modern governance, authorization, and device-centric security scenarios that today’s zero-trust architectures demand.