Configure Okta Device Trust for managed Windows computers Skip to main content
https://support.okta.com/help/oktaarticledetailpage?childcateg=&id=ka02a0000005ucqsaa&source=documentation&refurl=http%3a%2f%2fsupport.okta.com%2fhelp%2fdocumentation%2fknowledge_article%2fconfigure-okta-device-trust-for-managed-windows-computers-503185971
How satisfied are you with the Okta Help Center?
Thank you for your feedback!
How satisfied are you with the Okta Help Center?
1
2
3
4
5
Very Dissatisfied
Very satisfied
Enter content less than 200 characters.
Average Rating:
Configure Okta Device Trust for managed Windows computers
Published: Jan 31, 2018   -   Updated: May 15, 2018

okta-doc-source

This is an Early Access feature. To enable it, please contact Okta Support.

Configure Okta Device Trust for managed Windows computers


Okta Device Trust for Windows allows you to prevent unmanaged Windows computers from accessing corporate SAML and WS-Fed cloud apps. It works with any browser or native app that can access the certificate store when performing the federated authentication flow to Okta. This includes Edge, Internet Explorer, Chrome, and Microsoft Office clients that support Modern Authentication.


Diagram — device authentication and certificate flow

DT Flow_80per_3



Key benefits
  • Ensures that only end users on domain-joined Windows computers can seamlessly SSO into SAML and WS-Fed cloud apps
  • Protects enterprise data even when there is no defined network boundary
  • Provides a frictionless end user experience by utilizing the Okta Certificate Authority

System requirements
  • Active Directory domain-joined Windows computer(s) running Microsoft Windows 7, Windows 8.1, or Windows 10
  • .NET Framework version 4.5.2 or higher on domain-joined Windows computers. The Device Trust Registration Task checks whether a supported version is present, and if not, installs it automatically. For details, see Known Issues.
  • A Device Trust-capable version of the Okta IWA web agent. For installation details, see IWA documentation.
  • Supported browsers
    • Microsoft Internet Explorer versions 10 and 11
    • Microsoft Edge (current and previous release)
    • Google Chrome (current and previous release)

Caveats
  • Device Trust does not apply to apps accessed via chiclets within Okta Mobile.

  • Web view must have access to the device certificate store — Device Trust for managed Windows computers works with any SAML/WS-Fed-enabled app that supports authentication through a webview. The web view in which authentication is performed must have access to the certificate store on the device. This includes Microsoft Office clients that support Modern Authentication, among others (for more information, see this Microsoft article).
  • Device + end user authentication requires network connection — For the IWA web app to authenticate end users and devices, they must be logged-in to your company's network at the time the Device Trust Registration Task runs. For more details, see the IWA web app section below.
  • Support for proxy server environments — To ensure that this device trust solution works in environments that implement a proxy server, you must install Device Trust Registration Task version 1.2.1 or higher through a command line and append the proxy server address and port number to the installation command. For details, see Install the Registration Task.
  • To verify installation of the Registration Task, use an appropriate detection setting — After installing the Device Trust Registration Task on your managed Windows computers, SCCM runs a script to verify that installation was successful. Make sure to specify either File System or Registry in your Detection Rule. Do not use the Windows Installer setting type to detect the installation, as SCCM cannot detect the Device Trust Registration Task using that setting. Screenshot

    DT_SCCM_FileSystemDetect

  • Shared-terminal scenarios not supported — This Device Trust solution does not support shared-terminal scenarios in which multiple end users log in to the same domain-joined workstation.


Procedures

This article has four main procedures:

Part Ⓐ — Enroll the Device Trust certificate on domain-joined Windows computers

Perform the four sub-procedures in Part Ⓐ to ensure that the Device Trust certificate is installed successfully on domain-joined Windows computers.

A.1 — Install a Device Trust-supported version of the Okta IWA web app in your AD domain

Okta Device Trust for Windows uses the IWA web app to confirm the security posture of Windows computers and users by validating that both are joined to your Active Directory domain. Okta then issues a certificate to the Windows computer enabling device trust flows to Okta-federated apps. Private keys associated with the Okta certificate never leave the Windows computer. Certificates are renewed automatically once a year, approximately 30 days before they expire.

