Directory sync errors. Duplicate attributes.

Question

Had these directory sync errors for a while now.

An ‎Microsoft Entra ID‎ cloud ‎user‎ and an on-premises ‎user‎ have identical ‎UserPrincipalName‎ values of ‎****@email.com‎**. Attribute values must be unique to each ‎user‎. To fix this, decide which ‎user‎ should use the attribute, then change or remove the identical attribute from the other ‎user‎. You can also delete the entire cloud ‎user‎.

Did fix most of them only have this one left. This one has a specific thing about it. In the Entra admin center it shows that both of the accounts (the real one and the auto generated one user+<4 numbers>@email.onmicrosoft.com) are on-premise synced.
The procedure I followed for the other accounts was to delete the auto generated user from Entra. Then from my computer in PowerShell I ran these commands:

Update-MgUser -UserId "<UserID>" -OnPremisesImmutableId "<Real Immutable ID>"  

But this command gave me this error for only the last user that accounts are both synced on premise:

Update-MgUser : Insufficient privileges to complete the operation.
Status: 403 (Forbidden)
ErrorCode: Authorization_RequestDenied
Date: 2026-07-10T06:32:31
Headers:
Transfer-Encoding             : chunked
Vary                          : Accept-Encoding
Strict-Transport-Security     : max-age=31536000
x-ms-resource-unit            : 1 
Cache-Control                 : no-cache 
Date                          : Fri, 10 Jul 2026 06:32:30 GMT 
At line:1 char:1 
+ Update-MgUser -UserId "<UserID>" -OnPremi ... 
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~     
	+ CategoryInfo          : InvalidOperation: ({ UserId = <UserID>...softGraphUser }:<>f__AnonymousType56`3) [Update-MgU    ser_UpdateExpanded], Exception     
	+ FullyQualifiedErrorId : Authorization_RequestDenied,Microsoft.Graph.PowerShell.Cmdlets.UpdateMgUser_UpdateExpand    ed

Answer 1

Hello**Kristijans Vēveris,**

Greetings! Thanks for raising this question in the Q&A forum.

The reason this last account behaves differently from the others is important. For the accounts you already fixed, the duplicate object was almost certainly cloud only, so setting OnPremisesImmutableId from the cloud side with Update-MgUser was a valid hard match that let the correct on-premises object claim it on the next sync cycle. For this remaining pair, both the real account and the auto generated user+####@tenant.onmicrosoft.com account already show as on-premises synced in the Entra admin center. That means both objects already have a source of authority in Windows Server AD. Microsoft Graph blocks writes to OnPremisesImmutableId on an object that is already actively synced from on-premises, because that attribute is meant to be owned by Microsoft Entra Connect, not overwritten through the API while the object is still under sync control. This is why you get Authorization_RequestDenied even though the same command worked for your other accounts, and it is not primarily a role or scope problem in this case.

Rule out the permission angle first Confirm you were connected with a role that includes the sensitive hybrid identity operation, ideally Global Administrator or Hybrid Identity Administrator, and that the session was consented with the Directory.AccessAsUser.All delegated scope in addition to User.ReadWrite.All. If you were using only User Administrator, elevate and retry once to eliminate this as a variable, but expect the same 403 given both objects are already synced.

Find both on-premises AD objects behind the collision On a domain controller or a machine with the AD PowerShell module, run

Get-ADUser -Filter "UserPrincipalName -eq '******@email.com'" -Properties UserPrincipalName,DistinguishedName,ObjectGUID,mS-DS-ConsistencyGuid

You are looking for two separate on-premises objects that both resolve to the same UPN. One is the real employee's object, the other is typically a stale, duplicate, or leftover object such as a disabled test account, an object left over from a rename or migration, or a re-created account that reused the old UPN.

Decide which on-premises object is authoritative Confirm with HR or the account owner which AD object corresponds to the actual active employee. The other object is the one that needs to stop claiming that UPN.

Resolve the conflict at the source, not in the cloud On the non-authoritative on-premises object, either change its UserPrincipalName to a non-colliding value, disable it, or move it out of the organizational unit scoped for Microsoft Entra Connect sync if it is no longer needed. Do not attempt to fix this by editing OnPremisesImmutableId through Graph, since the object is still under sync authority and the write will keep failing by design.

Force a sync cycle and confirm resolution From the Entra Connect server run

Start-ADSyncSyncCycle -PolicyType Delta

Then check the Entra Connect Health portal or the Entra admin center sync errors report to confirm the duplicate attribute error for this user has cleared. If it persists, run a full import and full sync instead of delta to make sure the change is picked up.

Use Synchronization Service Manager if the objects are hard to identify If you cannot tell which connector space object maps to which cloud user, open miisclient.exe on the Entra Connect server, search the metaverse for the UPN in question, and inspect both connector space entries and their export errors. This will show you the exact distinguishedName of each on-premises object contributing to the conflict.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix