Forum Discussion
Azure AD Connect - Dealing with incorrectly created users post-sync
You don't need to disable the sync, simply delete the "duplicate" account. As for avoiding such issues in the future, add the "verified" suffix as additional UPN suffix on-premises and update any such accounts.
When creating the accounts, Azure AD looks at the UPN value and if its populated, it will use it to create the corresponding account in O365. If the UPN doesn't match a verified domain, it will be replaced with the default @tenant.onmicrosoft.com value. If the UPN is empty, the SamAccountName attribute will be used instead, with the default domain. Similar rules apply to SMTP addresses: https://support.microsoft.com/en-us/help/3190357/how-the-proxyaddresses-attribute-is-populated-in-azure-ad
You can also use the so-called soft-matching mechanism to make sure the on-premises object "links" correctly to an already created cloud one: http://support.microsoft.com/kb/2641663
You don't need to disable the sync, simply delete the "duplicate" account. As for avoiding such issues in the future, add the "verified" suffix as additional UPN suffix on-premises and update any such accounts.
When creating the accounts, Azure AD looks at the UPN value and if its populated, it will use it to create the corresponding account in O365. If the UPN doesn't match a verified domain, it will be replaced with the default @tenant.onmicrosoft.com value. If the UPN is empty, the SamAccountName attribute will be used instead, with the default domain. Similar rules apply to SMTP addresses: https://support.microsoft.com/en-us/help/3190357/how-the-proxyaddresses-attribute-is-populated-in-azure-ad
You can also use the so-called soft-matching mechanism to make sure the on-premises object "links" correctly to an already created cloud one: http://support.microsoft.com/kb/2641663