This article explains why users may continue to use their old passwords to log in to Azure Active Directory (AD)-joined devices after updating their passwords in Okta, and may get locked out of Okta seemingly at random.

Symptoms of this issue include:

• Users are being frequently locked out of Okta at times when they are not attempting to access a resource protected by Okta.
• Finding Okta logs for the user containing repeated "Authentication of a user via Rich Client" failure events, and/or "Authentication of user via MFA" events that failed due to invalid credentials (and inspecting either of these failure events will show a "Raw User Agent" value similar to "Windows-AzureAD-Authentication-Provider/1.0").
• On the affected machine, opening a command prompt and using the command "dsregcmd /status" to find the "AzureAdPrtUpdateTime" shows a date further in the past than expected.

• Azure Active Directory (AD)
• Single Sign On (SSO)

Azure AD-joined devices keep a Primary Refresh Token (PRT) that is periodically refreshed using the cached credentials of users who log in to the device. While the device determines that the PRT is not yet due for a refresh, Microsoft's PRT mechanism does not attempt to route authentication requests to Okta. As a safety mechanism, Windows will keep a hash of the last valid credentials that will be allowed for logging into the desktop, in case the device loses connectivity to the internet. The local hash does not have a specific lifetime or expiration, and may even be usable for months after the password is changed in Okta, until the new password is utilized to obtain a new PRT on the device.

To ensure that users can log in to Azure AD-joined devices using their updated Okta credentials and reliably receive/refresh PRTs:

1. After changing their Okta password, users should immediately lock their Windows desktop (from the Ctrl+Alt+Del menu, or by pressing Win+L) and then use their new Okta password to unlock the device. Windows will detect that the newly provided password does not match the stored hash and will attempt to validate this password against the federation with Okta. If this password is accepted by Okta, then Windows will delete the hash of the previous credentials, and so only the updated credentials will be valid to access the desktop going forward.
2. Once on the desktop, open a Command Prompt (Windows key + R > type “cmd” > Enter), and use the command "dsregcmd /status" to find the "AzureAdPrtUpdateTime" value. If this was not within the expected date range, then have the user change their Okta password and try the lock/unlock process again, while advising that they should always use their most current Okta password to access the computer's desktop.

Related References

• Microsoft Documentation: What is a Primary Refresh Token?
• Okta Documentation: Enabling Okta Credentials for Windows 10 Login with Azure AD Join