Jul 27 2020 04:28 AM - edited Aug 04 2020 10:07 AM
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:
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?
Aug 03 2020 11:01 AM
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.
Aug 04 2020 10:10 AM