How to Change Active Directory Group Source of Authority to Microsoft Entra ID

Introduction

In many hybrid identity deployments, organizations have groups (security groups, distribution lists) in their on-premises Active Directory Domain Services (AD DS) that are synchronized into Microsoft Entra ID via Entra ID Connect\Cloud Sync. In these cases, although the cloud copy in Entra ID appears as a group, the source of authority (SOA) remains the on-premises AD ,meaning you must manage membership and settings on-premises, and the cloud instance is often read-only or limited.
Yet with modern cloud identity and access governance requirements (self-service access, reviews, lifecycle automation, cross-tenant B2B, cloud apps, conditional access) many organizations want to shift group management into the cloud, reduce reliance on AD for everyday changes, and leverage the full governance features of Entra ID.

Fortunately, Microsoft has introduced the capability to change the SOA for groups essentially converting a hybrid AD-synced group so that Entra ID becomes the authoritative source, enabling cloud-native management, while still preserving hybrid connectivity. I will walk you through why you’d do this, how it works, what’s required (for Entra ID Connect vs Entra Cloud Sync), how to plan and execute the conversion, and what the pitfalls/licensing/security implications are.

Why Does Source of Authority Matter?

The Hybrid Challenge

When you have an on-premises group that’s synced into Entra ID (via Entra ID Connect\Cloud Sync), but the group’s SOA remains AD DS:

• Any membership or property changes must be made on-premises in AD. The cloud side may show the group but will often be greyed out / read-only. 

• Some advanced cloud-native scenarios are blocked or limited. For example, adding guest users (B2B) or using the group for entitlement management, dynamic membership or conditional access may be constrained when the group is locked down by the on-prem authority. 

• Over time the organization may want to reduce its dependency on AD DS: fewer changes on-premises, more cloud-native identity operations, simpler governance. Shifting SOA is part of that AD minimization strategy.

The “Win” of Converting SOA to Cloud

When you convert a group’s SOA to Entra ID (cloud-managed), you gain:

• Ability to edit the group (membership, properties) directly in the cloud ,not required to go back to on-prem AD. (Once converted, the isCloudManaged flag becomes true.) 
• Leverage full cloud-based governance: membership reviews, entitlement mgmt (Access Packages), dynamic groups, guest users, cross-tenant access, etc. 
• Simplified operations for IT and identity teams: fewer on-prem changes, less dual management risk, better alignment with cloud-first identity strategies. 
• Retain hybrid compat: The group object remains synchronized (in many cases), and you can still support on-prem resources if configured, rather than ripping everything out at once. 

Prerequisites & Preparations

Before converting SOA for a group, you must prepare your environment and ensure you meet some key prerequisites.

Licensing & Roles

• The minimal license of Entra Free is required just for the SOA conversion feature. 
• You’ll need appropriate Azure/Entra roles: typically a Hybrid Administrator (to read / update the Graph API properties) and Application Administrator (or Cloud Application Administrator) to grant necessary permissions. 
• For using Graph/PowerShell automation, the application must have Group-OnPremisesSyncBehavior.ReadWrite.All permission (in addition to Group.ReadWrite.All)

Connect & Cloud sync Versions & Environment

• If you use Entra ID Connect, you must be at version 2.5.76.0 or later.
• If you use Entra Cloud Sync, version 1.1.1370.0 or later is required.
• Confirm you have clear scoping and filtering so you avoid conflicts (e.g., same group being targeted by both Connect and Cloud Sync) ,because converting SOA changes how sync engine handles the group.

Group Preparation: Scope, Type, Nesting

• The group must be a Universal Security Group (not a domain local or global) if you expect membership in cloud and cross-tenant use.

• Nested groups: If your group has nested groups (child groups inside parent groups), you need to treat them individually. Converting a parent group’s SOA does not automatically convert nested groups. 
• Review any extension attributes (e.g., extensionAttribute1-15). Some attributes may not be supported for cloud-managed groups after conversion. 
• Cleanup and review group membership: ensure the group is healthy (well-scoped members, no unusual legacy complicated rules) before converting.

• Consider naming/alias, OU path, and whether you will write back the group into AD (via Cloud Sync). If so, plan the distinguished name/OU mapping

Governance & Planning

