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?
It is possible that this attribute had never been mapped and I am just now noticing the warning. The passwords not syncing between Okta/Azure AD is still an issue though.
I am also getting this if I look at the log for the user. More users may be affected than I previously thought just haven't been contacted by them yet. On the user in paticularo this is shown in the system log of the directory ingegration to ad:
I followed this article to enable logging https://support.okta.com/help/s/article/How-to-Retrieve-Okta-Logs-for-Troubleshooting?language=en_US
I am blurring out some of what I found that may contain identifying information. Not sure if it does or not but someone from Okta can ask for the full log if needed.
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!
Mihai - Our Okta was setup by a 3rd party with little to no documentation as to how to troubleshoot when issues arise. Are you able to look at the current case we have open? Case 01402911 to see if you see anything there that can help me?
Sorry, Jason. The Okta Community Questions forum isn't really meant for in-depth troubleshooting.
If you already have a Support ticket open, then I recommend continuing the discussion with the assigned Technical Support Engineers. They'll be able to access additional tools and resources to help you get to the bottom of it.
Thank you. I don't know how to check the things you are asking so I will put your response in the ticket in hopes that it will help the technician assisting us.
We do use an Office 365 Application in Okta that assigns an office license to a user for us. I am thinking that this creates the user in our Azure AD environment. We also have an on premises AD that syncs to our Okta as well and we run the Okta Agents on two different servers.