Moving User Management to the Cloud: A Practical Guide to Source of Authority Transfer

As organizations embrace cloud transformation, one critical milestone is shifting user management from on-premises Active Directory to Microsoft Entra ID. This guide walks you through the process of transferring Source of Authority (SOA) for users—a strategic move that simplifies infrastructure while unlocking modern identity governance capabilities.

Understanding Source of Authority

Think of Source of Authority as the “home base” for managing user accounts. Traditionally, this has been your on-premises Active Directory Domain Services (AD DS). When you transfer SOA to the cloud, Microsoft Entra ID becomes the primary system where user accounts are created, modified, and governed.

Transferring SOA delivers several compelling advantages:

• Simplified Management: Edit and manage users directly in the cloud without maintaining complex on-premises synchronization
• Advanced Governance: Leverage Microsoft Entra ID Governance features for lifecycle management, access reviews, and entitlement policies
• Reduced Infrastructure: Minimize your on-premises AD DS footprint and associated maintenance overhead
• Modern Authentication: Enable passwordless authentication methods and sophisticated conditional access controls

Requirements for SOA Transfer

Your environment must meet these prerequisites before attempting SOA transfer:

System Requirements

• Cloud HR system integrated with Microsoft Entra ID for direct provisioning
• Exchange mailboxes fully migrated to the cloud (no on-premises Exchange servers)
• Microsoft Entra Connect Sync version 2.5.76.0 or higher
• Cloud Sync agent version 1.1.1370.0 or later
• Microsoft Entra Free license (minimum)

Authentication Considerations

• For users accessing Kerberos-based applications, implement Cloud Kerberos Trust with passwordless authentication
• Ensure no users depend on password-based authentication for critical applications
• If using federated authentication via AD FS, SOA transfer is not supported
• Third-party federation providers require manual AD account maintenance

Required Roles and Permissions

• Hybrid Administrator: To read and update user SOA via Microsoft Graph APIs
• Application Administrator or Cloud Application Administrator: To grant consent for required permissions
• API Permission: User-OnPremisesSyncBehavior.ReadWrite.All
• Additional Permission for testing: User.ReadWrite.All

Step-by-Step Implementation

Step 1:

Install Latest Sync Clients

First, ensure your synchronization infrastructure is current. Download and install the latest Microsoft Entra Connect Sync build, then verify the installation through Control Panel. Confirm the version meets the minimum requirement of 2.5.76.0.

Next, install the Microsoft Entra Provisioning agent (minimum version 1.1.1370.0) and configure provisioning between AD DS and Microsoft Entra ID. Verify proper installation and check the agent’s current version.

Grant Necessary Permissions

Navigate to the Microsoft Entra admin center as an Application Administrator. Access Enterprise Apps, select your application, navigate to Permissions, and grant admin consent for your tenant. You’ll need to sign in again to confirm consent and accept the permissions list.

Alternatively, use Microsoft Graph Explorer by signing in with appropriate credentials, selecting your profile icon, choosing “Consent to permissions,” searching for “User-OnPremisesSyncBehavior,” and consenting to the permission.

Step 2: Test with a Single User

Prepare Your Test User

Select an existing synchronized user from your AD DS environment or create a new test user in Active Directory. Open PowerShell with administrator privileges and execute:

Start-ADSyncSyncCycle

This triggers a delta synchronization cycle. Verify the user appears in the Microsoft Entra admin center as a synced account.

Verify Current Status

Using Microsoft Graph Explorer, check the user’s current SOA status with this GET request (replace {ID} with the user’s object ID):

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

The isCloudManaged attribute should return false, confirming the user is still managed on-premises.

Test that the user is read-only in the cloud by attempting to modify their display name:

PATCH https://graph.microsoft.com/v1.0/users/{ID}/
{
  "DisplayName": "User Name Updated"
}

The operation should fail, confirming on-premises authority. If you receive a 403 error, grant consent to the User.ReadWrite.All permission through the Modify permissions tab.