• Identify candidate groups for conversion (pilot groups): select those with lower risk, fewer dependencies, and high benefit (e.g., groups used for access to cloud apps, guests, etc.).
• Map out dependencies: Which applications rely on the group? Which on-prem resources? Are there scripts or workflows expecting AD-based group management?
• Define fallback/rollback plan: What if something breaks?
• Determine governance: membership owners, review cadence, access lifecycle, etc. Make sure the new cloud-managed group fits into your governance model.
• Communicate: Change of source of authority means changed operational model (memberships may now be changed via Entra rather than AD), so ensure owners know.

Step-by-Step: Converting Group SOA

Here’s a practical walkthrough. In my Lab environment i have Hybrid AD + Entra ID environment with Entra ID Connect as the primary sync engine, and optionally Entra Cloud Sync for write-back scenarios.

Step 1: Verify Current State of the Group

1. Identify the group in AD DS that has been synced to Entra ID. In Entra Admin Center, locate the group and check its Source (should show “Windows Server AD”).

In Microsoft Graph Explorer you can check this by using the below request.

GET https://graph.microsoft.com/beta/groups/e28dfb58-6bb0-418b-9a2d-a95b21116ed9/onPremisesSyncBehavior

Ensure no unusual sync errors or blocking issues in your Entra ID Connect or Cloud Sync logs.

Step 2: (Optional) Deploy Cloud Sync Move the Group into a Dedicated OU / Adjust Sync Scoping

If your organization uses both Entra ID Connect and Entra Cloud Sync, you may want to ensure that after conversion the group is in a different OU to avoid conflicts. For example:

• Create a target OU for cloud-managed groups that will be provisioned back from Entra (if write-back is required).
• Adjust your sync filters so that Entra ID Connect no longer syncs the group (or you configure the group’s object to be excluded).
• If using Cloud Sync for write-back, ensure the group is in scope for the Cloud Sync agent. 

Now, let’s configure Cloud Sync to synchronize the cloud-managed group.

I’ve installed Entra Cloud Sync on the on-premises server. You can refer to my previous blog, where I explained the Cloud Sync setup process used for on-premises Active Directory provisioning

Open the Entra Connect menu from the Entra ID Admin Center, select Cloud Sync, and then choose New Configuration. Choose Microsoft Entra ID to AD Sync

Select the appropriate agent that you’ve installed on your on-premises server and click create

Once the configuration is created, go to Scoping Filters and select the group you want to synchronize to the on-premises Active Directory.

Note: We haven’t converted the group to cloud-only yet. In Step 3, we’ll convert the existing AD-synced group to a cloud-only group and then synchronize it back to the on-premises AD using Cloud Sync.

Note: The group must be converted to cloud-only before it can be synchronized to the on-premises Active Directory.

Step 3: Convert the Group SOA via Graph API

Execute the update call to change isCloudManaged to true. For example:

Goto Graph Explorer

PATCH  https://graph.microsoft.com/v1.0/groups/{group-id}/onPremisesSyncBehavior

{

  "isCloudManaged": true

}

After the patch, call GET to verify:

GET https://graph.microsoft.com/v1.0/groups/{group-id}/onPremisesSyncBehavior?$select=isCloudManaged

You should see isCloudManaged = true

Step 4: Sync/Export / Verify the Effects

• If using Entra ID Connect: After conversion, the sync engine should detect that the group is now cloud-managed and should set property blockOnPremisesSync = true on the metaverse object (so on-prem changes are blocked). 

• Confirm in Entra Admin Center: the group’s Source should now show “Cloud”.

• Test cloud changes: Edit membership from Entra Admin Center, add a cloud-only guest user, confirm the change propagates as expected.

• If write-back to Local AD Cloud Sync is required: Make sure the group is provisioned back correctly (same SID, maintain OU path if needed) and that if any on-prem applications that has dependency with the Group can continue to work.

To sync the group back to the on-premises Active Directory, select the Cloud Sync configuration created in Step 2, go to Scoping Filters, choose the cloud-only group, and specify the desired OU where the cloud-synced group should be created.

If needed, you can modify the group attributes under Attribute Mappings. By default, the CN of the cloud-synced group will have the cloud group object appended automatically.

Now lets review and Enable the Cloud Sync configuration

Now, let’s perform an on-demand provisioning, since the default provisioning interval is fixed at 20 minutes.

