This article addresses an issue where users are still required to enter their password when logging into a Windows machine, even after an administrator has enabled the passwordless feature for Okta Device Access via the required registry key.

• Okta Identity Engine (OIE)
• Okta Device Access (ODA)
• Desktop MFA
• Windows Devices

This problem occurs when security policy settings, configured via a Windows Group Policy Object (GPO) or a Mobile Device Management (MDM) policy, deviate from best practice recommendations.

Pre-requisites 

• Passwordless is enabled via this registry key -  HKLM\Software\Policies\Okta\Okta Device Access\PasswordlessAccessEnabled is set to 1 on the affected device.
• The device is online.
• The user has authenticated with password + Okta Verify Push during initial login.

Administrators should verify the device's configuration and adjust the relevant security policies.

The most common cause is a conflicting security policy. Ensure the local Users group has the necessary network logon rights on the local machine.

NOTE: If these settings are managed by a GPO/MDM, the changes will need to be made in the MDM or the Active Directory Group Policy Object, as local changes will be overwritten.

1. Open the Local Security Policy Editor: On the affected machine, run secpol.msc or gpedit.msc.
2. Navigate to User Rights Assignment: Go to Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment.
3. Open the Access this computer from the network policy.
   1. Ensure that the Users group is included in this list. If it is missing, the passwordless flow will fail.
4. Open the Deny access to this computer from the network policy.
   1. Confirm that the user, their group, or a broad group like Everyone is NOT on this list. A deny rule will always take precedence over an allow rule.

Verify security logs on the affected device.

1. Open Event Viewer.

2. Navigate to Windows Logs > Security.

3. Filter the log for failures.

4. After a failed passwordless login attempt, look for an Audit Failure event. The event details will often show a Logon Type: 3 (Network), indicating that the network logon required for passwordless access was blocked.

For more information on these Windows security policies, refer to the official Microsoft documentation on User Rights Assignment.