Cloud Sync: Entra ID to AD; Groups sync'ing but no members of the groups: Error: NotEffectivelyEntitled

Question

Cloud Sync: Entra ID to AD; Groups sync'ing but no members of the groups: Error: NotEffectivelyEntitled

Tom Robinson 0

Entra ID to AD Sync not working for All Users members.

I have set up Cloud Sync to sync Entra ID to AD on premises. The groups are syncing but the members of the groups are skipped with NotEffectivelyEntitled.

What am I doing wrong? How can I get the members fo the groups to synchronise to the on premises AD?

Anonymous

2025-10-10T05:36:10.62+00:00
Hello Tom Robinson,Welcome to Microsoft Q&A Platform. Thank you for reaching out & hope you are doing well.

I will try to clarify your doubts regarding the issue. So basically, the issue is a design limitation of the Group Provisioning feature, not a configuration error.

The group members MUST be hybrid (synchronized from on-premises AD). Will recommend some workarounds below as:

Identify User Type: You can check and confirm that the skipped users are indeed Cloud-Only (check their onPremisesSyncEnabled attribute, which will likely be False or not present).

Move to Supported Users: The only way to get group membership to synchronize is to ensure the members of the cloud-created security group are users who were originally synchronized from your on-premises AD to Entra ID.

Alternative (which is Not Supported by Cloud Sync): If the goal is to fully manage cloud-only users and their membership in on-premises AD, Cloud Sync does not support User Writeback (creating the user object itself in on-premises AD from the cloud).

For full bidirectional user and group provisioning, Microsoft recommends exploring API-driven inbound provisioning to on-premises AD or the legacy, unsupported, Entra Connect User Writeback feature (if the environment permits).

more understanding and clarification at: https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync

https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-configure-entra-to-active-directory#limitations

https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync#comparison-between-microsoft-entra-connect-and-cloud-sync

Hope this helps! If it answered your question, please consider clicking Accept Answer and Upvote. This will help us and others in the community as well. If you need more info, feel free to ask in the comments. Happy to help!

Regards,

Monalisha
Tom Robinson 0 Reputation points

2025-10-13T03:46:23.7166667+00:00
Hi @Anonymous ,

Thanks for you assistance.

To answer your questions:

We only have Cloud-Users

We never had an on-premises AD

I have now implemented an API-driven provisioning to on-premises Active Directory

We are still having issues, however.

In the API-driven provisioning to on-premises Active Directory application I have added Users individually and alternatively as a Group (neither selection worked to provision users to the on-premises AD). In the provisioning log I only see one message: "No results."

What am I now doing wrong? Please let me know what extra information I can provide.

Kind regards, Tom
Tom Robinson 0 Reputation points

2025-10-13T20:56:41.49+00:00

Can anyone help further with this issue?
Anonymous

2025-10-14T06:55:26.36+00:00
Hello Tom,
Thank you for your patience, we were looking into your issue.

Your scenario involves cloud-only users and API-driven provisioning to on-premises AD. The issue is that:

Cloud Sync does not support creating users in on-prem AD (no user writeback).

API-driven provisioning requires proper attribute mappings, scope configuration, and connectivity to the on-prem AD via the provisioning agent.

The “No results” message means the provisioning job did not find any users in scope based on your configuration.

Try these below steps as:
Validate API-Driven Provisioning Setup

Ensure you have installed and registered the Microsoft Entra Provisioning Agent on a server that can reach your on-prem AD. Confirm the agent is healthy in the Microsoft Entra admin center: Microsoft Entra admin center > Identity > Hybrid management > Microsoft Entra Connect > Cloud sync > Agents

refer: https://learn.microsoft.com/en-us/entra/identity/hybrid/verify-sync-tool-version

Check Scope Configuration

In the Provisioning settings, verify:

Scope is set to Sync all users and groups or correctly filtered.

If you selected Sync only assigned users and groups, ensure:

Users are assigned to the app individually or via a group.

