Provisioning issues to AzureAD due to sync with AD

[nvachhani]

I am testing AzureAD provisioning with the AzureAD connector and seeing the following error:

"Unable to update the specified properties for on-premises mastered Directory Sync objects or objects currently undergoing migration."

Reading up on this, it looks like Microsoft Graph API cannot assign/remove access to an AzureAD account if it is marked as being synced from AD. Has anyone seen this before? We could possibly provision exclusively to AD and let it sync with AzureAD but there are AAD Groups/entitlements in AzureAD that are not in AD so I am unsure of how to accomplish this.

[rushikeshvartak]

The error you're encountering, "Unable to update the specified properties for on-premises mastered Directory Sync objects or objects currently undergoing migration," typically occurs when trying to update or manage an object in Azure Active Directory (AAD) that is synchronized from an on-premises Active Directory (AD) environment. This is because the object is considered "mastered" on-premises, meaning that changes to certain attributes must be made in the on-premises AD rather than directly in AAD.

Issue Overview:

1. Synchronized Objects: Objects that are synchronized from AD to AAD using Azure AD Connect cannot have certain properties modified directly in AAD. Instead, these properties need to be modified in the on-premises AD, and then the changes will be synchronized to AAD.

2. Microsoft Graph API Limitation: The limitation you're reading about relates to how the Microsoft Graph API (or other AzureAD management tools) interacts with these synchronized objects. Direct modifications to these objects in AAD, especially for properties like group memberships or entitlements, are restricted.

[NM]

Hi @nvachhani , it is an expected behaviour if the account/user was synced from AD .. we have restriction on some of the properties.

[nvachhani]

Understood.

How can we differentiate between AD synced groups and groups exclusive to AzureAD?

For example, when removing access as part of termination, tasks with AzureAD entitlements that are synced with AD will fail with the aforementioned error but tasks with AzureAD entitlements that were created in AzureAD will process correctly. Can this be accomplished with timing of the access removal? If so, how can this be done?

[rushikeshvartak]

To differentiate between AD synced groups and groups exclusive to AzureAD, you can look at the source attribute in Azure AD. Here’s how you can identify them:

1. AD Synced Groups: These groups are synchronized from your on-premises Active Directory using Azure AD Connect. In Azure AD, these groups will have the source attribute set to “Windows Server AD” or similar1.
2. AzureAD Exclusive Groups: These groups are created directly in Azure AD and will have the source att...1.

Timing of Access Removal

To handle access removal effectively, especially during terminations, you can follow these steps:

1. Identify Group Source: Before removing access, check if the group is synced from AD or exclusive to AzureAD.
2. Remove Access in AD First: For AD synced groups, remove the user from the group in your on-premises AD. This change will then sync to Azure AD.
3. Remove Access in AzureAD: For groups exclusive to AzureAD, you can directly remove the user from the group in Azure AD.

[NM]

Hi @nvachhani , what do you want to manage On Prem groups from AzureAD endpoint.

Import groups exclusively created in AzureAD(cloud) groups.

[nvachhani · Accepted solution]

I was able to filter out these groups by using  the ENTITLEMENT_FILTER_JSON with the following:

{
"group_filter": "onPremisesSyncEnabled eq false"
}