Azure AD Sign in issue: “The account might not exist or it might not be synchronized"

%3CLINGO-SUB%20id%3D%22lingo-sub-1563274%22%20slang%3D%22en-US%22%3ERe%3A%20Azure%20AD%20Sign%20in%20issue%3A%20%E2%80%9CThe%20account%20might%20not%20exist%20or%20it%20might%20not%20be%20synchronized%22%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1563274%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F29544%22%20target%3D%22_blank%22%3E%40unnie%20ayilliath%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3EBecause%20you%20were%20using%20Okta%20%5Band%20Okta%20requires%20federation%20with%20Azure%5D%2C%20are%20you%20using%20ADFS%20for%20federation%20with%20AD%3F%20IF%20so%20the%20issue%20may%20be%20with%20the%20Office%20365%20Relying%20Party%20Trust%20claim%20rule.%20I%20know%20that%20when%20I%20was%20working%20with%20a%20customer%20in%20helping%20them%20with%20their%20Okta%20issues%2C%20ADFS%20and%20Office%20365%20I%20needed%20to%20rewrite%20that%20to%20get%20it%20to%20work%20the%20way%20I%20wanted.%20I%20don't%20remember%20the%20details%2C%20but%20it%20had%20something%20to%20so%20with%20the%20samaccountname%20matching%20the%20beginning%20of%20the%20UPN.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1547552%22%20slang%3D%22en-US%22%3EAzure%20AD%20Sign%20in%20issue%3A%20%E2%80%9CThe%20account%20might%20not%20exist%20or%20it%20might%20not%20be%20synchronized%22%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1547552%22%20slang%3D%22en-US%22%3E%3CP%3E%3CU%3E%3CSTRONG%3EScenario%3A%3C%2FSTRONG%3E%3C%2FU%3E%3C%2FP%3E%3CP%3EWe%20have%20Azure%20AD%20tenant%20set%20up%20with%20user%20provisioning%20and%20federated%20authentication%20done%20via%20Okta.%20So%2C%20Okta%20was%20synchronizing%20users%20to%20Azure%20AD.%26nbsp%3B%3C%2FP%3E%3CP%3ENow%2C%20we%20installed%20Azure%20AD%20Connect%20and%20switched%20off%20Okta%20based%20user%20provisioning%20(Still%20keeping%20Okta%20for%20federated%20authentication).%20We%20have%20successfully%20matched%20existing%20users%20in%20Azure%20AD%20to%20their%20AD%20objects%20using%20hard%20matching%20based%20on%20ObjectGuid.%20The%20Azure%20AD%20connect%20based%20sync%20was%20run%20on%20all%20users%20and%20it%20worked%20for%20all%20except%202%20users.%20These%20users%20had%20a%20mismatch%20between%20Azure%20AD%20immutableId%20and%20ObjectGuid%20in%20AD.%20Then%20we%20got%20sync%20errors%20for%20these%202%26nbsp%3B%20users%20and%20Azure%20AD%20created%20duplicate%20account%20for%20them%20with%20email%20format%20as%20%3A%20%3CA%20target%3D%22_blank%22%20rel%3D%22noopener%22%3Eusername-%3CSOMENUMBER%3E%40%3CTENANT%3E.onmicrosoft.com%3C%2FTENANT%3E%3C%2FSOMENUMBER%3E%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWe%20have%20corrected%20those%20user's%20immutableId%20by%20running%20PowerShell%20commands%20to%20change%20the%20immutableId.%20Once%2C%20the%20immmutableId%20of%20those%20users%20were%20corrected%20the%20sync%20was%20run%20again%20and%20Azure%20AD%20connect%20now%20properly%20matches%20the%20Azure%20AD%20user%20with%20their%20correct%20AD%20object%20(we%20tested%20by%20changing%20some%20irrelevant%20Ad%20attributes%20and%20they%20are%20properly%20propagated).%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EBut%2C%20when%20the%20user%20tries%20to%20login%20they%20are%20first%20redirected%20to%20Okta%20for%20login%20and%20after%20Okta%20login%2C%20the%20tokens%20are%20forwarded%20to%20Azure%20AD%20and%20user%20get%20below%20error%20from%20Azure%20AD%20login%20page%3A%3C%2FP%3E%3CP%3E%3CSTRONG%3E%E2%80%9CThe%20account%20might%20not%20exist%20or%20it%20might%20not%20be%20synchronized.%20Contact%20your%20administrator%20to%20add%20or%20synchronize%20the%20account%22%3C%2FSTRONG%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWe%20do%20not%20have%20any%20major%20services%20provisioned%20in%20M%20365%20yet%2C%20so%20can%20live%20with%20user's%20Azure%20AD%20account%20being%20recreated.%26nbsp%3B%3C%2FP%3E%3CP%3ESome%20additional%20things%20tested%20out%2C%20but%20all%20leads%20to%20same%20sign%20in%20behavior%3A%3C%2FP%3E%3COL%3E%3CLI%3EChange%20the%20immutable%20ID%20of%20the%20Azure%20AD%20account%20to%20match%20AD%20object%20and%20run%20sync%20%3D%26nbsp%3B%26nbsp%3BAll%20props%20are%20synced%20but%20login%20failure.%3C%2FLI%3E%3CLI%3EDelete%20the%20existing%20Azure%20AD%20account%20and%20run%20sync%20to%20create%20new%20account%20%3D%20New%20Azure%20AD%20account%20created%20but%20login%20fails%20as%20before.%3C%2FLI%3E%3CLI%3ECreate%20a%20cloud%20account%2C%20changed%20the%20immutable%20Id%20to%20match%20the%20AD%20objectGuid%2C%20changed%20the%20UPN%20to%20match%20the%20AD%20object%20email%2C%20run%20sync%20%3D%26nbsp%3B%20The%20cloud%20account%20gets%20synced%20to%20AD%20object%20and%20properties%20are%20updated%2C%20but%20login%20fails%3C%2FLI%3E%3C%2FOL%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThe%20issue%20is%20only%20for%20the%202%20user%20account%20which%20had%20this%20sync%20error%20in%20the%20beginning%2C%20for%20all%20other%20users%20login%20is%20working%20properly.%3C%2FP%3E%3CP%3EAny%20ideas%20or%20pointers%20to%20check.%20What%20are%20we%20missing%20here%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-1547552%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EIdentity%20Management%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1565577%22%20slang%3D%22en-US%22%3ERe%3A%20Azure%20AD%20Sign%20in%20issue%3A%20%E2%80%9CThe%20account%20might%20not%20exist%20or%20it%20might%20not%20be%20synchronized%22%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1565577%22%20slang%3D%22en-US%22%3EOkta%20authentication%20is%20working%20for%20the%202%20users%2C%20but%20post%20authentication%20hen%20the%20users%20are%20returned%20to%20Azure%20AD%20page%2C%20they%20get%20this%20error.%20Also%2C%20for%20all%20other%20users%20who%20did%20not%20have%20any%20Azure%20AD%20Connect%20sync%20error%20during%20setup%2C%20federated%20authentication%20via%20Okta%20is%20working%20properly.%3C%2FLINGO-BODY%3E
Contributor

