Converting AD Group SOA to Govern On-Prem Access via Entra ID – EMS Route

Microsoft recently introduced the Group SOA convert option. At the time of writing, this is in Preview, but with this feature, you can change the AD group’s Source of Authority (SOA) to be Entra. HOW COOL?

This can help IT admins in many ways. Moving to cloud is the buzz word, but some options are not available yet to complete a successful project. There are a lot of moving parts from users, their attributes, Entra Connect Sync or Cloud Sync etc. It’s exciting to see these features as they make the move to cloud a reality sooner rather than later.

AD groups are always a challenge in a Hybrid setup. Some organisations will continue to use the SOA for AD groups, and some will start to create groups straight in AD. And it’s not always a clear-cut process, as for some scenarios require in-cloud groups even if your IT policy requires you to create the groups on-premises.

And more over, when there is no good way to migrate the groups to be in-cloud. But that changes with this new introduction.

While this directly help the AD Minimisation process, this answers a burning question straight away.

What’s The Big Deal?

Your On-prem apps that have tight dependencies with the local AD (Legacy or other dependencies) which has AD security groups which manages app permissions. These AD groups are predominantly used in On-prem, managed and governed in On-prem. You may have synchronised them with Entra ID, but nothing much Entra ID can perform, as the group’s Source of Authority is the On-Prem AD. As you can see in the below image, everything is On-prem. (I have dissected the image to show different parts of the scenario 🙂 )

Below shows the high-level of the sync status

The Win?

AD is the SOA means you need to do changes to the group from On-prem, and it will be on Read-Only from Entra ID end. When the Group SOA changed, you have all the opportunities to control the users for the app via Entra ID features.

• Manage via Access Packages
• Identity lifecycle workflows
• PIM for groups feature for JIT access
• Group Access Reviews

Step 1: Enabling Group Provisioning in Entra Cloud Sync

If you haven’t used the Group Provisioning in Entra Cloud Sync, this is a good opportunity to start using it. Below are the steps to get that up and running.

Requirements

• RBAC: Hybrid Identity Administrator
• On-premises AD DS environment with Windows Server 2016 operating system or later
  • Required for AD DS schema attribute – msDS-ExternalDirectoryObjectId
• Provisioning agent with build version 1.1.3730.0 or later.
• The provisioning agent must be able to communicate with one or more domain controllers on ports TCP/389 (LDAP) and TCP/3268 (Global Catalog).
• Microsoft Entra Connect Sync with build version 2.22.8.0

Permissions

Now that you have the agent installed, let’s get the gMSA accout the permissions to perform the tasks.

The permissions to the service account are assigned during clean install only. If you’re upgrading from the previous version, then permissions need to be assigned manually by using PowerShell:

Import-Module "C:\Program Files\Microsoft Azure AD Connect Provisioning Agent\Microsoft.CloudSync.Powershell.dll"

• Run the command to provide permissions to gMSA account

$credential = Get-Credential
Set-AAD DSCloudSyncPermissions -PermissionType UserGroupCreateDelete -TargetDomain "FQDN of domain" -EACredential $credential

Why You Need This?

This feature enables the option of “basically writing back” group changes back to the on-prem AD group now that you have SOA as Entra. It identifies the group info from the SIDs as I mentioned earlier.
Go through the below steps to enable the feature in Cloud Sync.

• Select Microsoft Entra ID to AD sync option in Cloud Sync Configuration

• Select the Agent > Create > Review and enable the agent
• Once configured, you will see below

Make sure you have the specific Security Groups or All Security Groups selected and the target container is accurate.

You will notice out of the security groups, synced groups are not able to perform Group Provisioning task as it’s managed by the AD.

Step 2: Graph API to Convert SOA

Once you identified the groups you need to convert SOA,

Required Graph Access: Group-OnPremisesSyncBehavior.ReadWrite.All

Check the current status, rune below in Graph Explorer
GET https://graph.microsoft.com/beta/groups/4e4527ed-ffa5-40b5-923d-09be6bd9dbc6/onPremisesSyncBehavior

How Does These Objects Stay In-Tact?

If you analyse the SID of the group, both AD and Cloud would have the same value.

Convert SOA

To convert SOA, On Graph Explorer, Run

PATCH https://graph.microsoft.com/beta/groups/4e4527ed-ffa5-40b5-923d-09be6bd9dbc6/onPremisesSyncBehavior

{
    "isCloudManaged": true
}

And now if you check the same group in Entra ID again you will see the SOA has been changed.

And now I can easily manage the group from Entra ID to add users. And with Group Provisioning in place, any membership changes done to the group will reflect in the On-prem AD as well.

Also, if you go back to the on-prem AD group and check the adminDescription, it has a value with TakenOver_Grorup_

The high-level can be shown as below

Considerations

But to get to this state, it requires completing some steps and then complete the tasks in Entra ID. Let’s look at what are they.

1. Setting up Group Provisioning in Entra Cloud Sync. Entra Connect Sync is not supported for this scenario.
2. AD group to be set as a Universal Security Group
3. Nested groups – While this is not addressing the Nested groups, the recommendation from Microsoft is to apply the SOA change per group in the nested list.
4. Group Provisioning target container must contain the group which you are trying to manage after converting SOA
5. Group Provisioning is not supported in Entra Connect Sync anymore as it has deprecated the feature and you will need to use Entra Cloud Sync

The full process of the SOA and group provisioning as below

Now we have all we need to govern access to On-prem Apps from Entra ID. Now let’s add the Identity Governance features to the mix.

Step 3: Identity Governance Using Entra ID

Now, this is where the fun begins.

Create the Access Package

Go to ID Governance in Entra > Entitlement Management > Access Packages > New Access Package

Add the Group that got SOA changed here.

And set the user/s who required to be a member of this group and the approvers as well as below

Set the Lifecycle details and Access Review info

Create the Access Package.

You will see the direct link for the Access Package in the overview as below

End User Flow

User to go to https://myapps.microsoft.com/ and navigate to My Access

And Access Packages from there > View All

Once the request is submitted, it will be heading to the approver. And the approver can go to the same location (My Access)

This will now add the user to the Entra ID group which in return will sync the same user in the relavent On-prem AD group.

Provisioning Log Details

And member correlates with the Object ID of the On-prem user

Wrapping Up

As you can see in the above image, its clear how you can now attach Entra ID Governance to AD Group SOA scenario. In the same way Just In Time access with PIM for groups, Access Reviews and Identity Lifecycle Workflows can be configured as well. This is a huge step towards shifting Identity Access and Management to Entra ID to make the Cloud-Native journey more achievable without showstoppers.

More reading:

Entra Group Provisioning: https://learn.microsoft.com/en-us/entra/id-governance/scenarios/provision-entra-to-active-directory-groups#considerations-when-provisioning-groups-back-to-ad-ds

Group SOA Concept: https://learn.microsoft.com/en-us/entra/identity/hybrid/concept-group-source-of-authority-guidance
https://learn.microsoft.com/en-au/entra/identity/hybrid/concept-source-of-authority-overview

Group SOA Scenarios: https://learn.microsoft.com/en-us/entra/id-governance/scenarios/provision-entra-to-active-directory-groups#considerations-when-provisioning-groups-back-to-ad-ds

Group SOA on YouTube: https://www.youtube.com/watch?v=AcBMPgpIsw4