07-31-2018 06:34 AM
07-31-2018 06:34 AM
We have a single domain in windows AD, not the same as our verified domain in Azure AD (through 365). If a user was not set up to use the "verified" suffix in their user principal name, Azure AD Connect will create a user with the traditional "onmicrosoft.com" UPN in azure.
This makes sense, but I want to understand this better, because if this happens by mistake I do not currently know how to "delete" or "merge", or perhaps "change the sync target" for that unmatched account. In this scenario assume that the user did exist already in Azure AD with a proper verified "@company.com" UPN, but now they have an incorrect "new" account.
What should be done in this situation? Currently I have successfully gone through the process of disabling the sync, deleting the new incorrect user in Azure AD, fixing the UPN in windows server AD, and then re-syncing. This seems like a nuclear approach for such a localized issue.
Any guidance is appreciated.
07-31-2018 11:16 AMSolution
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-az...
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
07-31-2018 11:19 AM
07-31-2018 11:24 AM
No, it will not auto-delete it, as the on-premises account and the "duplicate" cloud one are now "linked". But you can delete it directly from O365 without having to disable DirSync (use Remove-MsolUser/Remove-AzureADUser).
07-31-2018 12:02 PM
11-13-2018 03:15 PM
Now under the Azuer active directory web, under users, Deleted users, select the users and Delete Permanently. Then drag the users back into the OU Initial sync from local AD and the users will be sync.
I had an azuer global admin account that created a duplicate account firstname.lastname@example.org and I could not get rid of it. taking the user out of the OU, sync (this will add the name1234 user to the deleted users in Azuer), then taking global admin off the user in Azuer, then sync, then delete like I listed above, then move user back to OU, then sync.
Thanks to this conversation I was able to find my way.
05-04-2019 12:09 PM
Depending on the exact request and setup if you verify the domain in Azure AD after that once the users are synced with the "wrong" domain and not using the proper UPN you can also do something which is called soft and hard match you can read more here:
If you are setting up Directory Synchronization from scratch (there are no users in the cloud yet), then Azure AD Connect will be pretty straightforward–the on-premises objects (and passwords if you choose that option) will be synchronized to the cloud, and you can assign services to the user accounts from there.
But what if you already have user accounts in the cloud which correspond to already existing user objects in the on-premises directory, and Directory Synchronization has not yet been configured between them? For example, if your organization previously migrated mailboxes to Office 365 using the cutover method or a third party tool. Or, if you had users provisioned for another Microsoft Online Service such as CRM, before you attempted mailbox migration.
In cases like these, you may need to create a matching mechanism between the on-premises accounts and the cloud-based ones, so that Azure AD Connect knows that they refer to the same user. There are two basic methods to create this “matching”:
To create soft matches, which will be adequate in 95% of situations, you will need to ensure first of all that your UPN suffixes match between on-premises and cloud-based accounts. What do we mean by this? It means that your users’ sign-in needs to be tied to the domain of your primary email address in both the
First, when you open the properties of a user account object, this object should have the email address field filled out (the primary SMTP address for the user)–so be sure that is the case first. Now take a look under the Account tab, and you should see the user logon name followed by a suffix.
The goal is to have this logon name be email@example.com–that is, the email address–and not the local domain name firstname.lastname@example.org. Note that you can also bulk-select accounts and make this suffix change on many objects at once."