What happened?

On May 14, 2024, Okta became aware that some customers had a small subset of Windows users who were unable to use FastPass after installing Okta Verify for Windows version 5.0.1.0 or later. Only new FastPass installations on Windows are impacted; users with existing FastPass enrollments on that device are not impacted. No other platforms are impacted.

While we are working on creating a new stable release, we rolled back the published release to Okta Verify for Windows version 4.10.7 to avoid creating further impact for customers who are in the process of deploying.

What is the error?

To diagnose this issue, you must meet both of the following criteria:

1. Users cannot open Okta Verify

   1. The process launches and runs in the background, but no user interface is shown to the user

2. The following error is seen in the Windows Okta Verify logs:

ClientStorageManager.TryInitializeStore: Failed to read storage secret after 50000ms.

What is the impact?

1. Some users who were enrolling in MDM for the first time were unable to open Okta Verify after enrollment completed

2. Some users who shared a machine with one or more other users were unable to open Okta Verify

3. Some users were unable to open Okta Verify after un-installing and re-installing Okta Verify

What is the cause?

Based on the Okta Verify team’s initial assessment, there are 2 contributing issues.

1. Windows Okta Verify data is improperly being created in the location C:\Users\Default\AppData\Local\Okta\OktaVerify when the Okta Verify installer is run in the System context

2. Windows Okta Verify is failing to properly cleanup data on un-install

How does a database file in the Default user profile affect Okta Verify?

When new user profiles are created, Windows uses the Default user profile as the template for the new user profile. When an Okta Verify database file is copied from the Default user profile to the new user’s profile during profile creation, it prevents Okta Verify from properly initializing.

How does data left from a previous installation affect Okta Verify?

When Okta Verify fails to properly clean up it’s data on un-installation, it prevents Okta Verify from properly initializing when re-installed and re-started.

What are the workarounds?

There are two possible workarounds. They differ based on whether a specific user is being targeted or whether all of the users on a device are being targeted. The appropriate option depends on the configuration and needs of the situation.

Option 1: Target a specific affected user (recommended)

There are 2 components to this approach

1. Stop Okta Verify and remove the Okta Verify database for the affected user

2. Remove the Okta Verify database from the Default user profile

Part 1

The following PowerShell script stops Okta Verify for all users and removes the Okta Verify database file from the profile of the context in which the script is running.

To properly remove the database file for an affected user, this script must be run in the context of the affected user.

#Stop Okta Verify for ALL users 
Stop-Process -Name "OktaVerify" -Force -ErrorAction SilentlyContinue 

#Remove the database file from the current context 
remove-item "$env:localappdata\Okta\OktaVerify\datastore.db" -verbose -Force -ErrorAction SilentlyContinue

Part 2

The following PowerShell script removes the Okta Verify database from the Default user profile. To execute, it needs to run in the System or Admin context.

#Remove the database file from the Default user folder 
remove-item "C:\Users\Default\AppData\Local\Okta\OktaVerify\datastore.db" -verbose -Force -ErrorAction SilentlyContinue

Option 2: Target all users on a device

If there is only 1 user on the device or if there are multiple affected users, you can use this simplified script to stop Okta Verify and remove the database file from all user profiles.

Do not execute this script if there are any users with working FastPass enrollments on the device. Do not push this script to all devices. Doing so will cause previously unaffected users to lose their FastPass enrollments.

#Stop Okta Verify for ALL users 
Stop-Process -Name "OktaVerify" -Force -ErrorAction SilentlyContinue 

#Remove the database file for ALL users on the machine 
remove-item "C:\Users\*\AppData\Local\Okta\OktaVerify\datastore.db" -verbose -Force -ErrorAction SilentlyContinue

What can users expect after applying the workarounds?

Once Okta Verify has been stopped and the database files for the Default user and any affected users on the machine have been removed, users can open Okta Verify and enroll in FastPass, which will then function as expected.

When will a fix be available?

We recently deployed a Windows Okta Verify hotfix with version number 5.0.5.0. This hotfix did not address the issue where users are unable to open Okta Verify. The team is working non-stop to release a new version of Okta Verify that prevents this problem from occurring. We will provide updates to impacted customers on a regular basis.