Cloud-first approach to identity management:
Transferring Source of Authority from Active Directory to Entra ID

👋 Introduction

The Source of Authority (SOA) in identity management is the single source of truth for an identity's existence and core attributes, like name, email address and job title.

On the journey to a cloud environment, organizations sooner or later need to switch their SOA to the cloud. This means that instead of managing users and groups in an on-premises Active Directory (AD), the management is done directly in Microsoft Entra ID. To ilustrate this concept further, Microsoft provides a nice diagram how an environment can evolve from on-premises to 100% cloud.

This modernization is a crucial step in the cloud journey, it not only improves security, reduces on-prem costs but also makes the management substantially easier through automation and centralized control.

In this article, I will explain why a cloud identity management could be the right fit for your organization and the process of transferring the Source of Authority from AD to Entra. In moving the SOA, administrators enable a phased migration approach, allowing for a smoother transition to the cloud while minimizing disruption to users and services.

☁️ Is cloud identity management right for you?

Improvements

Active Directory has long been a prime target for attackers because it controls so much access. Moving your identities and application authentication to Entra ID reduces that risk. Entra ID adds protection through features like Conditional Access and Lifecycle Workflows. It also enables modern options such as passwordless sign-in and better identity governance, even for apps that were once on-prem. Overall, managing identities through Entra ID strengthens security across the organization.

• IT admins can manage identities, groups and app access from the Entra admin center or via PowerShell.
• Entra governance (Entitlement Management, Access Reviews, Lifecycle Workflows) automates user and group lifecycles and aids accountability with strong audit trails.
• Users get single sign-on to both cloud and on-prem apps with modern features like Conditional Access and passwordless login. This means fewer passwords to manage and stronger protection for their credentials.

---

Road to the Cloud

Like mentioned in the introduction, most organizations move to the cloud in phases. They usually start with a hybrid setup, using both on-premises AD and cloud services. The next step is a cloud-first stage, where more resources shift to the cloud. Over time, they work toward an AD-minimized state.

SOA transfer helps with that journey by letting you move users, groups and contacts to Entra much easier with the additional option to roll back changes if needed. This avoids major changes all at once in a big bang kind of way. Instead, you can migrate identities in phases and slowly reduce their AD footprint. But, always start with checking your applications before transferring SOA, to ensure users don’t lose access to apps relying on AD authentication.

As you start moving your apps and identities to the cloud, many users and groups will no longer be needed in Active Directory and can be removed or retired.

You can also move user creation and lifecycle management to the cloud. Using Entra ID Governance, you can manage SOA-transferred users and groups directly in the cloud and set up automation for creating new identities.

---

Are you ready for SOA?

By following this flowchart you can determine if you are ready to transfer the source of authority for your users and groups:

Moving users: SOA works for users who don’t rely on AD DS for app access. To plan the migration, you need to know which user is tied to which app.

Moving groups: For groups, start by moving security groups to the cloud. If needed, you can provision them back to AD from Entra. For Distribution Lists and Mail-Enabled Security Groups, move them when you migrated to Exchange online.

💿 Application-centric migration approach

The application-centric approach is one of the recommended ways to tackle cloud migration. Like this you will try to modernize your app authentication without compromising access for users.

The following steps outline an example of the process transferring your identities with SOA from AD to Entra:

