Overview

This guide provides a structured approach to diagnosing and resolving issues related to Okta Desktop Multi-Factor Authentication (MFA). Follow these steps sequentially to effectively narrow down the root cause.

Solution

Step 1: Initial Triage & Scoping Questions

First, gather essential information to understand the scope and context of the problem.

• New or Existing Setup? Is this a new implementation of Desktop MFA, or is it an existing setup that has stopped working?
• Scope of Impact? Are all users impacted, or is the issue isolated to a single user or a specific group?
• Browser Login Test: Can the affected user(s) successfully log in to their Okta dashboard through a web browser using Okta Verify Push/TOTP? This helps confirm if the issue is specific to the desktop client.
• Federated App Test: For Entra-joined devices: After logging into the Okta dashboard, can users access Microsoft 365 or other federated applications? This helps rule out broader federation or licensing issues with Microsoft.

Step 2: Implementation & Configuration Checks

If the initial triage points towards a setup problem, verify the core configuration.

• Okta Verify (OV) Installation:

  • Confirm that the correct ClientID, Client Secret, and Org URL were used during the installation.

  • If Okta Verify was already installed on devices before Desktop MFA was set up, ensure the new version used for Desktop MFA is equal to or greater than the existing version.

• Registry Settings:

  • Check if the administrator is using default settings or has configured custom policies.

  • If custom settings are used, ensure all registry keys under HKLM\Software\Policies\Okta\Okta Device Access are configured correctly as per the documentation: Configure and deploy Desktop MFA policies for Windows.

Step 3: Common Problems & Solutions

If the configuration appears correct, consult this list of common issues for specific resolution steps.

1. Users Can Bypass the Okta Credential Provider

   • If users can select the default Windows password provider or Windows Hello for Business instead of being forced to use Okta, refer to the guide on excluding other credential providers.

   • Article: Exclude credential provider from Desktop MFA

2. Users Are Not Prompted for MFA (or Only See Offline MFA)

   • This can be caused by an incorrect Application Username format or other policy settings.

   • Article: Windows Desktop MFA troubleshooting: users not getting prompted for MFA

3. Security Key (USB) Option is Missing from MFA Choices

   • If the option to use a FIDO2 security key is not visible on the login screen, certain configurations may be missing.

   • Article: Security Key (USB) doesn't show on Desktop MFA login screen

4. "Login Failed" Errors When Direct Authentication is Enabled

   • When using the useDirectAuth setting, users may face errors with FIDO2 keys or Okta Verify Push/OTP.

   • Article: Windows Desktop MFA users unable to login when useDirectAuth is enabled

5. Self-Service Password Reset (SSPR) is Failing

   • If the "Forgot Password" option is missing:

     • Verify that the SelfServicePasswordResetEnabled registry key is set to 1, as mentioned in Configure access policies.

     • Ensure the "Application Username" format for the Desktop MFA app in Okta matches the user's Active Directory (AD) samAccountName or Azure AD User Principal Name (UPN).

• • If unable to reset password using “Forgot Password” option from Desktop Login screen:

    • First, test if the user can reset their password from the Okta User Dashboard. If this also fails, the issue is not specific to Desktop MFA.

      1. If users are imported from AD, make sure the AD sync agent is running and can communicate with AD. Refer to the links below for more details on Password Reset settings.

         1. Active Directory Password reset workflow
         2. Configure the password authenticator

      2. Verify Password Requirements from both Okta and AD.

         1. Note: Set the password minimum length and complexity requirements to match the AD password requirements. These requirements are displayed to the user when they reset their password through Okta and help ensure their password complies with the AD policy.

    • If users are able to reset passwords using the Okta User Dashboard or from the Okta Login screen, then collect logs to troubleshoot the password reset issue.

      1. Article - Error "There was an error while performing this action. Please contact your organizations administrator" after Selecting "Forgot Password" on Desktop MFA for Self-Service Password Reset on Windows.

      2. Verify if Okta username matches the Active Directory UPN.
         Windows Desktop MFA Users Unable to Login with FIDO2 Security Keys or Okta Verify Push or TOTP when UseDirectAuth is Enabled.

6. Unable to log in to the device with offline factors or getting only online factor method during device login, though users are allowed to log in with offline factors.