The role of the IWA web app is limited to the certificate enrollment and renewal process described above. Once the certificate is installed, the Device Trust Registration Task no longer needs to communicate with the IWA web app in order for end users to access apps. Desktop SSO does not need to be On in Security > Delegated Authentication for Okta Device Trust for Windows desktop to function.

  1. To download the Early Access version of the IWA web app, configure a link as follows:
  2. https://<org>.<okta/oktapreview>.com/static/agents/iwa/OktaSsoIwa-x.x.x.exe

    Where:

    • <org> is the name of your org
    • <okta/oktapreview> denotes either your Okta Production or Preview environment.
    • oktaSsoIwa-x.x.x.exe is the version of the IWA web app that supports Device Trust for Windows. For the current Device Trust-capable version, see SSO IWA Web App Version History.

    For example, a link for downloading version 1.11.0 to the org example.oktapreview.com would look like this:

    https://example.oktapreview.com/static/agents/iwa/OktaSsoIwa-1.11.0.exe
  3. Install the Okta IWA web app as detailed in Install and Configure the Okta IWA Web App for Desktop SSO.
  4. To make sure that IWA web agent is operational, test it as described in the guide.
  5. If you use HTTPS for IWA, you must modify the IWA web.config file as follows:
    1. On the server running the IWA web agent, access the file C:\inetpub\wwwroot\IWA\web.config
    2. Locate the section <system.serviceModel> and replace it with the following:
    3. <system.serviceModel>

      <bindings>

      <webHttpBinding>

      <binding name = "SecureBindingForDeviceTrust">

      <security mode="Transport">

      <transport clientCredentialType = "Windows" proxyCredentialType="Windows"/>

      </security>

      </binding>

      <binding name = "HttpBindingForDeviceTrust">

      <security mode="TransportCredentialOnly">

      <transport clientCredentialType = "Windows" proxyCredentialType="Windows"/>

      </security>

      </binding>

      </webHttpBinding>

      </bindings>

      <services>

      <service name="OktaSSO.DeviceTrust" behaviorConfiguration="OktaSSO.DeviceTrustBehavior">

      <endpoint binding="webHttpBinding" bindingConfiguration="SecureBindingForDeviceTrust" contract="OktaSSO.IDeviceTrust" behaviorConfiguration="webHttp"/>

      </service>

      </services>

      <behaviors>

      <endpointBehaviors>

      <behavior name="webHttp">

      <webHttp/>

      </behavior>

      </endpointBehaviors>

      <serviceBehaviors>

      <behavior name="OktaSSO.DeviceTrustBehavior">

      <!-- To avoid disclosing metadata information, set the value below to false before deployment -->

      <serviceMetadata httpGetEnabled="false"/>

      <!-- To receive exception details in faults for debugging purposes, set the value below to true.  Set to false before deployment to avoid disclosing exception information -->

      <serviceDebug includeExceptionDetailInFaults="false"/>

      <serviceCredentials>

      <windowsAuthentication allowAnonymousLogons="False" includeWindowsGroups="True"/>

      </serviceCredentials>

      </behavior>

      </serviceBehaviors>

      </behaviors>

      </system.serviceModel>

      Note: A detailed look at the values that configure HTTP or HTTPS binding are shown below:

      HTTPS binding configured:

      <services>

      <service name="OktaSSO.DeviceTrust" behaviorConfiguration="OktaSSO.DeviceTrustBehavior">

      <endpoint binding="webHttpBinding" bindingConfiguration="SecureBindingForDeviceTrust" contract="OktaSSO.IDeviceTrust" behaviorConfiguration="webHttp"/>

      </service>

      </services>
      HTTP binding configured:

      <services>

      <service name="OktaSSO.DeviceTrust" behaviorConfiguration="OktaSSO.DeviceTrustBehavior">

      <endpoint binding="webHttpBinding" bindingConfiguration="HttpBindingForDeviceTrust" contract="OktaSSO.IDeviceTrust" behaviorConfiguration="webHttp"/>

      <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />

      </service>

      </services>
    4. Save and close the web.config file.
    5. From your Windows command prompt, restart Internet Information Services (IIS) by issuing the following commands:

      iisreset /stop

      iisreset /start

    6. Before proceeding, retest the IWA web app as described in Install and Configure the IWA Web App for Desktop SSO.
    7. If you have not done so already, install the Device Trust Registration Task as described in A.2.

A.2 — Install the Device Trust Registration Task on domain-joined Windows computers

Click: Important to know before you begin

Schedule the Registration Task to run when end users are on the corporate network

Once installed on domain-joined computers, the Registration Task runs:

  • Immediately after it is installed
  • Whenever the user logs on to the computer
  • Once every 24 hours, starting with the time that the Registration Task first ran.

It is important that you configure your management tool to schedule the Registration Task to run when end users are on the corporate network. When the Registration Task runs, it triggers the certificate enrollment flow and creates a Scheduled Task that will run every 24 hours and whenever the user logs on to the computer. This retry behavior helps both certificate enrollment and renewal scenarios.

Certificate renewal can only occur when end users are on the corporate network

Certificates are valid for one year and are renewed automatically sometime within 30 days before expiration. In order for renewal to succeed, end users must be logged on to the domain-joined computer and connected to your corporate network.

Automatic certificate selection

By default, the Registration Task configures registry keys on domain-joined Windows computers to allow supported Chrome, Edge, and IE browsers to automatically select the device trust certificate that will be presented to Okta. If appropriate for your environment, you can disable this behavior by adding the flag SkipBrowserSetup=true to the installation command as detailed below. For example, this would be necessary if you want to configure automatic certificate selection using a Group Policy Object (GPO) tool.

If you opt not to configure automatic certificate selection — either through the Registration Task or a GPO — end users are prompted to select the certificate when accessing the app. In that case, to make the selection easier for end users, only the Okta Device Trust certificate will be shown to them.

Note: End users running the 32-bit version of Internet Explorer on their domain-joined computer may be prompted to pick the Device Trust certificate when accessing Device Trust-secured apps. This happens because the Device Trust Registration Task automatically configures the 64-bit version of Microsof Internet Explorer and Edge browsers.To prevent the certificate picker from displaying in this case, edit the Windows registry as detailed in Basic Troublshooting.

Proxy server environment

If your organization routes internet traffic through a proxy server, you must install Device Trust Registration Task version 1.2.1 or higher through a command line and append the proxy server address and port number to the installation command. For example:

HttpProxy=<your proxy http url>:<port number>

For details, see Install the Registration Task.

Certificate revocation

You may need to revoke an end user's Device Trust certificate(s) from the Okta Certificate Authority. This is recommended if the computer is lost or stolen. To re-secure an end user's computer with Device Trust after revoking their certificate(s), you need to remove the Device Trust certificate from their computer before you enroll a new certificate. Certificate revocation does not remove existing certificates from managed Windows computers. For details, see Revoke and remove Device Trust certificates.

Use an appropriate Setting Type in SCCM to verify Device Trust Registration Task installation

After installing the Device Trust client on your managed Windows computers, SCCM runs a script to verify that installation was successful. Make sure to specify either File System or Registry in your Detection Rule. Do not use the Windows Installer setting type to detect the installation, as SCCM cannot detect the Device Trust client using that setting. Screenshot

DT_SCCM_FileSystemDetect



Download the Registration Task

The Registration Task is available in .msi and .exe formats.

To download the Early Access version of the Device Trust Registration Task, configure a link as follows:

https://<org>.<okta/oktapreview>.com/static/devicetrust/OktaDeviceRegistrationTaskSetup-x.x.x.<msi/exe>

Where:

  • <org> is the name of your org
  • <okta/oktapreview> denotes either your Okta Production or Preview environment.
  • OktaDeviceRegistrationTaskSetup-x.x.x is the version of the Registration Task. For the latest version of the Registration Task, see Device Trust for Windows Desktop Registration Task Version History.
  • <msi/exe> is the file type of the Registration Task, either .msi or .exe.

For example, a link for downloading .msi Registration Task version 1.1.0 to example.oktapreview.com would look like this:

https://example.oktapreview.com/static/devicetrust/OktaDeviceRegistrationTaskSetup-1.1.0.msi

Install the Registration Task

Distribute the Registration Task using a management tool (SCCM)

Follow your organization's procedure for distributing software to domain-joined workstations. If your organization uses SCCM, you may want to refer to the Microsoft article How to Deploy Applications in Configuration Manager. Execute the appropriate command for *.exe or *.msi installation.

Note:Make sure to replace the filename and the org name in the command provided below with the actual filename and your org name.

MSI installation

Using a proxy server?

If your organization routes internet traffic through a proxy server, you must install Device Trust Registration Task version 1.2.1+ through a command line and append the proxy server address and port number to the installation command.

HttpProxy=<your proxy http url>:<port number>

For example, the installation command that includes the proxy server parameter would look similarly to this:

msiexec /i OktaDeviceRegistrationTaskSetup-1.x.x-xxxxxxx INSTALLDIR="c:\Program Files\Okta\DeviceTrust" EXEOPTIONS="/q2 OktaURL=https://<your Okta org>/ HttpProxy=<your proxy http url>:<port number>"

Note: Make sure to add a space if you are also adding the parameter to disable automatic certificate handling.


With automatic certificate challenge handling:

msiexec /i OktaDeviceRegistrationTaskSetup-1.x.x-xxxxxxx INSTALLDIR="c:\Program Files\Okta\DeviceTrust" EXEOPTIONS="/q2 OktaURL=https://<your Okta org>"


Without automatic certificate challenge handling.

msiexec /i OktaDeviceRegistrationTaskSetup-1.x.x-xxxxxxx INSTALLDIR="c:\Program Files\Okta\DeviceTrust" EXEOPTIONS="/q2 OktaURL=https://<your Okta org>/ SkipBrowserSetup=true"


EXE installation

Using a proxy server?

If your organization routes internet traffic through a proxy server, you must install Device Trust Registration Task version 1.2.1+ through a command line and append the proxy server address and port number to the installation command.

HttpProxy=<your proxy http url>:<port number>

For example, the installation command that includes the proxy server parameter would look similarly to this:

OktaDeviceRegistrationTaskSetup-1.0.0-XXXX.exe /q2 OktaURL=https://<your-okta-org-url>.com HttpProxy=<your proxy http url>:<port number>

Note: Make sure to add a space if you are also adding the parameter to disable automatic certificate handling.


With automatic certificate challenge handling:

OktaDeviceRegistrationTaskSetup-1.0.0-XXXX.exe /q2 OktaURL=https://<your-okta-org-url>.com


Without automatic certificate challenge handling:

OktaDeviceRegistrationTaskSetup-1.0.0-XXXX.exe /q2 OktaURL=https://<your-okta-org-url>.com/ SkipBrowserSetup=true

– or –

Manually install the Registration Task

This procedure is provided in case you want to install the Registration Task manually during the testing or Proof of Concept phase of your implementation.

  1. Copy the Registration Task to the domain-joined Windows computer.
  2. Run the command prompt as an Administrator.
    1. Click Start.
    2. In the search box, type cmd, and then press CTRL+SHIFT+ENTER.
  3. Change directories to the location of the file.
  4. Issue the command appropriate for the file type:
  5. Note:Make sure to replace the filename and the org name in the example command below with the actual file name and org name.

    MSI installation

    Using a proxy server?

    If your organization routes internet traffic through a proxy server, you must install Device Trust Registration Task version 1.2.1+ through a command line and append the proxy server address and port number to the installation command.

    HttpProxy=<your proxy http url>:<port number>

    For example, the installation command that includes the proxy server parameter would look similarly to this:

    msiexec /i OktaDeviceRegistrationTaskSetup-1.x.x-xxxxxxx INSTALLDIR="c:\Program Files\Okta\DeviceTrust" EXEOPTIONS="/q2 OktaURL=https://<your Okta org>/ HttpProxy=<your proxy http url>:<port number>"

    Note: Make sure to add a space if you are also adding the parameter to disable automatic certificate handling.


    With automatic certificate challenge handling:

    msiexec /i OktaDeviceRegistrationTaskSetup-1.x.x-xxxxxxx INSTALLDIR="c:\Program Files\Okta\DeviceTrust" EXEOPTIONS="/q2 OktaURL=https://<your Okta org>"


    Without automatic certificate challenge handling.

    msiexec /i OktaDeviceRegistrationTaskSetup-1.x.x-xxxxxxx INSTALLDIR="c:\Program Files\Okta\DeviceTrust" EXEOPTIONS="/q2 OktaURL=https://<your Okta org>/ SkipBrowserSetup=true"


    EXE installation

Using a proxy server?

If your organization routes internet traffic through a proxy server, you must install Device Trust Registration Task version 1.2.1+ through a command line and append the proxy server address and port number to the installation command.

HttpProxy=<your proxy http url>:<port number>

For example, the installation command that includes the proxy server parameter would look similarly to this:

OktaDeviceRegistrationTaskSetup-1.0.0-XXXX.exe /q2 OktaURL=https://<your-okta-org-url>.com HttpProxy=<your proxy http url>:<port number>