1. Discover Active Directory–Integrated applications
2. Map applications to AD Security Groups
3. Clean up unused AD groups
4. Identify users for each application
5. Determine authentication methods
6. Assess modernization feasibility
• Older applications with hard-coded assumptions about AD are out of scope for this kind of migration.
7. Categorize applications and plan integration approach
• Apps that get retired or replaced
• Apps on modern auth can be moved directly to Entra (update AD FS to Entra, migrate to Azure Files)
• Kerberos/NTLM apps can be published with Entra Application Proxy or Entra Private Access and use Kerberos Delegation so Entra handles auth and AD gets Kerberos tickets
• LDAP-bound apps can use Microsoft Entra Domain Services (managed AD in Azure) so apps can bind to a cloud LDAP endpoint
• Legacy apps that can't be modernized could be hosted on Azure Virtual Desktop
• Apps without connections to the environment (High Security)
8. Mapping and planning
9. Migrate groups to the cloud
10. Handling LDAP-based applications (Directory-Bound Apps)
11. Handling Kerberos-based applications (Windows Integrated Auth)
• User lifecycle: After moving a user to cloud management, keep an AD account with the same UserPrincipalName for Kerberos
• Auth & attributes: Don’t migrate users who need password-based AD apps that can’t be changed to Kerberos. Apps that use Kerberos and read AD attributes require those attributes kept in sync (dual-write or similar).
• Devices & SSO: For seamless Kerberos SSO, devices should be Microsoft Entra–joined or hybrid-joined. Domain‑only devices with cloud-managed users often need manual logon.
12. Verify and optimize

TIP

Always start with an app-centric analysis to avoid breaking access for users tied to AD apps. Use phased migration to avoid a “big bang” cutover and long downtimes.

👥 Transferring group SOA from AD to Entra

WARNING

Please be aware that this Feature is in Preview at the moment.

1. To transfer the source of authority for a group from AD to Entra, make sure that the group is synchronized to Entra.

2. When you got the groups synchronized, you can use PowerShell to change the SOA.

TIP

You can get a list of all your groups that are currently synchronized from on-prem by running the following command:

get-mgbetagroup -all -property * | Where-Object { $_.OnPremisesSyncEnabled -eq $true } | select Displayname, OnPremisesSyncEnabled

3. Use the following PowerShell script to change the SOA of a group from AD to Entra.

Import-Module Microsoft.Graph.Beta.Groups
Import-Module Microsoft.Graph.Authentication

# Define the Parameters
$tenantId = "[YourTenantID]"
$groupName = "[MyGroupName]"

#Connect to Microsoft Graph using delegated permissions
Connect-MgGraph -Scopes "Group.Read.All, Group-OnPremisesSyncBehavior.ReadWrite.All" -TenantId $tenantId


# Retrieve the group using group name
$group = Get-MgBetaGroup -Filter "displayName eq '$groupName'"

# Ensure group is found
if ($null -ne $group)
{
    $groupObjectID = $($group.Id)
    # Define the Microsoft Graph API endpoint for the group
    $url = "https://graph.microsoft.com/beta/groups/$groupObjectID/onPremisesSyncBehavior"

# Define the JSON payload for the PATCH request
    $jsonPayload = @{
        isCloudManaged = "true"
    } | ConvertTo-Json

# Make the PATCH request to update the JSON payload
    Invoke-MgGraphRequest -Uri $url -Method Patch -ContentType "application/json" -Body $jsonPayload

$result = Invoke-MgGraphRequest -Method Get -Uri "https://graph.microsoft.com/beta/groups/$groupObjectID/onPremisesSyncBehavior?`$select=id,isCloudManaged"

Write-Host "Group Name: $($group.DisplayName)"
    Write-Host "Group ID: $($result.id)"
    Write-Host "SOA Converted: $($result.isCloudManaged)"
}
else 
{
    Write-Warning "Group '$groupName' not found."
}

TIP

If you want to change the SOA for multiple groups, can just edit this line $group = Get-MgBetaGroup -Filter "displayName eq '$groupName'" to change the filter and the $group to $groups and then put a foreach($group in $groups) loop around the code directly beneath that.

4. Now you will see that the source field in the groups changed from Windows Server AD to Cloud.

INFO

You can also check the audit logs to confirm the change.

👤 Transferring user SOA from AD to Entra

WARNING

Please be aware that this Feature is in Preview at the moment.

1. To transfer the source of authority for a user from AD to Entra, make sure that the user is synchronized to Entra.

2. When you got the users synchronized, you can use PowerShell to change the SOA.

TIP

You can get a list of all your users that are currently synchronized from on-prem by running the following command:

get-mgbetauser -all -property * | Where-Object { $_.OnPremisesSyncEnabled -eq $true } | select Displayname, OnPremisesSyncEnabled