Provisioning completed successfully, and the provisioning logs confirm the operation.

Now, let’s open the local AD OU selected for Cloud Sync and review the group attributes.

The Cloud Sync Monitoring page displays the current sync status and the synchronization interval.

Hook into Your Identity Governance & Access Scenarios

With the group now cloud-managed, you can modernize it:

• Use the group as an Access Package in Entitlement Management for self-service access requests.

• Set up Access Reviews on the group membership (especially important now that cloud users/guests may be members).

• Use Dynamic membership rules (if applicable) or combine with conditional access policies.

• If you still need on-prem resource access (e.g., Kerberos/LDAP apps) and you write back the group, ensure your workflow integrates accordingly. 

I’ll be covering some of these use cases in my upcoming blog posts.

Considerations, Pitfalls & Limitations

This Group SOA conversion process is powerful, but not without caveats. Be aware of these before you start.

Key Limitations

• Nested groups: If you have a parent group with nested child groups, converting the parent’s SOA does not automatically convert nested groups; they remain on-prem until individually converted. 
• Extension attributes: Some on-prem extension attributes (e.g., extensionAttribute1-15) are not supported after conversion for cloud-managed groups. 
• Dual write / conflict potential: After conversion, if you use group provisioning back to AD (via Cloud Sync) and nest the cloud group under an on-prem group that’s still synced, you may face synchronization limitations because the sync engine may not know membership references. 
• Mail-enabled security groups/distribution lists: Converting these may impose restrictions because they may need to be managed via Exchange rather than via Entra native UI. 
• App dependencies: Some legacy applications or scripts may reference the AD group’s distinguished name, SID, or expect on-prem editing. If you convert SOA and then attempt to edit on-prem, membership changes may not sync. It’s critical to identify all dependencies.
• Rollback is possible but requires care: If you revert the group’s SOA (isCloudManaged = false), you must ensure no cloud-only users remain in the group (remove them) and the sync engine re-takes control.  

Operational & Security Considerations

• Audit and logging: Use the Entra Audit Logs to track the change of SOA and subsequent membership edits.

• Governance for membership changes: Since membership is now editable in the cloud, ensure you have robust review processes. Perhaps set up access reviews for the group after conversion.
• Security posture: When group is cloud-managed you can integrate it with conditional access policies, identity governance, privileged access workflows, etc. That’s a big benefit, but you must treat the group as higher importance (it may have broader access).
• Licensing review: While the SOA conversion might require only minimal license, the broader governance features (access packages, access reviews, identity governance) may require higher-tier Entra or Azure AD licensing.
• Training & process changes: The operational model changes, for example, group owners need to know they now manage membership in Entra rather than AD. Access request flows may also change.
• Impact analysis: Before conversion, run an impact analysis , which resources (cloud or on-prem) use the group, who the members are, nested groups, assignment in applications etc.
• Change management: This is a significant change to identity architecture; communicate to stakeholders, schedule during maintenance window if needed, ensure rollback plan.

Next Steps & Roadmap

• Start with a small pilot of 5-10 groups: pick those with high benefit and low risk.

• Document all dependencies, workflows and applications associated with those groups.
• Update your sync engine(s) to required versions and ensure your environment is healthy (no sync errors).
• Define governance and process for cloud-managed groups (owner assignment, membership review, audit logs).
• Convert pilot groups, validate membership editing, application access, fallback readiness.
• Expand conversion across more groups, prioritizing groups tied to cloud apps, guest access or self-service.
• Monitor and clean up old on-prem groups as you go (decommission when no longer needed).
• Review licensing and identity governance stack to ensure you’re leveraging full value of cloud-managed groups.
• Continue evolving toward a “cloud-first” identity posture: fewer manual on-prem changes, more automation, richer access governance.

Conclusion

In summary, converting the source of authority (SOA) for Active Directory–synced groups to Microsoft Entra ID empowers organizations to modernize group management, simplify operations, and enhance identity governance. By shifting control to the cloud, IT admins and identity engineers can enable self-service access, automate lifecycle management, and reduce reliance on on-prem AD, all while maintaining hybrid flexibility. With careful planning, updated sync agents, and proper governance, this change becomes a key step toward a secure, cloud-first identity infrastructure.