Note: Make sure to add a space if you are also adding the parameter to disable automatic certificate handling.


With automatic certificate challenge handling:

OktaDeviceRegistrationTaskSetup-1.x.x-xxxx.exe /q2 OktaURL=https://<your-okta-org-url>.com

Without automatic certificate challenge handling:

OktaDeviceRegistrationTaskSetup-1.x.x-xxxx.exe /q2 OktaURL=https://<your-okta-org-url>.com/ SkipBrowserSetup=true

A.3 — Verify certificate enrollment before you enable Device Trust

Click: Important to know before you begin

Before you enable Device Trust for your org, you must make sure that certificates are installed in the certificate store on the domain-joined computers you have targeted for this Device Trust solution. If certificates are not installed and Device Trust is enabled, users are denied access to apps that have been configured with the Trusted option in app sign-on policies, and are redirected to a security message advising them to contact their administrator. (You can configure the message to include a Learn more link to more information. For details, see here). To verify certificate enrollment, Okta recommends that you use your management tool to parse the Windows Event Viewer, or use a command line to query the user certificate store directly. Look for Okta MTLS certificate.

Note: If an end user is deactivated, all device trust certificates installed on their domain-joined Windows computer(s) are revoked (but not removed) automatically. To remove revoked certificates, see Revoke and remove Device Trust certificates.



Though you will probably use a management tool to verify that certificates are installed on multiple domain-joined computers, here are two ways to check enrollment on a single computer:

Verify with Windows Event Viewer
  1. Go to Start and type event in the search field.
  2. When Event Viewer appears at the top of the Start menu, press Enter to open it.
  3. Expand Applications and Services Logs.
  4. Click Okta Device Trust and find Event ID 1000. Screenshot
  5. Verify_WindowsEventVwr

Verify with Microsoft Management Console
  1. Go to Start and type mmc in the search field to open the console.
  2. Go to File and click Add/Remove Snap-in.
  3. Select Certificates and then click Add.
  4. In the Certificates snap-in dialog box, select My user account.
  5. Click Finish.
  6. Click OK.
  7. Under Console Root, expand Certificates - Current User.
  8. Expand the Personal folder, click Certificates and see the Okta MTLS certificate. Screenshot
  9. Verify_MSFTMgmtConsole2


A.4 — (Optional) Use GPO to configure browsers to select the certificate automatically

If appropriate for your environment, you can use a Group Policy Object (GPO) tool instead of the default capability of the Device Trust Registration Task to configure browsers to automatically select the device trust certificate. If you use a GPO tool, make sure that you have added the flag SkipBrowserSetup=true to the Registration Task installation command as detailed in section A.1.

If you opt not to configure automatic certificate selection — either through the Registration Task or a GPO — end users are prompted to select the certificate when accessing the app. To make the selection easier for end users, only the Okta Device Trust certificate will be shown to them in this case.

Note: Depending on the refresh interval, changes you make using GPO may not be seen immediately on Windows client computers. For more information, see the Microsoft article Group Policy refresh interval for computers.

To configure Chrome to select the Device Trust certificate automatically
  1. Download policy templates.
  2. Extract the zip file to the Desktop of the Active Directory Domain Controller.
  3. Copy files to folders:
  4. Copy:

    C:\end users\Administrator\Desktop\policy_templates\windows\admx\en-US\chrome.adml

    To:

    C:\Windows\PolicyDefinitions\en-US\


    Copy:

    C:\end users\Administrator\Desktop\policy_templates\windows\admx\chrome.admx

    To:

    C:\Windows\PolicyDefinitions\


  5. Open the Group Policy Management Console (GMPC).
    1. In the Start menu type Run.
    2. In Run, type gpmc.msc.
  6. Expand to the appropriate domain, navigate to Group Policy Objects, right click Default Domain Policy, and then click Edit. Screenshot
  7. GPCM_1

  8. Navigate to Computer Configuration > Policies > Administrative Templates: Policy definitions (ADMX files) retrieved from the local computer > Google Chrome > Content Settings.
  9. In the right pane click Automatically select client certificate for these sites, and then under Content Settings, click Edit policy setting. Screenshot
  10. GPCM_2

  11. In the dialog box that opens, click Enabled.
  12. Under Options, click Show.
  13. In the Show Contents dialog box, enter a value that specifies the subdomain of your org and indicates whether it applies to your Preview or Production org. Screenshot
  14. GPCM_3

For example:

If your Okta Preview org URL is https://[*.]oktapreview.com, you would enter the following value:

{"pattern":"https://[*.]oktapreview.com","filter":{"ISSUER":{"CN":"MTLS Certificate Authority"}}} 

If your Okta Production org URL is https://[*.]okta.com, you would enter the following value:

{"pattern":"https://[*.]okta.com","filter":{"ISSUER":{"CN":"MTLS Certificate Authority"}}}
  • Click OK.
  • Confirm that auto certificate settings are configured:
    1. Refresh GPO, either by waiting for the next GPO refresh interval, or by issuing the gpupdate command.
    2. In Chrome, enter chrome://policy in the address bar, and then press Enter. Screenshot
    3. VerifyPolicy_Chrome

    4. Click Show value and verify that the policy AutoSelectCertificateForUrls displays this value:
    5. {"pattern":"https://[*.]oktapreview.com","filter":{"ISSUER":{"CN":"MTLS Certificate Authority"}}}

    You can also confirm settings through the Windows Registry Editor:

    1. Go to Start and type regedit in the search field
    2. In Registry Editor, navigate to:
    3. HKEY_LOCAL_MACHINE > SOFTWARE > Policies > Google > Chrome > AutoSelectCertificateForUrls Screenshot

      VerifyPolicy_Regedit