For groups, confirm nested group membership is supported (it is not only direct members sync).

Refer:https://learn.microsoft.com/en-us/entra/identity/app-provisioning/configure-automatic-user-provisioning-portal

Validate Attribute Mappings

Ensure required attributes for AD user creation are mapped:

userPrincipalName

sAMAccountName

mail

givenName, surname

Missing mandatory attributes will cause silent skips more understanding: https://learn.microsoft.com/en-us/entra/identity/app-provisioning/customize-application-attributes

Check Permissions

The account used by the provisioning agent must have Create, Update, Delete permissions in on-prem AD and Verify OU target is correct and accessible. Refer: https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-gmsa-cmdlets

Key Limitation

Even with API-driven provisioning, group membership writeback is not supported for cloud-only users unless the users themselves are successfully provisioned to on-prem AD first.

hope this helps!

Thanks!

Tom Robinson 0

Hi @Anonymous ,

Thank you for your detailed response and troubleshooting steps. I've been working through this issue with assistance from Claude (Anthropic's AI assistant), and we've systematically gone through each of your recommendations. Here's what we've found:

1. Validate API-Driven Provisioning Setup ✓ Confirmed:

The Microsoft Entra Provisioning Agent is installed, registered, and showing as "Active" in Microsoft Entra admin center > Identity > Hybrid management > Microsoft Entra Connect > Cloud sync > Agents.

Service "Microsoft Azure AD Connect Provisioning Agent" is running on the domain-joined server Agent status shows as "Active" in the portal

2. Check Scope Configuration ✓ Confirmed:

Initially set to "Sync only assigned users and groups" Assigned the "All Users" group (Dynamic group with 166 members) to the application All 166 users are confirmed members of this group We also verified that the Source Object Scope in the attribute mappings is set to "All records" with no scoping filters

3. Validate Attribute Mappings ✓ This is where we discovered a critical issue:

The API schema had externalId

The API schema had externalId set as both "Required" and "Primary Key" PowerShell verification showed that ALL our cloud-only users have externalId as NULL/empty:

Get-MgUser -All | Select-Object DisplayName, UserPrincipalName, ExternalId, Id

Result: externalId column was empty for all 166 users Actions taken:

Modified the API attribute schema to set id (ObjectId) as the Primary Key instead of externalId Removed the "Required" flag from externalId Confirmed id is marked as both "Required" and "Primary Key" Updated the attribute mapping from externalId → employeeID to id → employeeID Saved the schema changes (which triggered automatic re-provisioning)

Result: Provisioning cycles still complete in ~0.4 seconds with "No results" in the provisioning logs.

4. Check Permissions ✓ Confirmed:

The provisioning agent service account has appropriate permissions in on-premises AD Target OU paths have been tested with both configurations:

Current configuration: CN=Users,DC=mrc,DC=motec,DC=com,DC=au (successfully syncs groups via Cloud Sync) Also tested: OU=Users,DC=mrc,DC=motec,DC=com,DC=au (standard OU format)

Both target containers exist and are accessible Note: Cloud Sync successfully provisions groups to the CN=Users container, which confirms the agent has proper write permissions to on-premises AD

5. Additional Investigation Through our troubleshooting with Claude, we discovered that the Source Object is hardcoded to:

urn:ietf:params:scim:schemas:extension:enterprise:2.0:User

This SCIM enterprise extension schema endpoint may not expose standard cloud-only Entra ID users, which could explain why provisioning finds zero users despite all our configuration being correct.

Current Assessment Despite following all recommended steps and correcting the schema configuration, the API-driven provisioning application still cannot find our cloud-only users. This suggests that the feature may not support our specific use case (provisioning cloud-only Entra ID users to on-premises AD without any prior on-premises presence).

Proposed Alternative Solution Based on Claude's recommendation, we're considering using PowerShell to perform a one-time bulk migration of users from Entra ID to on-premises AD, then using Entra Connect or Cloud Sync to maintain synchronization going forward.

