Azure AD Sync Error: Quarantined Attribute Value Must Be Unique

Hi All

We are tyring to implement a password hash sync for our local AD and Azure AD. The first thing we did was to uninstalled the old Azure AD connect from another server which We assume should have removed any old connection or configuration setting and We set up another one on a different server with all the new sync configuration.

Later we created a new OU for sync testing and move a few user over to the test OU. We run into some duplicate issue which we were able to clear beside the one such as in the attachment. We figured out that the account must have been either created first in Azure AD or already synced to an old domain server. The username in that problematic account that synced with the active directory is definitely incorrect from what We see inside the AD server. Now we need to at least know is what we suspect is correct

It sounds like you’re working on implementing password hash synchronisation between your local Active Directory (AD) and Azure AD. Let’s break it down:

  1. Password Hash Synchronisation (PHS): This method allows users to log in to Azure AD using the same username and password they use for their on-premises AD login. It synchronises a hash of the user’s password from your local AD to Azure AD. Microsoft refers to this pattern as “same sign-on” because users can seamlessly log in to both environments.

  2. Process Overview:

    • You uninstalled the old Azure AD Connect from one server, which should have removed any old configurations.
    • You set up a new Azure AD Connect instance on a different server with updated sync configurations.
    • You created a new Organizational Unit (OU) for sync testing and moved some users there.
    • Despite resolving most duplicate issues, there’s still one problematic account.
    • You suspect this account was initially created in Azure AD or previously synced to an old domain server.
    • The username associated with this account in Azure AD doesn’t match what you see in your local AD.
  3. Verifying Suspicions:
    To confirm your suspicions, consider the following steps:

    • Check the account’s creation date in Azure AD. If it predates your recent sync setup, it likely existed there before.
    • Review the account’s history in your local AD to see if it was previously synced to an old domain server.
  4. Additional Considerations:

    • Ensure you have set a temporary password on-premises for the problematic account. The force password change at the next logon flag isn’t automatically synced; you must handle it manually.
    • If you encounter further issues, refer to Microsoft’s documentation on connecting password hash synchronization for troubleshooting and best practices.