To configure IE to select the Device Trust certificate automatically
  1. From the Active Directory Domain Controller, open the Group Policy Management Console (GMPC).
    1. In the Start menu type Run.
    2. In Run, type gpmc.msc and then press Enter.
  2. Expand to the appropriate domain, navigate to Group Policy Objects, right click on Default Domain Policy, and then click Edit. Screenshot
  3. GPCM_1

  4. Navigate to Computer Configuration > Policies > Administrative Templates: Policy definitions (ADMX files) retrieved from the local computer > Windows Components > Internet Explorer > Internet Control Panel > Security Page > Internet Zone.
  5. In the right pane under Settings, double click Do not prompt for client certificate selection when no certificates or only one certificate exists. Screenshot
  6. GPCM_2_IE

  7. In the dialog box that opens, click Enabled.
  8. Close open windows.
  9. Navigate to Computer Configuration > Policies > Administrative Templates: Policy definitions (ADMX files) retrieved from the local computer > Windows Components > Internet Explorer > Internet Control Panel > Security Page.
  10. In the right pane under Settings, double click Site to Zone Assignment List. Screenshot
  11. GPCM_3_IE_SiteToZone

  12. In the dialog box that opens, click Enabled.
  13. Under Options, next to Enter the zone assignments here, click Show.
  14. In the Show Contents dialog box, enter either *okta.com or *oktapreview.com as the Value name depending on whether you are deploying this feature in your Okta Production or Preview org. Screenshot
  15. GPCM_4_IE_SiteToZone

  16. Click OK to close open windows.
  17. Confirm that the GPO settings are configured:
    1. Refresh GPO, either by waiting for the next GPO refresh interval, or by issuing the gpupdate command in a command line.
    2. In the Start menu type Run.
    3. In Run, type gpedit.msc and then press Enter.
    4. Navigate to Computer Configuration > Policies > Administrative Templates: Policy definitions (ADMX files) retrieved from the local computer > Windows Components > Internet Explorer > Internet Control Panel > Security Page > Internet Zone.
    5. In the right pane under Settings, double click Do not prompt for client certificate selection when no certificates or only one certificate exists.
    6. In the dialog box that opens, confirm that the setting is Enabled. Screenshot
    7. GPCM_e_IE_VerifyEnabled



Part Ⓑ — Enable the global Device Trust setting for your org

Click: Important to know before you begin
  • Before you enable Device Trust for your org, you must make sure that certificates are installed in the certificate store on the domain-joined computers you have targeted for this Device Trust solution. If certificates are not installed and Device Trust is enabled, users are denied access to apps that have been configured with the Trusted option in app sign-on policies, and are redirected to a security message advising them to contact their administrator. (You can configure the message to include a Learn more link to more information. For details, see here). To verify certificate enrollment, Okta recommends that you use your management tool to parse the Windows Event Viewer, or use a command line to query the user certificate store directly. Look for Okta MTLS certificate.
  • Do not disable the Desktop Device Trust setting on the Security > Device Trust page if you have also configured an app sign on policy for Office 365 that allows trusted Windows devices. Otherwise, your Device Trust configuration will be in an inconsistent state and users with untrusted devices will not be shown the security message advising them to contact their administrator, nor the Learn more link to more information (if configured; for details about the link, see here).


  1. From the Okta Admin dashboard, go to Security > Device Trust.
  2. Click Edit.
  3. In the Desktop section, click Enable Desktop Device Trust.
  4. (Optional) In the Learn more link field, you can enter an externally-accessible redirect URL where end users with untrusted devices can find more information. The security message shown to these end users will include a Learn more link that redirects to your specified URL. Screenshot

    DT_Security_URLspecified_2

    If you choose not to specify a URL in this optional field, these end users will be shown the same message but without the Learn more link. Screenshot

    DT_Security_noURLspecified_2

  5. Click Save.
  6. If you have not done so already, configure app Sign-On policy rules.

Part Ⓒ — Configure app Sign On policy rules in Okta

Click: Important to know before you begin
  • Only Super and App admins can configure app Sign On policies.
  • Do not disable the Desktop Device Trust setting on the Security > Device Trust page if you have also configured an app sign on policy for Office 365 that allows trusted Windows devices. Otherwise, your Device Trust configuration will be in an inconsistent state and users with untrusted devices will not be shown the security message advising them to contact their administrator, nor the Learn more link to more information (if configured; for details about the link, see here).

  • If you decide to ask Okta Support to disable Device Trust capability for your org, make sure to first change the Device Trust setting in the app sign on policy rules to Any (Applications > app > Sign On). If you do not make this change and then later have Okta Support re-enable Device Trust capability for your org, the Device Trust setting in app sign on policy rules will take effect immediately, which you may not have expected.

By default, all Client options in the App Sign On Rule dialog box are pre-selected to allow users of all client types and platforms to access the app. To configure more granular access to the app, selectively apply conditions as you create one or more prioritized rules based on:

  • Who users are and/or the groups to which they belong
  • Whether they are on or off network or within a defined network zone
  • The type of client running on their device (Office 365 apps only)
  • The platform of their mobile or desktop device
  • Whether or not their devices are Trusted
Whitelist and blacklist approaches to creating Sign On policy rules

Typical approaches to creating and prioritizing rules often employ whitelist and blacklist concepts:

  • In a whitelist approach, you might do the following:
    1. Create one or more permissive rules to support the scenarios that will allow access to the app, then assign those rules the highest priority.
    2. Create a Deny catch-all rule that will apply to users who don't match the permissive scenarios you created in Step 1. Assign the Deny catch-all rule the lowest priority, just above Okta's Default Rule. The Default Rule is applied to users who don't match any of the more restrictive rules that have higher priority.
  • In a blacklist approach, you create one or more restrictive rules designed to deny app access to — or increase the authentication requirements for (MFA, Device Trust) — everyone except certain users/groups connected to a specified network or network range from specified client(s) and platform(s). Users able to pass through the restrictive rule(s) are then subject to the Default policy, which is designed to allow access to everyone.

