Troubleshoot the migration of Device Trust to Okta FastPass
Consider the following troubleshooting and verification procedures when you migrate from Device Trust (Classic Engine) to Okta FastPass:
In Identity Engine, you need authentication policies for devices that aren't trusted. If you didn't configure these correctly, you receive an error when you try to deactivate Device Trust (Classic Engine. The error message varies, depending on affected authentication policies.
For example, your Device Trust (Classic Engine) app sign-on policy might have to following configuration:
- CLIENT: Windows and/or macOS
- DEVICE TRUST: Not trusted
- ACCESS: Denied
This policy migrated to Identity Engine as:
- AND Device state is: Registered
- AND Device management is: Not managed
- THEN Access is: Denied
The following images illustrate these two configurations:
Classic Engine app sign-on policy
Identity Engine authentication policy
Before you delete the legacy Device Trust configuration, revise the Identity Engine authentication policy to deny access to devices that aren’t enrolled in Okta FastPass.
- Create one or more Allow rules to define when to allow access to the app. Assign these rules the highest priority.
- Create a Denied catch-all rule that applies to users who don't match the permissive rules you created in step 1. Assign the Denied catch-all rule the lowest priority, just above the Okta default rule.
Your first rule should allow registered, managed devices:
- AND Device state is: Registered
- AND Device management is: Managed
- THEN Access is: Allow
A later rule should deny all other devices.
|Rule||Rule name||User group||IF||THEN|
|1||Group A managed||A||Require registered, managed devices||Allow with 1FA|
|2||Group A other||A||Any device state||Allow with 2FA|
|3||Group B managed||B||Require registered, managed devices||Allow with 1FA|
Verify that Integrated Windows Authentication (IWA) works as expected
On the client device, go to the following URLs (replace [IWA_DOMAIN_NAME] with your IWA domain name), and verify that it works as expected:
Verify that it appears correctly in the browser.
Verify that Userid, UserPrincipalname, UserprincipalName(Transformed), and Security Identifier appear.
Verify that you go to the Okta sign-in page.
Verify that a Device Trust client is deployed to the client device
- In Windows, click Start > Add or remove programs.
- Search for Okta Device Registration Task.
Verify that a Device Trust mutual TLS client certificate is installed
In the Microsoft Management Console (MMC), open the Certificate Manager (click Start > certmgr.msc).
Verify that an Okta MTLS - [userName] certificate is present.
If the certificate wasn’t present, open Task Scheduler (click Start > Task Scheduler) and run okta-devicetrust-usertask.
Verify that Device Trust Enrollment works as expected
- In the Microsoft Management Console (MMC), open the Certificate Manager (click Start > certmgr.msc).
- Delete the Okta MTLS - [username] certificate.
- Open a Command Prompt.
- Change directories to “Program Files\Okta\DeviceTrust”.
- Run OktaDeviceReg.exe --user --verbose --force.
- Verify that errors don’t exist, and that a new certificate is enrolled on the client device.
A new command window appears.
Verify that a rule requires registered and managed devices
- In the Admin Console, go to Security > Authentication Policies.
- Select the policy that you want to update.
- Click the Rules tab.
- View the policy information, and then verify that one of the rules in the policy specifies:
- Device: Registered, Managed
- User must authenticate with: Any 1 factor type
Review the Admin System logs
Go to Enforce Okta Device Trust for managed Windows computers, and see the Troubleshooting > Basic Troubleshooting > SystemLog section.
If you’re using a Trusted Platform Module (TPM), see Enhance Windows Device Trust security with Trusted Platform Module (TPM).
Verify that a Device Trust client is deployed to the client device. See "To verify installation from a terminal" at Enforce Okta Device Trust for Jamf Pro-managed macOS device.