Microsoft has made a couple pretty big changes to how UPN syncs and how soft matching works when syncing to Azure AD.
Synchronization of UPN Updates for Licensed/Managed Users
Historically Microsoft has blocked all updates to UserPrincipalName via Sync from On-premises if the User is managed (non-federated) and has been assigned a license. This behaviour is described under scenario 2 of article User names in O365, Azure or Intune don’t match on the on-premises UPN or alternate login ID (in the process of being updated).
This feature changes that behaviour, allowing the update to be processed. This has been enabled by default in tenants created after June 15, 2015 but tenants created before June 15, 2015 now have the option to opt-in to this behaviour by running the PowerShell cmdlet:
Set-MsolDirSyncFeature -Feature SynchronizeUpnForManagedUsers-Enable $True
Note: Unfortunately, this does not affect the federated domain to federated domain rename restriction described in scenario 3 of this article https://support.microsoft.com/en-us/kb/2669550.
UserPrincipalName Soft Match (Preview)
When this feature is enabled the normal soft-match logic still applies, but if we fail to match on the primary SMTP Microsoft will fall back and attempt a match based on UserPrincipalName instead. This is particularly useful for customers who need to match on-prem Active Directory accounts with existing accounts created in the cloud, but are not using Exchange Online and therefore generally don’t have a reason or means to set SMTP in the cloud.
The documentation for this feature is coming soon, but the customer can enable this feature by running the PowerShell cmdlet
Set-MsolDirSyncFeature -Feature EnableSoftMatchOnUpn -Enable $True
Identity Synchronization and Duplicate Attribute Resiliency
Duplicate Attribute Resiliency is a feature in Azure Active Directory designed to eliminate friction caused by UserPrincipalName and ProxyAddress conflicts when running one of Microsoft’s synchronization tools. The UserPrincipalName and ProxyAddress attributes are generally required to be unique across all User, Group, or Contact objects in a given Azure Active Directory directory.
Instead of completely failing to provision or update an object with a duplicate attribute, Azure Active Directory “quarantines” the duplicate attribute which would violate the uniqueness constraint. If this attribute is required for provisioning, like UserPrincipalName, the service will assign a placeholder value. The format of these temporary values is
+<4digitnumber>@.onmicrosoft.com
If the attribute is not required, like a ProxyAddress, Azure Active Directory simply quarantines the conflict attribute and proceeds with the object creation or update.
For more information about this, see https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnectsyncservice-duplicate-attribute-resiliency/
No responses yet