Procedure

  1. In Okta, go to Applications and click the SAML or WS-Fed-enabled app that you want to protect with Device Trust.
  2. Click the Sign On tab, scroll down to the Sign On Policy, and click Add Rule.
  3. Configure one or more rules using the following examples as a guide.

Note: These examples show Device Trust rules for managing access to Office 365. For other apps, note that the section If the user's client is any of these is not present.

Example 1 — Blacklist

Example 1, Rule 1 — Web browser or Modern Auth; Windows; Not trusted; Deny access

Screenshot

E1_R1_Web_Win_NoT_Denied

  1. Enter a descriptive name for the rule.

CONDITIONS

  1. Under People, specify whether to apply the rule to individuals only or to individuals and groups. The People option you select needs to be the same for both the rules you create for this example.
  2. Under Location, specify the user location to which the rule will apply. The Location option you select needs to be the same for both the rules you create in this example.
  3. Configure client settings:
  4. Type:

    þWeb browser or Modern Auth client is selected.

    ¨Exchange ActiveSync client is unselected.

    Mobile:

    ¨iOS is unselected.

    ¨Android is unselected.

    ¨Other mobile is unselected.

    Desktop:

    þWindows is selected.

    ¨macOS is unselected.

    ¨Other desktop is unselected

  5. Configure Device Trust.
  6. ¨Any is unselected.

    ¨Trusted is unselected.

    þNot trusted is selected.

ACTIONS

  1. Configure Access:
  2. Denied is selected.

  3. Click Save.
  4. Create Rule 2.
Example 1, Rule 2 — Web browser or Modern Auth; All platforms; Any Trust; Allow access + MFA

Screenshot

E1_R2_Web_AllP_AnyT_MFA

  1. Enter a descriptive name for the rule.

CONDITIONS

  1. Under People, select the same People option that you selected in Rule 1 of this example. The People option needs to be the same for both rules in this example.
  2. Under Location, select the same Location option that you selected in Rule 1 of this example. The Location option needs to be the same for both rules in this example.
  3. Configure client settings:
  4. Type:

    þWeb browser or Modern Auth client is selected.

    ¨Exchange ActiveSync client is unselected.

    Mobile:

    þiOS is selected.

    þAndroid is selected.

    þOther mobile is selected.

    Desktop:

    þWindows is selected.

    þmacOS is selected.

    þOther desktop is selected.

  5. Configure Device Trust.
  6. þAny is selected.

    ¨Trusted is unselected.

    ¨Not trusted is unselected.

ACTIONS

  1. Configure Access:
  2. Allowed is selected.

    þPrompt for factor is selected.

  3. Click Save.

Example 2 — Whitelist

Example 2, Rule 1 — Exchange ActiveSync or Legacy Auth; All platforms; Any Trust; Allow access

Screenshot

E2_R1_EAS-AnyP-AnyT-Allow

  1. Enter a descriptive name for the rule.

CONDITIONS

  1. Under People, specify whether to apply the rule to individuals only or to individuals and groups. The People option you select needs to be the same for all the rules you create for this example.
  2. Under Location, specify the user location to which the rule will apply. The Location option you select needs to be the same for all the rules you create for this example.
  3. Configure client settings:
  4. Type:

    ¨Web browser or Modern Auth client unselected.

    þExchange ActiveSync client or Legacy Auth client is selected.

    Mobile:

    þiOS is selected.

    þAndroid is selected.

    þOther mobile is selected.

    Desktop:

    þWindows is selected.

    þmacOS is selected.

    þOther desktop is selected

  5. Configure Device Trust.
  6. þAny is selected.

    ¨Trusted is unselected.

    ¨Not trusted is unselected.

ACTIONS

  1. Configure Access.
  2. Allowed is selected.

  3. Click Save.
  4. Create Rule 2.
Example 2, Rule 2 — Web browser or Modern Auth; Windows; Trusted; Allow access + MFA

Screenshot

E2_R2_Web-Win-Trust-Allow-MFA

  1. Enter a descriptive name for the rule.

CONDITIONS

  1. Under People, select the same People option that you selected in Rule 1. The People option needs to be the same for all rules in this example.
  2. Under Location, select the same Location option that you selected in Rule 1. The Location option needs to be the same for all rules in this example.
  3. Configure client settings:
  4. Type:

    þWeb browser or Modern Auth client is selected.

    ¨Exchange ActiveSync client is is unselected.

    Mobile:

    ¨iOS is unselected.

    ¨Android is unselected.

    ¨Other mobile is unselected.

    Desktop:

    þWindows is selected.

    ¨macOS is unselected.

    ¨Other desktop is unselected.

  5. Configure Device Trust.
  6. ¨Any is unselected.

    þTrusted is selected.

    ¨Not trusted is unselected.

ACTIONS

  1. Configure Access:
  2. Allowed is selected.

    þPrompt for factor is selected.

  3. Click Save.
  4. Create Rule 3.
Example 2, Rule 3 — Web browser or Modern Auth; All platforms except Windows; Any Trust, Allow access + MFA

Screenshot

E2_R3_Web_AllButWin_AnyT_MFA

  1. Enter a descriptive name for the rule.

CONDITIONS

  1. Under People, select the same People option that you selected in Rule 1. The People option needs to be the same for all rules in this example.
  2. Under Location, select the same Location option that you selected in Rule 1. The Location option needs to be the same for all rules in this example.
  3. Configure client settings:
  4. Type:

    þWeb browser or Modern Auth client selected.

    ¨Exchange ActiveSync client is unselected.

    Mobile:

    þiOS is selected.

    þAndroid is selected.

    þOther mobile is selected.

    Desktop:

    þWindows is selected

    þmacOS is selected

    þOther desktop is selected

  5. Configure Device Trust.
  6. þAny is selected.

    ¨Trusted is unselected.

    ¨Not trusted is unselected.