Transfer Authority to the Cloud

Execute a PATCH operation through Microsoft Graph API to update the user’s onPremisesSyncBehavior:

PATCH https://graph.microsoft.com/beta/users/{ID}/onPremisesSyncBehavior
{
  "isCloudManaged": true
}

This single action transfers management authority to Microsoft Entra ID.

Verify the transfer by querying the same endpoint:

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

The response should now show isCloudManaged as true.

Confirm Cloud Management

Attempt to modify the user’s display name again:

PATCH https://graph.microsoft.com/v1.0/users/{ID}/
{
  "DisplayName": "Update User Name"
}

This time, the operation should succeed, confirming cloud management capability.

Check the audit logs in the Azure portal by navigating to Manage Microsoft Entra ID > Monitoring > Audit Logs, then filter for “Change Source of Authority from AD to cloud” activity to validate the change.

Open the Microsoft Entra admin center and confirm the user’s “On-premises sync enabled” property displays “Yes.”

Step 3: Understand Sync Behavior

Once SOA is transferred, on-premises changes no longer flow to the cloud. Use the Synchronization Service Manager to examine the user object:

1. Navigate to Connectors
2. Right-click “Active Directory Domain Services Connector”
3. Search for the user by relative domain name (RDN): “CN=<UserName>”
4. Double-click the entry and select Lineage > Metaverse Object Properties
5. Select Connectors and double-click the Microsoft Entra ID object with “CN={<Alphanumeric Characters>}”

You’ll notice the blockOnPremisesSync property is set to true on the Microsoft Entra ID connector object, meaning on-premises changes won’t synchronize.

Testing On-Premises Change Blocking

Update the on-premises user object (for example, change the username from TestUserF1 to TestUserF1.1). Then run:

Start-ADSyncSyncCycle

Open Event Viewer and filter the Application log for event ID 6956. This event confirms the object isn’t syncing to the cloud because SOA resides in Microsoft Entra ID.

For organizations with many users, manual updates aren’t practical. Use PowerShell with app-based authentication to automate the process:

# Define your Microsoft Entra ID app details and tenant information
$tenantId = ""
$clientId = ""
$certThumbprint = ""

# Connect to Microsoft Graph as App-Only using a certificate
# The app registration must have User.Read.All and User-OnPremisesSyncBehavior.ReadWrite.All permissions
Connect-MgGraph -ClientId $clientId -TenantId $tenantId -CertificateThumbprint $certThumbprint

# Alternative: Connect using delegated permissions
# Connect-MgGraph -Scopes "User.Read.All User-OnPremisesSyncBehavior.ReadWrite.All" -TenantId $tenantId

# Define the user name you want to query
$userName = "Ken Roy"

# 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

    # Verify the change
    $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."
}

Understanding Attribute States

As you work with SOA transfers, pay attention to two key attributes and their states:

When you first sync an object, isCloudManaged is false and onPremisesSyncEnabled is true. After transferring SOA, isCloudManaged becomes true and onPremisesSyncEnabled changes to null.

Reversing the Transfer

If you need to move authority back to on-premises, execute a PATCH operation setting isCloudManaged to false:

PATCH https://graph.microsoft.com/beta/users/{ID}/onPremisesSyncBehavior
{
  "isCloudManaged": false
}

However, take these critical precautions first:

• Remove cloud users from SOA-transferred groups
• Remove these groups from access packages
• Ensure no cloud-only references exist for these users

Important: The rollback isn’t complete until both the API call executes AND Connect Sync runs its next cycle. During this interim period, the object remains editable in the cloud.

Validate the Rollback

Check the audit logs by selecting “Undo changes to Source of Authority from AD DS to cloud” as the activity filter.

Run the sync cycle:

Start-ADSyncSyncCycle

Open the object in Synchronization Service Manager. You should see the Microsoft Entra ID connector object state as “Awaiting Export Confirmation” with blockOnPremisesSync set to false, confirming on-premises has regained authority.