In this article, we provide a starting point to begin troubleshooting Device Management (formerly known as Device Trust) for Desktops in Okta Identity Engine (OIE). 

While the deployment procedure varies step-by-step from one Mobile Device Management (MDM) solution to another, the primary elements are all the same. However, the importance of identifying and using the correct documentation for the specific MDM integration can not be overstated.


Understanding how Device Management Attestation is expected to work and the components that enable the functionality is crucial to identifying and resolving common issues that may arise in the implementation or management. For educational purposes, here is a high-level review of the elements involved in enabling Device Management Attestation across all MDMs:

• Configure / Integrate the Public Key Infrastructure (PKI) for Okta Device Management
  • Configure Okta for Endpoint Management
    • Enabling a Simple Certificate Enrollment Protocol (SCEP)  URL, Challenge Type, and Shared Secret.
    • Okta OIE Tenants with Adaptive MFA are configured with a Certificate Authority (CA). Once Endpoint Management (above) is configured, download the Okta CA root certificate. 
      • Administrators with existing PKI infrastructure have the option to 'Bring Your Own' Certificate Authority (CA).
• Configure the Mobile Device Management (MDM) solution
  • API permissions (when applicable) between Okta and MDM
  • Configure SCEP Profiles
    • Parameters around integrating a Chain-Certificate to the Okta CA onto endpoint systems so they can establish the chain of trust from their certs, to the issuing CA.
  • Deploying the SCEP profiles to the endpoints
    • This sends the intermediate and end-point certificates configured in the MDM profiles.

Okta expects these components and concepts to be familiar to Okta administrators responsible for the implementation of Device Management. 

• Okta Identity Engine (OIE)
• Desktop Okta Verify - FastPass
• Device Management Attestation
• Mobile Device Management (MDM)
• Simple Certificate Exchange Protocol (SCEP)
• Public Key Infrastructure (PKI) 
• Passwordless Authentication
• Authentication Policies
• Global Session Policies

Knowing where to start can be difficult, as it depends on multiple factors in a deployment with numerous moving parts. Here, we will try to cover the most common areas where Okta Administrators run into issues.

• If encountering issues with a new implementation, or if unsure where the errant behavior may be coming from, it is best to work from the top of the list, with the section immediately below named "Ensure each step of Configure a Certificate Authority", and iterate through the solutions list until resolution is identified.
• However, if the issue pertains to an existing deployment that is now encountering issues or isolated incidences, it is best to narrow the scope of the issue down to the particular component and start from there. See the outline below for further guidance.

Solution Table Of Contents

Ensure each step of "Configure a Certificate Authority" from the Okta Manual was followed accurately

Scenarios for use:

• New Implementations, including one that does not appear to be working.
• MDM Configuration profiles are not being deployed, or Certificates are not being issued to devices.

There are multiple options when integrating a Certificate Authority (CA) for use with Device Management:

• Tenants with Adaptive MFA on Okta Identity Engine (OIE) come with a CA.
  • This is the most common configuration. 
• It is also possible to integrate an existing CA instead of using the one built into Okta.

Comprehensive instructions for the entire Device Management Deployment (For Desktop Devices) can be found in Configure management attestation for desktop devices. 

The second step in the Configuration Workflow guide linked above is "Configure a Certificate Authority".

• NOTE: It is imperative that each step in the manual be thoroughly reviewed and verified for accuracy. To identify the correct reference documentation in the "Configure a Certificate Authority" section of the manual, locate the MDM in use and the operating system.

Once the proper guide has been identified and double-checked for accuracy in the configuration, if the issue persists or the above configuration was previously functional, we may move on to the next steps on where to review.

 

Investigate SCEP Profile Deployment Issues 

Scenarios for use:

• New implementation / Proof of Concept and validation testing: After confirming and following the appropriate documentation for "Configure a Certificate Authority", how to confirm the profiles were sent to the target desktop device. 
• The device is not showing as managed in Okta: Management profiles, and the resulting certificates are required for management attestation to occur.
• Troubleshooting issues getting configuration changes pushed to systems: Configuration seemingly deployed, but desktop device does not appear to have it. How to find issues with profiles being sent, or received on the machine, and finding any error messages related to profile deployment.

In certain situations, admins may encounter issues with configuration profile deployment which will require further inspection. This includes how to check inside the MDM for information on profile deployment, and where in the target desktop to look to confirm the profile deployment failed or was successful and a certificate was deployed.

More details are available in the How-To Verify SCEP Profile Deployment to Desktop Devices for Device Management article. 

 

Verify Certificate Installed Successfully On Desktop OS

Scenarios for use:

• New implementation / Proof of Concept and validation testing: After confirming and following the appropriate documentation for "Configure a Certificate Authority" and optionally confirming the profiles were sent to the target desktop device, how to validate and review the resulting management certificate was received on the device.
• The device is not showing as managed in Okta: Management certs are required for management attestation to happen.
• Confirm certificate details: Details such as issuer, common name, and expiry can be validated using this procedure.

Once the SCEP profiles are confirmed successfully deployed, we can expect an Intermediate Certificate for the CA and a Device Management Certificate to be installed on the target local machine. These will need to be present and installed correctly for Device Management Attestation to happen. Review this article to review how exactly to confirm the certificates exist in Windows or Mac Operating systems:

More details are available in the Verifying Device Management SCEP Certificate Installed Successfully On Desktop OS article. 

 

Verify FastPass Policy and Rules

Scenarios for use:

• New implementation / Proof of Concept and validation testing: The next step after confirming and following the appropriate documentation for "Configure a Certificate Authority", and optionally confirming the profiles and certificates exist on the target desktop device.
• Device is not showing as managed in Okta: Device Management configuration in the profiles are required for management attestation to happen, and for devices to be evaluated for management.- FastPass Login is Required for Device to Show as Managed
• FastPass deployment considerations: How to configure policies to roll out FastPass authentication to targeted users. 

Step 3 in the Device Management configuration workflow ("Add an authentication policy rule for desktop").

Device registration and Authentication Policies that check for a Managed device status are requirements for making a device show as managed.

More details are available in the How To Configure Authentication Policies For Device Management article. 

Shared Workstations

Scenarios for use:

• New implementation / Proof of Concept for Shared Workstation use-case.
• The device is not showing as managed in Okta.
  • The instructions covered in the manual chapter to Configure management attestation for desktop devices often only provide steps for deploying configuration profiles to users and not the Device or System cert store locations. When multiple user accounts share a single workstation, config profiles targeting User cert stores will result in only the first user logged in getting a device management certificate and showing managed, while all others that log in do not. 

There are special considerations when the intended use case is for a shared workstation.

• A Shared Workstation is defined as a Desktop Operating System in which separate individual users sign in to perform tasks. Each unique login accesses the computer with its own profile and registers its Okta account using the locally installed Okta Verify app on the Desktop.
• Kiosk-style workstations, where multiple individuals use a shared single account to access the workstation, are not supported.

If a Device is failing to show as managed, for multiple users on a device, Okta Admins may need to modify the deployment to issue a certificate to the Machine / Device Certificate store. 

More details available in the Deploying Device Management in OIE to Shared Workstations article. 


 

SSO Extensions for macOS

Scenarios for use:

• New implementation for macOS: Validating Device Management Proof of Concept
• End-users are prompted to open Okta Verify in the browser. Unlike Windows desktop devices, macOS devices are prompted to open Okta Verify and are not automatically logged in. 

The SSO extension forwards requests from the browser or app to Okta Verify, so end-users do not receive the "Open Okta Verify" browser prompt.
 
The SSO Extension is required to provide a seamless login experience with Okta Verify FastPass for Managed Devices in Safari and in-app browsers, it also gives the authentication phishing resistant properties in the authentication flow.

More details available in the Troubleshooting Okta SSO Extension for macOS article.