ACTIONS

  1. Configure Access.
  2. Allowed is selected.

    þPrompt for factor is selected.

  3. Click Save.
  4. Create Rule 4.
Example 2, Rule 4 — Any client; All platforms; Any Trust; Deny access

Screenshot

E2_R4_AnyClien_AnyP_AnyT_Denied

  1. Enter a descriptive name for the rule.

CONDITIONS

  1. Under People, select the same People option that you selected in Rule 1. The People option you select needs to be the same for all the rules you create for this example.
  2. Under Location, select the same Location option that you selected in Rule 1. The Location option you select needs to be the same for all the rules you create for this example.
  3. Configure client settings:
  4. Type:

    þWeb browser or Modern Auth client selected.

    þExchange ActiveSync client is selected.

    Mobile:

    þiOS is selected.

    þAndroid is selected.

    þOther mobile is selected.

    Desktop:

    þWindows is selected.

    þmacOS is selected.

    þOther desktop is selected.

  5. Configure Device Trust.
  6. þAny is selected.

    ¨Trusted is unselected.

    ¨Not trusted is unselected.

ACTIONS

  1. Configure Access.
  2. Denied is selected.

  3. Click Save.

Part Ⓓ – Revoke and remove Device Trust certificates

You may need to revoke an end user's Device Trust certificate(s) from the Okta Certificate Authority. This is recommended if the computer is lost or stolen. To re-secure an end user's computer with Device Trust after revoking their Device Trust certificate(s), you need to remove the certificate from their computer before enrolling a new certificate.

Click: Important to know before you begin
  • Steps 1 - 4 of this procedure revoke all Device Trust certificates from the Okta Certificate Authority that were issued to the end user. Certificate revocation does not remove existing certificates from managed Windows computers. In order to re-secure a Windows computer with Device Trust after revoking certificates, you must first remove any existing Device Trust certificate from the computer and then re-enroll the computer with a new certificate as detailed in Step 5. The Device Trust Registration Task will not enroll a new certificate if another certificate (whether revoked or not) is present on the computer.
  • Deactivating an end user in Okta also revokes their Device Trust certificate from the Okta Certificate Authority (but does not remove the certificate from their computer).

  1. Go to Directories > People.

  2. Click the end user whose Device Trust certificate you want to revoke.

  3. In the More Actions menu, click Revoke Trust Certificate. Screenshot

    DT_revokeTrustCert_80per

  4. Read the message that displays, and then click Revoke Trust Certificate.

  5. (Optional) If you want to re-secure the end user's computer with Device Trust, first remove any existing Device Trust certificate from the computer.

    • To remove a certificate from a single computer (such as during testing or the Proof of Concept phase of your implementation), use a third-party management tool such as Certificate Manager Tool (Certmgr.exe) to remove the certificate issued by the Okta MTLS Certificate Authority.

    • To remove certificates from multiple computers, use a third-party management tool such as GPO or SCCM to remove the certificate issued by the Okta MTLS Certificate Authority.


Troubleshooting

Device Trust for Windows generates a certificate on domain-joined Windows devices and presents it to Okta when a Device Trust-secured WS-Fed or SAML app is launched. The two problems that you are most likely to encounter are:

  • End users with trusted devices are unable to access Device Trust-secured apps.
  • End users with untrusted devices are able to access Device Trust-secured apps.

If you encounter either problem, try to correct it by performing Basic Troubleshooting. If the problem persists, perform Advanced Troubleshooting.

Basic Troubleshooting

To perform basic troubleshooting, review the following areas:

IWA web app installation and setup

Verify the following:

If the problem persists, proceed to Advanced Troubleshooting.

Enablement

Verify the following:

  • Okta Customer Support has enabled this Device Trust solution for your org. (This is necessary during the Early Access phase of this Device Trust solution.) This is in addition to the global Device Trust setting that you enable in Okta via Security > Device Trust.
  • — and —

  • You have enabled the global Device Trust setting in Security > Device Trust.
Registration task

Verify that you have distributed the Device Trust Registration Task to Windows domain-joined workstations.

Proxy server environments — In order for the Registration Task installation to succeed in environments that implement a proxy server, you must install Device Trust Registration Task version 1.2.1 or higher through a command line and append the proxy server address and port number to the installation command. For example:

HttpProxy=<your proxy http url>:<port number>

For details, see Install the Registration Task.

Certificate

Verify that the certificate is installed on Windows domain-joined workstations.

  1. Open Microsoft Management Console as described in section A.3.
  2. Open the end user's personal store (not the Local computer store).
  3. Verify that a single certificate appears under Personal > Certificates issued by MTLS Certificate Authority.
  4. If no certificate appears, proceed to Advanced Troubleshooting.

Device Trust certificate picker displays when some end users access Device Trust-secured apps

End users running the 32-bit version of Internet Explorer on their domain-joined computer may be prompted to pick the Device Trust certificate when accessing Device Trust-secured apps. This happens because the Device Trust Registration Task automatically configures the 64-bit version of Microsof Internet Explorer and Edge browsers. The following procedure shows how to set the trusted site settings in the 32-bit version of the registry on a single Windows computer. Use a tool like GPO to push registry updates to multiple computers in your organization.

  1. Go to Start and type regedit in the search field.
  2. In the Registry Editor, navigate to:

    HKEY_CURRENT_USER > Software > Wow6432Node > Microsoft > Windows > CurrentVersion > Internet Settings > Zones > 2

  3. Add a REG_DWORD value called 1A04 and set it to 0.
  4. Navigate to:

    HKEY_CURRENT_USER > Software > Wow6432Node > Microsoft > Windows > CurrentVersion > Internet Settings > ZoneMap > Domains

  5. Select the Domains folder and then add a Key (a subkey) called okta.com.
  6. Under the okta.com subkey add a REG_DWORD value called https and set it to 2.
  7. Advise affected end users to restart IE and try to access the app again.