Would you be able to confirm whether API-driven provisioning to on-premises AD is designed to work with cloud-only users (users that have never existed in on-premises AD)? If not, could you recommend the officially supported approach for our scenario?

Below is a PowerShell script Claude helped develop for the bulk user creation approach:

<#
.SYNOPSIS
    Bulk create Active Directory users from Microsoft Entra ID (Azure AD)
.DESCRIPTION
    Exports users from Entra ID and creates matching user accounts in on-premises Active Directory.
    Designed for organizations migrating from cloud-only to hybrid identity.
.NOTES
    Prerequisites:
    - Microsoft.Graph PowerShell module
    - Active Directory PowerShell module
    - Appropriate permissions in both Entra ID and on-premises AD
#>

# ============================================================================
# PART 1: Export Users from Entra ID
# ============================================================================

Write-Host "Connecting to Microsoft Graph..." -ForegroundColor Cyan
Connect-MgGraph -Scopes "User.Read.All"

Write-Host "Retrieving users from Entra ID..." -ForegroundColor Cyan
$entraUsers = Get-MgUser -All -Property Id, DisplayName, UserPrincipalName, GivenName, Surname, Mail, JobTitle, Department, CompanyName, OfficeLocation, MobilePhone, BusinessPhones | 
    Where-Object { $_.UserPrincipalName -notlike "*#EXT#*" } | # Exclude guest users
    Select-Object Id, DisplayName, UserPrincipalName, GivenName, Surname, Mail, JobTitle, Department, CompanyName, OfficeLocation, MobilePhone, BusinessPhones

Write-Host "Found $($entraUsers.Count) users in Entra ID" -ForegroundColor Green

# Export to CSV for reference
$exportPath = "C:\Temp\EntraID_Users_Export_$(Get-Date -Format 'yyyyMMdd_HHmmss').csv"
$entraUsers | Export-Csv -Path $exportPath -NoTypeInformation
Write-Host "Users exported to: $exportPath" -ForegroundColor Green

# ============================================================================
# PART 2: Create Users in On-Premises Active Directory
# ============================================================================

Write-Host "`nPreparing to create users in Active Directory..." -ForegroundColor Cyan

# Configuration - MODIFY THESE VALUES FOR YOUR ENVIRONMENT
$targetOU = "CN=Users,DC=mrc,DC=motec,DC=com,DC=au"  # Target container for user creation
$defaultPassword = ConvertTo-SecureString "ChangeMe123!" -AsPlainText -Force  # Initial password
$domainSuffix = "@mrc.motec.com.au"  # Your domain suffix

# Import Active Directory module
Import-Module ActiveDirectory

# Results tracking
$results = @()
$successCount = 0
$failureCount = 0
$skippedCount = 0

