Skip to content

Take control over AD-managed groups

Screenshot of fake Entra ID group, with source set to Windows Server AD

I am working through automating user onboarding at an Enterprise-size client from start to finish, and group memberships is one of the hurdles.

Although groups can be synced to Entra ID, the Source of Authority (SOA) is still the AD of the business unit. This can complicate management of group memberships, because membership for groups can only be modified at the source. This complicates automation, like user creation (including groups) and management.

However, automatically managing AD groups isn't impossible. There are several options that an organization can choose from, each with their own benefits and caveats. Those are:

  • Enabling Group Writeback in Entra ID Cloud/Connect Sync
  • Changing the 'source of authority' (SOA) of groups
  • Using an Azure-based solution to send commands to local infrastructure

I'll go through the three options and guide you through the decision, with some bonus options at the end.

Enabling Group Writeback in Entra ID Cloud/Connect Sync

The easiest to start with, is group writeback. You can create groups in Entra ID, and sync them back to your on-premises AD. The groups will be made a new groups, and won't be matched to existing groups This is the easiest option for greenfield deployments, but I can't imagine a lot of us are setting up new AD environments.

When working in existing environments, this will be more complicated. Groups are used in a lot of systems, and those would need to be swapped out with groups created in Entra ID. That means going into systems/sites/applications to modify the permissions.

The process will go roughly like the diagram below:

---
title: "Process of migrating groups from AD to Entra ID"
---
    flowchart TD
    Prepare[Prepare AD environment for incoming groups] --> Creation[Create groups in Entra ID]
    Creation --> Enable[Enable group writeback on Connect/Cloud Sync]
    Enable --> Modify[Modify permissions of apps/sites/systems to use Entra ID-based groups]
    Modify --> Delete[Delete AD-based groups]

Benefits

This is a simple way of changing the source of authority for groups. There aren't many decisions to be made, other than where incoming groups should go and which groups to sync. It will then be picked up by your sync engine for creation.

Limitations

You'll get new groups, which you need to assign to applications and systems. The group membership needs to be updated too. The latter one could be automated, when old and new groups are mapped (i.e. in a spreadsheet). Either way, it would take a lot of manual work to fix, although it could be done iteratively through widening of the sync scope.

Also, you'd need to manage the groups in Entra ID from now on, as the SOA has changed. Although you'll be technically able to manage groups in AD, the changes will be overwritten at the next sync.

How to continue

I'll forward you to guides from Microsoft to implement group writeback.

When using Entra ID Connect Sync, you can use this guide, or get some guidance from Ali Tajran, who provides a bit of extra context. When using Entra ID Cloud Sync, you can use this guide. Jaap Wesselius from Practical 365 has a good guide too, with some extra visuals.

Change 'source of authority' of AD groups to Entra ID

Another option is to change the SOA of a group. This is a possibility since mid-2025 and is generally available. This will mean that the authority of the group (and the management of the users) will move from AD to Entra ID.

You can use this functionality with both Entra ID Connect Sync or Cloud Sync, granted that you have updated the service after July 2025. This could work a bit easier than writing back groups, but is a bit more difficult in conversion.

You can follow this process, when converting groups to have Entra ID be their SOA.

---
title: "Process of converting the SOA from AD to Entra ID"
---
    flowchart TD
    Prepare[Assign permissions to be able to convert SOA of groups] --> Convert[Convert the SOA of groups]
    Convert --> Verify[Verify the SOA change of groups]

Benefits

You do not need to re-create or re-assign groups, either in AD or in Entra ID, to be able to manage users in the cloud. This will mean less work on other systems to process this change.

Limitations

When you want to sync the membership of groups from Entra ID back to AD after the SOA change, you would need Cloud Sync and additional configuration.

You would also need to work with Graph to continue with this, to the dismay of ClickOps teams.

Also, you'd need to manage the groups in Entra ID from now on, as the SOA has changed. Although you'll be technically able to manage groups in AD, the changes will be overwritten at the next sync.

How to continue

Microsoft really wants you to move to Entra ID, so they made a great landing page with a lot of information, if you want to dive into the details and architectural decisions. You can find the page here.

If you just want to go ahead and move over the SOA, follow this step-by-step guide here. If you want to change the SOA and sync back the changes to AD, you can follow this guide.

[!INFO] Note about Entra Cloud Sync and Connect Sync It's possible to run the clients side-by-side in your environment. Both sync clients can be used for syncing different objects, which should be fine in this use case, as Connect Sync can't provision groups from Entra to AD.

Azure-based solution

If you really do not want to (or can) touch Entra Connect/Cloud Sync, there are alternatives. Azure offers a few options to make contact with on-premises systems, so scripts can be run locally, so groups can be managed.

You can choose either of the following:

Source of main inspiration here

I would personally choose Azure Automation or Azure Logic Apps, given that most uses I'm seeing will work with something that relies on Logic Apps (i.e. Entra ID Governance). The process of implementing this, should be something like this:

---
title: "Process of modifying group membership from Azure to AD"
---
flowchart TD
subgraph "Initial Deployment"
    direction TD
    CreateAutomation[Create Azure Automation Runbook] --> HybridWorker[Configure Hybrid Runbook Workers]
    HybridWorker --> CreateScript[Create script to modify group membership]
    CreateScript --> ModifyAutomation[Modify existing automation to call runbook for group management]
end

subgraph "Modify"
    direction TD
    Prepare[Prepare group membership changes for user] --> SendToAutomation[Call Azure Automation Runbook]
    SendToAutomation --> SyncBack[Sync changes back from AD to Entra ID]
end

Benefits

With the right scope, you'll be able to fulfil the need to modify membership, without changing anything to the sync engine. Groups will still be managed on-premises (which can be a limitation, but at least it's clear where it needs to happen).

Limitations

It takes more effort to make it work, and will be reliant on a few systems and services, which all can be a point of failure. Incorrectly setting up the services (or Azure in general) could mean you'll be adding security vulnerabilities in your environment.

How to continue

When executing the script from Azure, Christian Frohn created a good solution for themself, in combination with Entra ID Governance. You could use this as a starting point for your script. The one thing I do not like, are the hard-coded credentials. Group Managed Service accounts (gMSA) are not natively available through Azure Automation. Microsoft has a guide for a workaround (which works if you're SOC is sleeping on PsExec usage on servers).

If you want less of a on-premises connection (with the caveat that monitoring will be more difficult), you can create files in a watch folder with the on-premises data gateway. It does require a service account on one end, but you can use a gMSA for the script polling the watch folder and processing the files for group membership changes (as seen in the blog of TheSleepyAdmin).

Bonus options

To close off, there are a few options I haven't gone through, but are out of scope for my use, taking security and manageability into account. Not everyone wants or needs to be correct, and pragmatic solutions still can be okay.

If we'll think out of the box, we can achieve management of group memberships somewhat by:

  • Using dynamic groups on both ends, using the same attribute filters in either group
  • Pulling group membership from Entra ID via Graph and updating a similar-named group in AD
  • Just migrating over fully from AD to Entra ID