Sign On Policy

Verify the following:

You have configured a Sign On Policy that:

  • Is applied to the WS-Fed or SAML app that you want to secure with Device Trust.
  • Is applied to the correct user(s) and/or groups.
  • Includes, at minimum, an Activerule that denies access to untrusted devices.
System Log

Review the System Log to verify the following Device Trust System Log events:

Authentication

  • DisplayMessage: Authentication of device via certificate
  • EventType: user.authentication.authenticate

Enrollment

  • DisplayMessage: Device Trust certificate enrollment
  • EventType: user.credential.enroll

Issuance

  • DisplayMessage: Device Trust certificate issuance
  • EventType: pki.cert.issue

Revocation

  • DisplayMessage: Device Trust certificate revocation
  • EventType: pki.cert.revoke

For a helpful explanation of the System Log, see this KB article.

Advanced Troubleshooting

If Basic Troubleshooting did not resolve the problem you are experiencing, and the certificate is not installed on the Windows workstation, check in the following locations:

In the Okta Admin app

Verify the following:

  • The org has an active Active Directory (AD) integration (Directory > Directory Integrations)
  • The end user of the domain-joined Windows computer is:
    • Present in Directory > People
    • Activated
    • A member of the Active Directory domain
  • The IWA web app is:
    • Primary
    • Enabled
  • A Device Trust-capable version

(Security > Delegated Authentication > Desktop Single Sign On > Integrated Windows Authentication)

DT_Trouble_IWA_status

On the IWA server

Check IIS settings for the IWA web app

  1. Click Start.
  2. In the search box, type IIS.
  3. Right click Internet Information Services Manager and select Run as administrator.
  4. If the IWA web app is configured for SSL, open SSL settings and make sure the option Require SSL is selected.
  5. Open the Authentication feature and make sure Windows Authentication is Enabled.

DT_Trouble_IWA_IIS_1

Check for errors in the web.config file

  1. Go to C:\Inetpub\wwwroot\IWA\web.config.
  2. Use a validation tool to make sure the web.config file contains valid XML syntax.
  3. If HTTPS was enabled in IIS on the site, make sure that the web.config file enables SecureBindingForDeviceTrust.

Check for errors in Windows Logs > Applications and Services Logs > Okta Single Sign On

  1. Click Start.
  2. In the search box, type Event Viewer.
  3. Expand Application and Services Logs.
  4. Check for errors in Okta Single Sign On.

DT_Trouble_AppSvcLogs

On the domain-joined Windows computer

Make sure Okta Device Trust Tasks were installed and successful:

  1. Click Start.
  2. In the search box, type Task Scheduler.
  3. Right click Task Scheduler and select Run as administrator.
  4. Make sure the tasks okta-devicetrust-devicetask and okta-devicestrust-usertask appear and have completed successfully.

DT_TaskSched

Check for errors in Windows Logs > Applications and Services Logs > Okta Device Trust:

  1. Click Start.
  2. In the search box, type Event Viewer.
  3. Expand Application and Services Logs.
  4. Click Okta Device Trust.

DT_EViewer

Run the task in debug mode as the logged-on user

  1. Make sure the IWA server is reachable when the task is run (either directly over the internet or via VPN).
  2. Open a command prompt and issue the following command:
  3. "C:\Program Files\Okta\DeviceTrust\OktaDeviceReg.exe" --user --debug
  4. If the device trust certificate is not generated on the device, the task executes the following actions:
    • Contacts Okta at the registry value pointed to by HKLM\Software\Okta\DeviceTrust\OktaOrgUrl and gets the location of the IWA server for the org.
    • Contacts the IWA server to generate the device token for the device.
    • Contacts the IWA server to generate a user token based on the device token.
    • Contacts Okta with the generated user token to generate the certificate.
    • Installs the certificate in the user's personal store.

The user token is a set of JWT claims signed by the IWA server. You may be asked to copy the token and provide it to Okta Support for analysis.

DT_OktaDeviceReg-Running2


Known Issues
  • Multiple apps opening simultaneously — If multiple apps secured by Device Trust are configured to open automatically when end users sign in to their Okta dashboard from IE or Edge browsers, only one of the apps completes the Device Trust flow. Access to the remaining apps fails and end users are presented a message advising them to contact their administrator. (For details about this message, see here.)
  • Device Trust for Windows desktop + certificate-based IWA for SSO — Configuring this Device Trust solution may cause an incompatibility issue if your org is configured with certificate-based IWA to support SSO for iOS and Android mobile devices. In that case, end users signing in to Okta using IWA from Windows computers with a Device Trust certificate and an IWA certificate installed may be presented with a certificate picker containing both certificates during the Desktop SSO flow, which may cause confusion. If end users select the device trust certificate, they will get a 403 error during the IWA flow. It may be possible to enable certificate hinting in IIS so that only one certificate is shown to users. For details, see this Microsoft article.
  • Checking .NET version — The Device Trust Registration Task checks the version of the .NET Framework running on managed Windows computers. If the version is not 4.5.2 or higher, the Registration Task installs version 4.5.2 automatically and, during installation, progress indicators and other installation dialog boxes will appear on end user screens.
  • Device Trust certificate picker displays when some end users access Device Trust-secured apps — End users running the 32-bit version of Internet Explorer on their domain-joined computer may be prompted to pick the Device Trust certificate when accessing Device Trust-secured apps. This happens because the Device Trust Registration Task automatically configures the 64-bit version of Microsof Internet Explorer and Edge browsers. To prevent the certificate picker from displaying in this case, edit the Windows registry as detailed in Basic Troublshooting.

Post a Comment