Forum Discussion
API-driven provisioning field mapping changes resynchronize all users and groups
We have configured API-driven provisioning for on-premises Active Directory, along with Azure AD Connect, to synchronize on-premises AD users with Azure Entra ID.
As part of the provisioning setup, we have used a separate Organizational Unit (OU) in on-premises AD (designated as the default OU for new users) while configuring API-driven provisioning.
We are attempting to make some changes to the API field mapping, specifically the ‘UserPrincipalName’ regular expression (custom domain) and the ‘manager’ field, and saving the configuration. Upon attempting to save, a prompt appears (as highlighted below screenshot), indicating that this action will resynchronize all users and groups.
Could you please clarify:
- Will this resynchronization update any existing users outside the default provisioning Organizational Unit (OU)?
- Specifically, what does the resynchronization operation update? For instance, will it modify the 'UserPrincipalName' and 'manager' attributes for all users including old users outside of provisioning Organizational Unit (OU)?
Screen Shot - While Saving Mapping.
The scope of impact is any joined user, which on the Active Directory side can be located anywhere - in our outside of the default creation organisational unit.
The default organisational unit is where creations are effected, but if they're then moved elsewhere in the directory outside of that default organisational unit, the synchronisation process still tracks them based on whichever attribute(s) was nominated as the "match objects using this attribute = yes" definition, as shown below:
As an aside, this holds true for both users and groups.
That's the scope question answered.
Moving onto LJohn's second question of what is "changed" in Active Directory, the answer is all attribute mappings where "apply this mapping = always". Conversely, any attribute mapping where "apply this mapping = only during creation" will not be updated.
Generally speaking, nothing should change other than the attribute whose mapping you've updated.
Just to be clear (I'm probably being overly cautious in making this point), if you update an attribute mapping then that is applied to all joined accounts retrospectively (assuming the provisioning rule has the "update" target objects action setting checked). It isn't the case that the updated rule mapping is only applied to new account creations. This is where the "apply this mapping" setting acts as an important determinant.
Cheers,
Lain
2 Replies
Wondering if you ever got a resolution for this, we are running into the same issue. Not sure if its going to affect our entire AD or just the provisioning OU
The scope of impact is any joined user, which on the Active Directory side can be located anywhere - in our outside of the default creation organisational unit.
The default organisational unit is where creations are effected, but if they're then moved elsewhere in the directory outside of that default organisational unit, the synchronisation process still tracks them based on whichever attribute(s) was nominated as the "match objects using this attribute = yes" definition, as shown below:
As an aside, this holds true for both users and groups.
That's the scope question answered.
Moving onto LJohn's second question of what is "changed" in Active Directory, the answer is all attribute mappings where "apply this mapping = always". Conversely, any attribute mapping where "apply this mapping = only during creation" will not be updated.
Generally speaking, nothing should change other than the attribute whose mapping you've updated.
Just to be clear (I'm probably being overly cautious in making this point), if you update an attribute mapping then that is applied to all joined accounts retrospectively (assuming the provisioning rule has the "update" target objects action setting checked). It isn't the case that the updated rule mapping is only applied to new account creations. This is where the "apply this mapping" setting acts as an important determinant.
Cheers,
Lain