3. Use the following PowerShell script to change the SOA of a user from AD to Entra.

Import-Module Microsoft.Graph.Beta.Users
Import-Module Microsoft.Graph.Authentication

# Define the Parameters
$tenantId = "[YourTenantID]"
$userName = "[MyUserName]"

#Connect to Microsoft Graph using delegated permissions
Connect-MgGraph -Scopes "User.Read.All, User-OnPremisesSyncBehavior.ReadWrite.All" -TenantId $tenantId


# Retrieve the user using user name
$user = Get-MgBetaUser -Filter "displayName eq '$userName'"

# Ensure user is found
if ($null -ne $user)
{
    $userObjectID = $($user.Id)
    # Define the Microsoft Graph API endpoint for the user
    $url = "https://graph.microsoft.com/beta/users/$userObjectID/onPremisesSyncBehavior"

    # Define the JSON payload for the PATCH request
    $jsonPayload = @{
        isCloudManaged = "true"
    } | ConvertTo-Json

    # Make the PATCH request to update the JSON payload
    Invoke-MgGraphRequest -Uri $url -Method Patch -ContentType "application/json" -Body $jsonPayload

    $result = Invoke-MgGraphRequest -Method Get -Uri "https://graph.microsoft.com/beta/users/$userObjectID/onPremisesSyncBehavior?`$select=id,isCloudManaged"

    Write-Host "User Name: $($user.DisplayName)"
    Write-Host "User ID: $($result.id)"
    Write-Host "SOA Converted: $($result.isCloudManaged)"
}
else 
{
    Write-Warning "User '$userName' not found."
}

TIP

If you want to change the SOA for multiple users, can just edit this line $user = Get-MgBetaUser -Filter "displayName eq '$userName'" to change the filter and the $user to $users and then put a foreach($user in $users) loop around the code directly beneath that.

4. Now you will see that the source field in the users changed from Windows Server AD to Cloud.

INFO

You can also check the audit logs to confirm the change.

💡 Conclusion

Moving the source of authority from Active Directory to Entra ID is a practical way to make cloud migrations easier, modernize identity, improve security and reduce on-premises reliance. This shift simplifies admin tasks and sets the stage for features like self-service, conditional access and automated lifecycle management.

The safest path is pragmatic and phased: start by inventorying apps and dependencies, then pilot a small set of users or groups. Validate authentication, SSO and use the right integration method per app. As you scale, monitor closely and leverage Entra governance to automate routine processes.

Start small and try to iterate. This approach lowers migration risk, minimizes headaches, delivers better manageability and positions your organization for a more flexible and secure future.

WARNING

But be aware that it needs a cultural shift within the organization to fully embrace these changes. Not only in departments like HR, with the automation of onboarding and offboarding processes, but also in IT, where admins need to get used to new tools, workflows and letting go of old habits. With these automations and workflows and the accountability in form of strong audit trails and security it brings, you got more options to delegating responsibilities (with admin units, entitlement management, workflow automation, access reviews etc.), empowering teams and reducing your workload.

But this shouldn't keep you from starting this journey. Nobody starts at 100% and using all the tools and all the possibilities at once. Start small, try things out, learn and iterate.

SOA battle card infos for IT admins

These are some key points you can use to explain yourself about the benefits of transferring your identity management to the cloud.

Understanding strategic benefits

• Reduces security risks and costs, while elevating flexibility by minimizing on-premises dependencies.
• Enables modern security features (Conditional Access, passwordless, Zero Trust).
• Possibilities to streamline identity management and governance with automation.

Monitoring & accountability

• Strong audit trails for compliance and audits.
• Possibilities for delegation and clear separation of duties.
• Tools to get workflows and decisions back to the people where they belong, without the IT as middle man and without compromising security, compliance or administrative control.
• Enables self-service for users and managers, reducing IT workloads.

Resources

• Cloud transformation posture - Microsoft Learn
• Cloud-First identity management: Guidance for IT architects - Microsoft Learn