This article explores the mechanisms available to help troubleshoot issues with Self-Service Password Reset (SSPR) with Okta Device Access in a Windows Domain-joined environment.
There are multiple components involved in a SSPR flow with Okta Device Access and understanding the components, flow and where the components log messages is useful for troubleshooting issues.
Note that there is some product documentation on supporting Okta Device Access for Windows (but focused on desktop MFA) at https://help.okta.com/oie/en-us/content/topics/oda/windows-mfa/win-mfa-end-user-support.htm.
Overview of SSPR with Okta Device Access
The following diagram shows the flow from the Workstation login process through Active Directory for self-service password reset.
Okta Device Access uses Okta Verify on the workstation (endpoint) for device registration and user authentication. Whilst we may talk about Desktop MFA and Device Access, they are implemented through the Okta Verify for Windows (.exe).
The flow is:
- Okta Verify on the workstation is integrated with the Windows login process, so when a user click the forgot password link Verify is invoked
- Verify verifies the identity of the user, such as using a Push Notification on the users’ mobile device
- Once verified the new/confirm password dialog is presented and the user enters the new password
- Verify pushes the new password to Okta which uses the AD Agent to update AD with the new password.
As there are multiple components, any issues could be at different points in the flow. How to determine where the issue is? There are logs associated with the different components.
Logging Available
As per the diagram above, there are multiple logs on the workstation (endpoint), Okta itself, the AD Agent and Active Directory.
Windows Logs on the Workstation
Okta Device Access logs to the local system logging. For example, the following shows the Event Viewer on a Windows Server2019 acting as a client.
The example shows a SelfServicePasswordResetStarted event, but you will also see SelfServicePasswordResetSucceeded and other Verify events.
The events provide some info, but may not provide much from a debugging perspective. However the events are often bookends for Verify – if you see a Started event like above but not the corresponding Succeeded event it indicates that the process hasn’t completed.
Okta Verify and Device Access Logs on Workstation
Okta Verify may produce it’s own Verify Log and a Device Access Log. The latter will be very useful for debugging.
The OktaDeviceAccessLog<date>.log file contains detailed information on the device access activity within Verify. It can be found in c:\Windows\System32\config\systemprofile\AppData\Local\Okta Device Access\Logs
Even if the logs don’t indicate a problem in the local Okta Verify, they should reflect any errors from downstream processing. These logs are often a good starting point for identifying errors.
Okta System Logs
Events related to Verify and the SSPR flow are written to the Okta System Log. It can give you a good idea of the flow and the components involved. For example a user using SSPR.
The above shows the Verify-driven MFA and the steps Okta took to update/validate the new password via the AD agent.
If there were problems you might see an error event like this:
In this case it indicates there were problems with the AD agent resetting the user password in AD.
The system log can be a very rich source of debugging information.
Okta AD Agent Logs on the DC (or Agent server)
The AD Agent logs may also provide information on any problems applying a new password to AD.
The agent logs can be found at: c:\Program Files (x86)\Okta\Okta AD Agent\logs
If the Okta System Log entries indicate problems downstream (i.e. AD Agent or AD) this log should be checked.
Windows Server Logs on the DC
Finally the Windows Server system logs, accessed via the Event Viewer, can show any issues with the Windows components like Active Directory. If users are able to log in and authenticate, it’s unlikely that there’s a problem with the AD components, but if all else fails it may pay to check.
An Example of Failed Password Reset
The driver for this article was a situation I came across when first testing SSPR for one of my users on a Windows Server2019 instance in a Windows Server 2016 AD domain. The scenario I encountered was:
- At the login prompt I entered my domain username and clicked the Forgot password? link
- I was able to verify the user using Okta Verify with Push on my phone
- I was able to enter/confirm a new password
- But after that the login just hung before timing out and dropping me back to my RDP client
As it had gone through the MFA step and prompted me to enter a new password, I knew the issue was somewhere between Verify on the desktop, Okta, the AD Agent and AD.
The first place to check was the Device Access logs on the workstation. I found the following error:
This seemed to indicate an error further down the line. I rechecked all the password policies in Okta for the user and the AD user, but that wasn’t the issue.
Next I checked the Okta System Log and found the following error:
This confirmed that the issue was further downstream in (or after) the AD Agent (system.agent.ad).
I then checked the AD Agent logs on the domain controller (where I have my AD Agent installed) and it had a number of errors related to “Invalid token provided”. When I checked the Agent status in the Okta dashboard, it showed it in a “Disruption” status.
Given issues with the agent, I installed a new agent and deleted the old. Once I did this the SSPR flowed as expected. You could suggest that checking the AD agent first would have been a more prudent approach, but it was a useful exercise to explore the logs.
Conclusion
There are multiple components involved in a self-service password reset (SSPR) flow with Okta Device Access on a Windows endpoint. Understanding the flow and components is important to being able to troubleshoot issues.
In this article I have described the components and flow, as well as the key log files that can be used:
- On the endpoint the Okta Device Access logs can be very useful
- The Okta System Logs can show the entier flow and where there are errors
- The Okta AD Agent log on the server hosting the AD Agent may also highlight agent problems causing issues with the SSPR flow
The above information can give you the tools you need to troubleshoot issues with the Okta Device Access SSPR flow on Windows. For more information on setting up SSPR with Okta Device Access see https://iamse.blog/2023/12/21/okta-device-access-self-service-password-reset/.
IAMSE