SOLVED
Home

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

%3CLINGO-SUB%20id%3D%22lingo-sub-220504%22%20slang%3D%22en-US%22%3EAzure%20AD%20Connect%20-%20Dealing%20with%20incorrectly%20created%20users%20post-sync%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-220504%22%20slang%3D%22en-US%22%3E%3CP%3EWe%20have%20a%20single%20domain%20in%20windows%20AD%2C%20not%20the%20same%20as%20our%20verified%20domain%20in%20Azure%20AD%20(through%20365).%26nbsp%3B%20If%20a%20user%20was%20not%20set%20up%20to%20use%20the%20%22verified%22%20suffix%20in%20their%20user%20principal%20name%2C%20Azure%20AD%20Connect%20will%20create%20a%20user%20with%20the%20traditional%20%22onmicrosoft.com%22%20UPN%20in%20azure.%26nbsp%3B%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThis%20makes%20sense%2C%20but%20I%20want%20to%20understand%20this%20better%2C%20because%20if%20this%20happens%20by%20mistake%20I%20do%20not%20currently%20know%20how%20to%20%22delete%22%20or%20%22merge%22%2C%20or%20perhaps%20%22change%20the%20sync%20target%22%20for%20that%20unmatched%20account.%26nbsp%3B%20In%20this%20scenario%20assume%20that%20the%20user%26nbsp%3B%3CEM%3Edid%3C%2FEM%3E%20exist%20already%20in%20Azure%20AD%20with%20a%20proper%20verified%20%22%40company.com%22%20UPN%2C%20but%20now%20they%20have%20an%20incorrect%20%22new%22%20account.%26nbsp%3B%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWhat%20should%20be%20done%20in%20this%20situation%3F%26nbsp%3B%20Currently%20I%20have%20successfully%20gone%20through%20the%20process%20of%20disabling%20the%20sync%2C%20deleting%20the%20new%20incorrect%20user%20in%20Azure%20AD%2C%20fixing%20the%20UPN%20in%20windows%20server%20AD%2C%20and%20then%20re-syncing.%26nbsp%3B%20This%20seems%20like%20a%20nuclear%20approach%20for%20such%20a%20localized%20issue.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAny%20guidance%20is%20appreciated.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-220504%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EAD%20Connect%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EAzure%20AD%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-286262%22%20slang%3D%22en-US%22%3ERe%3A%20Azure%20AD%20Connect%20-%20Dealing%20with%20incorrectly%20created%20users%20post-sync%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-286262%22%20slang%3D%22en-US%22%3E%3CP%3ENow%20under%20the%20Azuer%20active%20directory%20web%2C%20under%20users%2C%20Deleted%20users%2C%20select%20the%20users%20and%20Delete%20Permanently.%20Then%20drag%20the%20users%20back%20into%20the%20OU%20Initial%20sync%20from%20local%20AD%20and%20the%20users%20will%20be%20sync.%3C%2FP%3E%3CP%3EI%20had%20an%20azuer%20global%20admin%20account%20that%20created%20a%20duplicate%20account%20name1234%40domain.nam%20and%20I%20could%20not%20get%20rid%20of%20it.%20taking%20the%20user%20out%20of%20the%20OU%2C%20sync%20(this%26nbsp%3Bwill%20add%20the%20name1234%20user%20to%20the%20deleted%20users%20in%20Azuer)%2C%20then%20taking%20global%20admin%20off%20the%20user%20in%20Azuer%2C%20then%20sync%2C%20then%20delete%20like%20I%20listed%20above%2C%20then%20move%20user%20back%20to%20OU%2C%20then%20sync.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThanks%20to%20this%20conversation%20I%20was%20able%20to%20find%20my%20way.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-221191%22%20slang%3D%22en-US%22%3ERe%3A%20Azure%20AD%20Connect%20-%20Dealing%20with%20incorrectly%20created%20users%20post-sync%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-221191%22%20slang%3D%22en-US%22%3EOk%2C%20I%20injected%20a%20word%20while%20reading%20your%20first%20reply%2C%20misread%20that%20it%20would%20do%20it%20for%20me.%20Powershell%20can%20do%20it%20then%2C%20which%20is%20fine%20-%20much%20better%20than%20disabling%20the%20sync.%20Thank%20you%20again.%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-221180%22%20slang%3D%22en-US%22%3ERe%3A%20Azure%20AD%20Connect%20-%20Dealing%20with%20incorrectly%20created%20users%20post-sync%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-221180%22%20slang%3D%22en-US%22%3E%3CP%3ENo%2C%20it%20will%20not%20auto-delete%20it%2C%20as%20the%20on-premises%20account%26nbsp%3Band%20the%20%22duplicate%22%20cloud%20one%20are%20now%20%22linked%22.%20But%20you%20can%20delete%20it%20directly%20from%20O365%20without%20having%20to%20disable%20DirSync%20(use%20Remove-MsolUser%2FRemove-AzureADUser).%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-221178%22%20slang%3D%22en-US%22%3ERe%3A%20Azure%20AD%20Connect%20-%20Dealing%20with%20incorrectly%20created%20users%20post-sync%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-221178%22%20slang%3D%22en-US%22%3ESo%20after%20I%20fixed%20the%20local%20account%20to%20have%20the%20correct%20UPN%20suffix%2C%20it%20would%20have%20auto-deleted%20the%20duplicate%20account%20it%20created%2C%20and%20synced%20to%20the%20correct%20one%3F%20I%20guess%20I%20should%20have%20given%20it%20more%20time.%20Thanks%20for%20the%20comprehensive%20response.%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-221175%22%20slang%3D%22en-US%22%3ERe%3A%20Azure%20AD%20Connect%20-%20Dealing%20with%20incorrectly%20created%20users%20post-sync%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-221175%22%20slang%3D%22en-US%22%3E%3CP%3EYou%20don't%20need%20to%20disable%20the%20sync%2C%20simply%20delete%20the%20%22duplicate%22%20account.%20As%20for%20avoiding%20such%20issues%20in%20the%20future%2C%20add%20the%20%22verified%22%20suffix%20as%20additional%20UPN%20suffix%20on-premises%20and%20update%20any%20such%20accounts.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EWhen%20creating%20the%20accounts%2C%20Azure%20AD%20looks%20at%20the%20UPN%20value%20and%20if%20its%20populated%2C%20it%20will%20use%20it%20to%20create%20the%20corresponding%20account%20in%20O365.%20If%20the%20UPN%20doesn't%20match%20a%20verified%20domain%2C%20it%20will%20be%20replaced%20with%20the%20default%20%40tenant.onmicrosoft.com%20value.%20If%20the%20UPN%20is%20empty%2C%20the%20SamAccountName%20attribute%20will%20be%20used%20instead%2C%20with%20the%20default%20domain.%20Similar%20rules%20apply%20to%20SMTP%20addresses%3A%20%3CA%20href%3D%22https%3A%2F%2Fsupport.microsoft.com%2Fen-us%2Fhelp%2F3190357%2Fhow-the-proxyaddresses-attribute-is-populated-in-azure-ad%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fsupport.microsoft.com%2Fen-us%2Fhelp%2F3190357%2Fhow-the-proxyaddresses-attribute-is-populated-in-azure-ad%3C%2FA%3E%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EYou%20can%20also%20use%20the%20so-called%20soft-matching%20mechanism%20to%20make%20sure%20the%20on-premises%20object%20%22links%22%20correctly%20to%20an%20already%20created%20cloud%20one%3A%20%3CA%20href%3D%22http%3A%2F%2Fsupport.microsoft.com%2Fkb%2F2641663%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttp%3A%2F%2Fsupport.microsoft.com%2Fkb%2F2641663%3C%2FA%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-531311%22%20slang%3D%22en-US%22%3ERe%3A%20Azure%20AD%20Connect%20-%20Dealing%20with%20incorrectly%20created%20users%20post-sync%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-531311%22%20slang%3D%22en-US%22%3E%3CP%3EDepending%20on%20the%20exact%20request%20and%20setup%20if%20you%20verify%20the%20domain%20in%20Azure%20AD%20after%20that%20once%20the%20users%20are%20synced%20with%20the%20%22wrong%22%20domain%20and%20not%20using%20the%20proper%20UPN%20you%20can%20also%20do%20something%20which%20is%20called%20soft%20and%20hard%20match%20you%20can%20read%20more%20here%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%22%3C%2FP%3E%3CH1%20id%3D%22toc-hId-1899432285%22%20id%3D%22toc-hId-1899432285%22%3ESoft%20(SMTP)%20vs.%20Hard%20(immutableID)%20matching%20with%20Azure%20AD%20Connect%3C%2FH1%3E%3CDIV%20class%3D%22info-bar%22%3E%26nbsp%3B%3C%2FDIV%3E%3CDIV%20class%3D%22the-content%22%3E%3CP%3EIf%20you%20are%20setting%20up%20Directory%20Synchronization%20from%20scratch%20(there%20are%20no%20users%20in%20the%20cloud%20yet)%2C%20then%20Azure%20AD%20Connect%20will%20be%20pretty%20straightforward%E2%80%93the%20on-premises%20objects%20(and%20passwords%20if%20you%20choose%20that%20option)%20will%20be%20synchronized%20to%20the%20cloud%2C%20and%20you%20can%20assign%20services%20to%20the%20user%20accounts%20from%20there.%3C%2FP%3E%3CP%3EBut%20what%20if%20you%20already%20have%20user%20accounts%20in%20the%20cloud%20which%20correspond%20to%20already%20existing%20user%26nbsp%3Bobjects%20in%20the%20on-premises%20directory%2C%20and%20Directory%20Synchronization%20has%20not%20yet%20been%20configured%20between%20them%3F%20For%20example%2C%20if%20your%20organization%20previously%20migrated%20mailboxes%20to%20Office%20365%20using%20the%26nbsp%3Bcutover%20method%20or%20a%20third%20party%20tool.%20Or%2C%20if%20you%20had%20users%20provisioned%20for%20another%20Microsoft%20Online%20Service%20such%20as%20CRM%2C%20before%20you%20attempted%20mailbox%20migration.%3C%2FP%3E%3CP%3EIn%20cases%20like%20these%2C%20you%20may%20need%20to%20create%20a%20matching%20mechanism%20between%20the%20on-premises%20accounts%20and%20the%20cloud-based%20ones%2C%20so%20that%20Azure%20AD%20Connect%20knows%20that%20they%20refer%20to%20the%20same%20user.%20%26nbsp%3BThere%20are%20two%20basic%20methods%20to%20create%20this%20%E2%80%9Cmatching%E2%80%9D%3A%3C%2FP%3E%3COL%3E%3CLI%3ESoft%20match%20(also%20known%20as%20%3CA%20href%3D%22https%3A%2F%2Fsupport.microsoft.com%2Fen-us%2Fhelp%2F2641663%2Fhow-to-use-smtp-matching-to-match-on-premises-user-accounts-to-office-365-user-accounts-for-directory-synchronization%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3ESMTP%20matching%3C%2FA%3E)%3C%2FLI%3E%3CLI%3EHard%20match%20(by%20%3CA%20href%3D%22https%3A%2F%2Fblogs.technet.microsoft.com%2Fpraveenkumar%2F2014%2F04%2F11%2Fhow-to-do-hard-match-in-dirsync%2F%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3EimmutableID%3C%2FA%3E).%3C%2FLI%3E%3C%2FOL%3E%3CH3%20id%3D%22toc-hId--1045751686%22%20id%3D%22toc-hId--1045751686%22%3E%3CSPAN%3E%3CSTRONG%3ESoft%20Matching%20using%20the%20SMTP%20address%3C%2FSTRONG%3E%3C%2FSPAN%3E%3C%2FH3%3E%3CP%3ETo%20create%20soft%20matches%2C%20which%20will%20be%20adequate%20in%2095%25%20of%20situations%2C%20you%20will%20need%20to%20ensure%20first%20of%20all%20that%20your%20UPN%20suffixes%20match%20between%20on-premises%20and%20cloud-based%20accounts.%20What%20do%20we%20mean%20by%20this%3F%20%26nbsp%3BIt%20means%20that%20your%20users%E2%80%99%20sign-in%20needs%20to%20be%20tied%20to%20the%20domain%20of%20your%20primary%20email%20address%20in%20both%20the%3C%2FP%3E%3CP%3EFirst%2C%20when%20you%20open%20the%20properties%20of%20a%20user%20account%20object%2C%20this%20object%20should%20have%20the%20%3CSTRONG%3Eemail%20address%20field%3C%2FSTRONG%3E%20filled%20out%20(the%20primary%20SMTP%20address%20for%20the%20user)%E2%80%93so%20be%20sure%20that%20is%20the%20case%20first.%20%26nbsp%3BNow%20take%20a%20look%20under%20the%20%3CSTRONG%3EAccount%3C%2FSTRONG%3E%20tab%2C%20and%20you%20should%20see%20the%20user%26nbsp%3Blogon%20name%20followed%20by%20a%20suffix.%3C%2FP%3E%3CP%3EThe%20goal%20is%20to%20have%20this%20logon%20name%20be%20%3CEM%3E%3CSTRONG%3Eusername%40domain.com%3C%2FSTRONG%3E%3C%2FEM%3E%E2%80%93that%20is%2C%20the%20email%20address%E2%80%93and%20not%20the%20local%20domain%20name%26nbsp%3B%3CEM%3Eusername%40domain.local%3C%2FEM%3E.%20Note%20that%20you%20can%20also%20bulk-select%20accounts%20and%20make%20this%20suffix%20change%20on%20many%20objects%20at%20once.%22%3C%2FP%3E%3C%2FDIV%3E%3C%2FLINGO-BODY%3E
Myles Gallagher
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.

6 Replies
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."

Related Conversations
Tabs and Dark Mode
cjc2112 in Discussions on
35 Replies
Extentions Synchronization
ChirmyRam in Discussions on
3 Replies
flashing a white screen while open new tab
Deleted in Discussions on
14 Replies
Security Community Webinars
Valon_Kolica in Security, Privacy & Compliance on
9 Replies