Okta Device Enrollment Verification

Introduction

Previously, when we wanted to ensure that a device was enrolled and compliant with Workspace ONE, we had to do a device trust integration. Whether this involved IdP factor as a mandatory factor, or simply using certificate based authentication with Workspace ONE as an IdP to Okta, this required pretty significant setup. With a new feature from Okta - the managed device data point as part of authentication policies - we can use a certificate (and Okta Verify) to ensure that a device is enrolled. 

Note: this does not ensure that a device is compliant with Workspace ONE compliance policies. You will need to leverage the integration between Workspace ONE Access and Okta for this capability. Also note that this requires the use of Okta FastPass/Okta Verify.

That said, the way this works, is that Okta checks for the existence of a certificate on the device, whether this be using a SCEP certificate provided by Okta, or using the Workspace ONE built-in AirWatch CA. Both methods are detailed below. The high level process involves ensuring the certificate, and intermediate/root certificate is on the device, and then setting Okta authentication policies to leverage this functionality. 

In this post, we are going to focus on Windows. 

Okta Endpoint Enrollment Verification with Okta CA

2. Select Desktop (Windows and MacOS), and click Next. Then select "Use Okta as my certificate authority", and set the SCEP URL challenge type to be Static. Then click generate. 

3. Okta will now present you with a SCEP URL and a secret key. Copy these to a clipboard. While we are in the Okta console, Click Save and then go to the Certificate Authority Tab. Download the intermediate certificate from here. We'll need it later. 

Note: this downloaded with no file extension when I was going through this. I gave the certificate a .cer extension for it to be recognized properly. 

4. Let's jump now into Workspace ONE UEM admin console. Sidenote: the instructions below on adding the SCEP certificate to Workspace ONE UEM are based on these directions from Okta, but are included below with screenshots from my lab environment. In Workspace ONE UEM, go to Groups and Settings - All Settings - System - Enterprise Integration - Certificate Authorities. Click Add.

5. Fill out the Certificate Authority with information below. Click "test connection" then click "Save and Add Template" 

Name: You can choose this (Ex. Okta Device Enrollment SCEP)

Authority Type: Generic SCEP

SCEP Provider: Basic

SCEP URL: (This was provided from okta a few steps ago)

Challenge Type: Static

Static Challenge (and confirm static challenge): (Secret key copied from Okta)

6. On the certificate template screen, fill in the below and click Save.

Name: You can choose this (Ex. Okta Device Enrollment SCEP Template) 

Certificate Authority: The CA you created earlier (ex. Okta Device Enrollment SCEP) 

Subject Name: CN={EmailAddress} managementAttestation {DeviceUid}

Private Key Type: Signing

San Type: (leave this default/do not specify) 

Automatic Certificate Renewal: Enabled

Auto Renewal Period: 5 days 

Next, we need to create profiles to push the intermediate certificate, and SCEP certificate, to the device. 

7. In the UEM console, go to Resources - Profiles - Add. First we are going to add a Windows Device Profile to deliver the intermediate certificate from Okta. Fill out the general information on the profile (name, assignment group) and then select the Credentials payload. Upload the intermediate certificate file from earlier. Select for the certificate store to be "Intermediate". Then Save and publish profile. 

Next, we are going to create the profile that issues the certificates to the device based on the SCEP CA we created earlier (that points to Okta).

8. In the UEM console, go to Resources - Profiles - Add. Create a Windows user profile. FIll out the general information (profile name and assignment group). Then add the SCEP payload. Select "Defined Certificate Authority" as the credential source, select the Okta CA we created earlier, and set the key location to be "TPM if present". Then click save and publish.

That's it! The device now has the certificate from Okta to prove that it is being managed by Workspace ONE. You still will need to configure your Okta policy to require checking this for certain applications, which I will detail later on in this blog post.

Okta Endpoint Enrollment Verification with AirWatch CA

If you are already using the AirWatch CA for certificate based authentication into Workspace ONE Access, and are pushing certificates from the AirWatch CA to your devices, then it may be easier to leverage the AirWatch CA instead of Okta's CA. This will assume that you aleady are pushing AirWatch certificates to your devices. If you need documentation on how to set this up, see the Okta Integrations page, Desktop SSO (or mobile SSO) sections for information on pushing out certificates leveraging the AirWatch CA.

If you followed the above section on pushing out certificates from the Okta CA, you can skip this section and go to the next section on configuring Okta.

2. Next, in the Okta admin console, go to Security - Device Integrations - Certificate Authority. Click Add Certificate Authority. 

3. Upload the VidmAirWatchRootCertificate document. Note: I had to change the upload to allow all file types to allow me to upload the certificate.

4. Back on the Endpoint management tab, click Add Platform. Select desktop devices, and then select to "use my own CA". Click Save.

Configure Okta to Check for Device Enrollment

At this point, we have a certificate on the device to prove that it is enrolled, and Okta is aware of the certificate authority in which those certificates are being issued from (whether it be Okta's own CA or using the AirWatch CA). Now we just need to change the authentication policy to require that the device enrollment is checked prior to accessing a certain SaaS application. 

2. Click Add Rule, name it, and select the options such that the device is both registered with Okta Verify (which is a requirement to check device management) and that the device is managed. Then, select the desired authentication (allowed with 1 factor, 2 factor, etc.) and click save. My examples are below. 

3. Be sure to edit the catch-all rule so that any devices that do not fall in the rule we created (where they are enrolled) are subject to a different authentication policy, or are denied altogether. 

4. Finally, once you click save, go to the Applications tab for the policy, and add any particular applications in Okta you want to make sure are authenticated using this policy. 

That's it! You should now be able to test out whether only enrolled devices are allowed to access the application you have specified behind the new authentication policy.