Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community
SOLVED

Azure AD Connect - Dealing with incorrectly created users post-sync

Brass Contributor

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.

9 Replies
best response confirmed by Myles Gallagher (Brass Contributor)
Solution

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

So after I fixed the local account to have the correct UPN suffix, it would have auto-deleted the duplicate account it created, and synced to the correct one? I guess I should have given it more time. Thanks for the comprehensive response.

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).

Ok, I injected a word while reading your first reply, misread that it would do it for me. Powershell can do it then, which is fine - much better than disabling the sync. Thank you again.

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 name1234@domain.nam 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.

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:

 

"

Soft (SMTP) vs. Hard (immutableID) matching with Azure AD Connect

 

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”:

  1. Soft match (also known as SMTP matching)
  2. Hard match (by immutableID).

Soft Matching using the SMTP address

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 username@domain.com–that is, the email address–and not the local domain name username@domain.local. Note that you can also bulk-select accounts and make this suffix change on many objects at once."

@Vasil Michev Hey I come from the future and admins are still making the same mistakes.

 

I can't delete the Office 365 user because the user has a EXO mailbox.

 

Now I have two duplicated users in AAD:

 

Is there any way I can change the sync target (user1@company.local --> user1@company.com.ni )? I tried to change the ImmutableId but failed.

 

Thanks in advance.

@Marconi Poveda 

 

I see this is old and somewhat unanswered. I am sure you have likely found the solution by now, but for those that have this question. 

 

---

 

When you end up with duplicate user accounts, while attempting to soft-match (ie. forgetting to update the UPN, or a slight variation in the logon name.) Even after simply deleting the duplicated account, you will still be unable to get the correct existing account in the AAD to soft-match until you remove the duplicate from the deleted users section of the Office365 portal. 

 

To do this, use the following PowerShell cmdlet remove the account from the recycle bin;

 

Remove-MsolUser -UserPrincipalName <Incorrectaccountname@domain.com> -RemoveFromRecycleBin

 

You can then perform a new AAD Export and your accounts will be soft-matched correctly. 

 

More Guidance regarding removing deleted users: 

https://practical365.com/exchange-server/permanently-remove-deleted-users-office-365/

 

Hope this helps. 

@Vasil Michev 

 

 

i need your help please i was facing a problem 

that problem after i trouble shooting in azure because there are many feature are not available so the trouble shoot show me that the problem from the ad connect so i uninstall it and then reach the cloud to see the users so i found them in deleted user so i decided to restore them again and every thing worked perfectly the next day i found that the users cant login into there profiles on their PC and an automatically New profile without any data created without any permission and when i try to delete the new user it recreate itself so what is the solution because i facing a big problem in my job and this is the diagram show how the company work 

 WhatsApp Image 2024-02-04 at 5.55.40 PM.jpeg

1 best response

Accepted Solutions
best response confirmed by Myles Gallagher (Brass Contributor)
Solution

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

View solution in original post