foreach ($user in $entraUsers) {
    $result = [PSCustomObject]@{
        EntraDisplayName = $user.DisplayName
        EntraUPN = $user.UserPrincipalName
        Status = ""
        Message = ""
        ADSamAccountName = ""
    }
    
    try {
        # Generate sAMAccountName (max 20 characters for AD)
        $samAccountName = $user.UserPrincipalName -replace '@.*$', ''  # Remove domain part
        if ($samAccountName.Length -gt 20) {
            $samAccountName = $samAccountName.Substring(0, 20)
        }
        
        # Check if user already exists
        $existingUser = Get-ADUser -Filter "UserPrincipalName -eq '$($user.UserPrincipalName)'" -ErrorAction SilentlyContinue
        if ($existingUser) {
            Write-Host "  [SKIP] User already exists: $($user.DisplayName)" -ForegroundColor Yellow
            $result.Status = "Skipped"
            $result.Message = "User already exists in AD"
            $skippedCount++
            $results += $result
            continue
        }
        
        # Prepare user parameters
        $userParams = @{
            Name = $user.DisplayName
            SamAccountName = $samAccountName
            UserPrincipalName = $user.UserPrincipalName
            GivenName = $user.GivenName
            Surname = $user.Surname
            DisplayName = $user.DisplayName
            EmailAddress = $user.Mail
            Path = $targetOU
            AccountPassword = $defaultPassword
            Enabled = $true
            ChangePasswordAtLogon = $true
        }
        
        # Add optional attributes if they exist
        if ($user.JobTitle) { $userParams.Title = $user.JobTitle }
        if ($user.Department) { $userParams.Department = $user.Department }
        if ($user.CompanyName) { $userParams.Company = $user.CompanyName }
        if ($user.OfficeLocation) { $userParams.Office = $user.OfficeLocation }
        if ($user.MobilePhone) { $userParams.MobilePhone = $user.MobilePhone }
        if ($user.BusinessPhones -and $user.BusinessPhones.Count -gt 0) { 
            $userParams.OfficePhone = $user.BusinessPhones[0] 
        }
        
        # Create the user
        New-ADUser @userParams
        
        Write-Host "  [SUCCESS] Created user: $($user.DisplayName) ($samAccountName)" -ForegroundColor Green
        $result.Status = "Success"
        $result.Message = "User created successfully"
        $result.ADSamAccountName = $samAccountName
        $successCount++
        
    } catch {
        Write-Host "  [ERROR] Failed to create user: $($user.DisplayName) - $($_.Exception.Message)" -ForegroundColor Red
        $result.Status = "Failed"
        $result.Message = $_.Exception.Message
        $failureCount++
    }
    
    $results += $result
}

# ============================================================================
# PART 3: Summary and Results Export
# ============================================================================

Write-Host "`n========================================" -ForegroundColor Cyan
Write-Host "MIGRATION SUMMARY" -ForegroundColor Cyan
Write-Host "========================================" -ForegroundColor Cyan
Write-Host "Total users processed: $($entraUsers.Count)" -ForegroundColor White
Write-Host "Successfully created:  $successCount" -ForegroundColor Green
Write-Host "Skipped (existing):    $skippedCount" -ForegroundColor Yellow
Write-Host "Failed:                $failureCount" -ForegroundColor Red

# Export results
$resultsPath = "C:\Temp\AD_User_Creation_Results_$(Get-Date -Format 'yyyyMMdd_HHmmss').csv"
$results | Export-Csv -Path $resultsPath -NoTypeInformation
Write-Host "`nDetailed results exported to: $resultsPath" -ForegroundColor Cyan

# Show failed users if any
if ($failureCount -gt 0) {
    Write-Host "`nFailed Users:" -ForegroundColor Red
    $results | Where-Object { $_.Status -eq "Failed" } | Format-Table -AutoSize
}

Write-Host "`n========================================" -ForegroundColor Cyan
Write-Host "NEXT STEPS:" -ForegroundColor Cyan
Write-Host "1. Review the results CSV file" -ForegroundColor White
Write-Host "2. Address any failures" -ForegroundColor White
Write-Host "3. Configure Entra Connect to sync these users back to Entra ID" -ForegroundColor White
Write-Host "4. Match users during Entra Connect setup using UserPrincipalName" -ForegroundColor White
Write-Host "========================================" -ForegroundColor Cyan

Disconnect-MgGraph

To use this script:

Install required PowerShell modules if not already installed:

   Install-Module Microsoft.Graph -Scope CurrentUser
   Install-Module ActiveDirectory

Modify the configuration variables:

$targetOU - Your target container path (script uses CN=Users to match your working Cloud Sync configuration) $defaultPassword - Initial password for created users $domainSuffix - Your AD domain suffix

Run the script with appropriate permissions (Global Reader in Entra ID, Account Operator or higher in AD)
Review the exported CSV files for results
After creating users in AD, set up Entra Connect to establish synchronization going forward

Question for Microsoft:

Could you please clarify if there's a documented way to make API-driven provisioning work with cloud-only users, or should we proceed with the PowerShell migration approach?

