JasonW.35132 (Customer) asked a question.
I have a user that their login to access their desktop on their computer is their Azure Active Directory email address/password. For some reason the password for this particular user is not matching their Okta password. It just appears to be one user being affected but this right now.
I have also noticed recently that if I navigate to Directory Integrations >> Active Directory >> Provisioning
Are the screenshots above what is causing my problems? If so, why is it only one user being affected? I have tried clicking on View Logs to see if this attribute objectGUID / externalId had somehow been changed but I have have not had any luck using the view logs to get any good information. Maybe I just don't know how to use that to search for what I am looking for. I would love to troubleshoot why these passwords are not matching for this user but not sure how to do that. Can anyone help me?
Hi @JasonW.35132 (Customer) , Thank you for reaching out to the Okta Community!
To take things in order. The Mapping warning is generic and has more of an informational purpose than anything. That mapping is typically not required, so you can ignore that in this case.
Now if that particular user leverages Azure AD instead of On-premise AD for authentication (so the Active Directory mappings and settings don't come into play here), then the source of the Password would be handled through the Azure ( Microsoft Office 365 ) implementation if you're pushing/managing the users that way. As such, you might want to look into that side of the implementation to see if password sync would come into play.
Seeing as there is just one user affected by this, I don't expect this to be a settings problem, so I don't recommend making any changes. It could be something environmental on the machine being used, like a failure to sync maybe via GPO, connectivity issue or something along that line.
That being said, if you're not using the Microsoft Office 365 (WS-Federation + Provisioning) implementation method of syncing information to the Azure tenant, it could be that password parity is not to be expected. To clarify, in the case of an On-Premise AD implementation, there's typically Delegated Authentication involved so the user's AD password is also used for the Okta login (not the other way around). In the case of Azure AD, the passwords might be independent of each other.
Hope it helps!