• • Please find registry keys configured under the path HKLM\Software\Policies\Okta\Okta Device Access.
  • End users must configure an offline verification method and an online verification method before the configured limit of MaxLoginsWithoutEnrolledFactors is reached.
  • Admin should also consider the MaxLoginsWithOfflineFactor limit. If the counter for offline logins exceeds MaxLoginsWithOfflineFactor, users will not be allowed to log in using the offline factor and will be locked out of the device if no online factors are enrolled. In that case, users must enroll in the online factors method.
  • Find counter values at the path “HKLM\Software\Okta\Okta Device Access\User Policies\<SID>”.
  • Note: Whenever a user logs in using an online factor method, the counter for MaxLoginsWithOfflineFactor is reset to 0.

7. Users or user groups are added in the MFABypasslist, but still get prompted for MFA

• • Currently, this would work only for a domain-joined machine (Hybrid joined).
  • For a single user, add the UPN for the user; for groups, only adding the group name should be sufficient.
  • The machine will communicate with the Domain Controller (DC) to obtain a list of the user's groups.
  • If a user is newly added to the group mentioned in the MFABypass list, the user must wait 10 minutes for the update to be reflected on the device.
  • More than one user group or user can be added to a registry, separated by a space. 
  • See the logs below for an example of the information obtained by the DC.

2024-11-05 11:29:59.013 -06:00 [INF] [ 🟦 ] [UserLogonSession::StartLogonAsync]
| OS: Windows 10 Enterprise  (Build 17763.1935)
| System: manufacturer=Dell Inc. product=OptiPlex 3070 ()
| Software:
|    C:\Program Files\Okta\Okta Device Access\Okta.DeviceAccess.Core.dll version: 0.10.1.13
|    C:\windows\system32\OktaDeviceAccessCredProvider.dll version: 0.10.1.13
|    C:\Program Files\Okta\Okta Verify\OktaVerify.exe version: 5.3.3.0
2024-11-05 11:29:59.013 -06:00 [INF] [OktaDeviceAccessUserPolicies.IsMfaRequired] IsMfaRequired(): islocal=False localmfareq=False
2024-11-05 11:29:59.013 -06:00 [INF] [OktaDeviceAccessUserPolicies.IsMfaRequired] IsMfaRequired=True
2024-11-05 11:29:59.013 -06:00 [INF] [OktaDeviceAccessUserPolicies.IsUserInList] IsUserInList - isLocalUser: False machineName: MFA-D-BD003283 userSAM: OdaTest.atkoepd.com\MarkJ
2024-11-05 11:29:59.013 -06:00 [INF] [OktaDeviceAccessUserPolicies.IsUserInList] User=
  UserIdentity:
    Sid: S-1-5-21-299502267-838170752-682003330-14783
    Sam: ODATest\MarkJ
    Upn: MarkJ@OdaTest.atkoepd.com
    OktaUsername:
  List 'MfaBypassList': Domain Admins;General Admins
2024-11-05 11:29:59.013 -06:00 [INF] [ 🟦 ] [OfflineFactorManager::GetActiveOfflineFactors] No offline factors found
2024-11-05 11:29:59.044 -06:00 [INF] [OnlineFactorManager.GetAllOnlineFactorsAsync] userName=MarkJ  scopes=openid;profile
2024-11-05 11:29:59.044 -06:00 [INF] [OnlineFactorManager.GetAllOnlineFactorsAsync] userName=MarkJ Scopes=openid
2024-11-05 11:29:59.169 -06:00 [INF] [ActiveDirectoryUtils.GetRecursiveGroupsForUser] User MarkJ belongs to groups: Administrators; Users; Domain Users; WINS Users; Ex Admins; General Admin; Printer Admin; All Internet Access; Accounting Users

The group name should match with AD user group list and the groups mentioned in MFABypassList

Step 4: Critical Service Check

A single service is responsible for the Okta Device Access functionality.

• On the affected machine, check if the OktaIdentityService is running in services.msc.

• This is especially important to check after an auto-update of Okta Verify. If the service is stopped, Desktop MFA will fail. An error on the "Okta Device Access" tab within the Okta Verify application is a strong indicator of a service-related issue.

Related References

• Get started with Desktop MFA for Windows
• Frequently Asked Questions About Desktop MFA
• Okta Device Access Product Hub
• Troubleshooting for macOS Desktop MFA
• Working with Okta Device Access Logs
• Support your Windows Desktop MFA users