Thank you for your continued assistance. Special thanks to Claude (Anthropic's AI) for the extensive troubleshooting help and script development!

Kind regards,

Tom

Tom Robinson 0 Reputation points

2025-10-16T21:02:58.8366667+00:00

deleted

1 answer

Your answer

Anonymous

2025-10-10T05:36:10.62+00:00

Hello Tom Robinson,Welcome to Microsoft Q&A Platform. Thank you for reaching out & hope you are doing well.

I will try to clarify your doubts regarding the issue. So basically, the issue is a design limitation of the Group Provisioning feature, not a configuration error.

The group members MUST be hybrid (synchronized from on-premises AD). Will recommend some workarounds below as:

Identify User Type: You can check and confirm that the skipped users are indeed Cloud-Only (check their onPremisesSyncEnabled attribute, which will likely be False or not present).

Move to Supported Users: The only way to get group membership to synchronize is to ensure the members of the cloud-created security group are users who were originally synchronized from your on-premises AD to Entra ID.

Alternative (which is Not Supported by Cloud Sync): If the goal is to fully manage cloud-only users and their membership in on-premises AD, Cloud Sync does not support User Writeback (creating the user object itself in on-premises AD from the cloud).

For full bidirectional user and group provisioning, Microsoft recommends exploring API-driven inbound provisioning to on-premises AD or the legacy, unsupported, Entra Connect User Writeback feature (if the environment permits).

more understanding and clarification at: https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync

https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-configure-entra-to-active-directory#limitations

https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync#comparison-between-microsoft-entra-connect-and-cloud-sync

Hope this helps! If it answered your question, please consider clicking Accept Answer and Upvote. This will help us and others in the community as well. If you need more info, feel free to ask in the comments. Happy to help!

Regards,

Monalisha
Tom Robinson 0 Reputation points

2025-10-13T03:46:23.7166667+00:00

Hi @Anonymous ,

Thanks for you assistance.

To answer your questions:

We only have Cloud-Users

We never had an on-premises AD

I have now implemented an API-driven provisioning to on-premises Active Directory

We are still having issues, however.

In the API-driven provisioning to on-premises Active Directory application I have added Users individually and alternatively as a Group (neither selection worked to provision users to the on-premises AD). In the provisioning log I only see one message: "No results."

What am I now doing wrong? Please let me know what extra information I can provide.

Kind regards, Tom
Tom Robinson 0 Reputation points

2025-10-13T20:56:41.49+00:00

Can anyone help further with this issue?
Tom Robinson 0 Reputation points

2025-10-16T21:02:58.8366667+00:00

deleted

Answer 1

Anonymous

Hello Tom Robinson,
Thank you for your response and the workarounds. You have correctly zeroed in on the fundamental design constraint of Microsoft's hybrid identity features.

Your question was: Could you please clarify if there's a documented way to make API-driven provisioning work with cloud-only users, or should we proceed with the PowerShell migration approach?
To answer that, unfortunately There is no documented, supported way from Microsoft to use API-driven provisioning to directly create cloud-only Entra ID users in on-premises Active Directory. API-driven provisioning is designed for integrating external sources like HR systems (Workday, SAP, etc.), not for migrating or exporting existing cloud-only users from Entra ID to AD. The definitive solution is that the PowerShell migration approach is the required and officially supported method for your scenario.

You should absolutely proceed with your PowerShell script, as it is the only viable path to convert your users to the hybrid status required for all subsequent Entra ID > AD provisioning features.
Thanks for your patience during this issue!
Regards,

Monalisha

Anonymous

2025-10-16T06:27:40.8766667+00:00

Hi Tom Robinson,

Just checking if you have checked the above comment. If my suggested solutions helped you somehow throughout the issue, please accept the answer, if you have further query, please reach out to us in the comments. Happy to help!

Thanks
Tom Robinson 0 Reputation points

2025-10-16T21:14:53.7233333+00:00

Hi @Monalisha Jena ,

What do we do in the case where we add more users to Entra Id? We manage everything in the cloud. Are we run some sort of update PowerShell to bring in new users to AD?

Kind regards,

Tom