Scenario:

We have Azure AD tenant set up with user provisioning and federated authentication done via Okta. So, Okta was synchronizing users to Azure AD. 

Now, we installed Azure AD Connect and switched off Okta based user provisioning (Still keeping Okta for federated authentication). We have successfully matched existing users in Azure AD to their AD objects using hard matching based on ObjectGuid. The Azure AD connect based sync was run on all users and it worked for all except 2 users. These users had a mismatch between Azure AD immutableId and ObjectGuid in AD. Then we got sync errors for these 2  users and Azure AD created duplicate account for them with email format as : username-<somenumber>@<tenant>.onmicrosoft.com 

 

We have corrected those user's immutableId by running PowerShell commands to change the immutableId. Once, the immmutableId of those users were corrected the sync was run again and Azure AD connect now properly matches the Azure AD user with their correct AD object (we tested by changing some irrelevant Ad attributes and they are properly propagated). 

 

But, when the user tries to login they are first redirected to Okta for login and after Okta login, the tokens are forwarded to Azure AD and user get below error from Azure AD login page:

“The account might not exist or it might not be synchronized. Contact your administrator to add or synchronize the account"

 

We do not have any major services provisioned in M 365 yet, so can live with user's Azure AD account being recreated. 

Some additional things tested out, but all leads to same sign in behavior:

  1. Change the immutable ID of the Azure AD account to match AD object and run sync =  All props are synced but login failure.
  2. Delete the existing Azure AD account and run sync to create new account = New Azure AD account created but login fails as before.
  3. Create a cloud account, changed the immutable Id to match the AD objectGuid, changed the UPN to match the AD object email, run sync =  The cloud account gets synced to AD object and properties are updated, but login fails

 

The issue is only for the 2 user account which had this sync error in the beginning, for all other users login is working properly.

Any ideas or pointers to check. What are we missing here?

2 Replies

@unnie ayilliath 

Because you were using Okta [and Okta requires federation with Azure], are you using ADFS for federation with AD? IF so the issue may be with the Office 365 Relying Party Trust claim rule. I know that when I was working with a customer in helping them with their Okta issues, ADFS and Office 365 I needed to rewrite that to get it to work the way I wanted. I don't remember the details, but it had something to so with the samaccountname matching the beginning of the UPN.

Okta authentication is working for the 2 users, but post authentication hen the users are returned to Azure AD page, they get this error. Also, for all other users who did not have any Azure AD Connect sync error during setup, federated authentication via Okta is working properly.