This is an Early AccessEarly Access (EA) features are opt-in features that you can try out in your org by asking Okta Support to enable them. Additionally, the Features page in the Okta Admin Console (Settings > Features) allows Super Admins to enable and disable some EA features themselves. feature. To enable it, please contact Okta Support.

Enforce Okta Device Trust for Jamf Pro-managed macOS devices

Okta Device Trust for Jamf Pro-managed macOS allows you to prevent unmanaged macOS computers from accessing corporate SAMLAn acronym for Security Assertion Markup Language, SAML is an XML-based standard for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). The SAML standard addresses issues unique to the single sign-on (SSO) solution, and defines three roles: the end user, the IDP, and the SP. and WS-Fed cloud apps. Device Trust ensures that only known and secured devices can access your Okta-managed applications.


ClosedDiagram — device authentication and certificate flow


ClosedPrerequisites
  • (Necessary only during the Early Access phases of this Device Trust solution) Make sure that Okta Customer Support has enabled this Device Trust solution for your orgThe Okta container that represents a real-world organization.. This is in addition to the global Device Trust setting that you enable in Part Ⓐ.
  • The Mutual TLS certificate exchange (handshake) in this Device Trust flow occurs on Okta URLs that are separate from your Okta org URL (indicated by the wildcard character (*) in the example below). If you implement endpoint protection software, make sure to configure it in a way that does not block your clients from completing the certificate exchange with Okta. For example, if your organization uses a whitelist to limit outbound traffic, add these exact URLs to the whitelist, including the wildcard character (*), as shown here:

    • *.okta.com

    *.okta-emea.com

  • This solution works with:
    • Apple computers running Okta-supported versions of macOS.
    • Jamf Pro MDM solution
    • The following browsers and native apps capable of accessing the Okta Keychain on the managed computer when performing the federated authentication flow to Okta:
      • Browsers: Chrome and Safari browsers
      • Modern Auth-enabled native apps:
        • Box
        • Google Drive
        • Microsoft Office
        • Skype for Business

ClosedProcedures
ClosedPart Ⓐ — In Okta: Enable the global Device Trust setting for your org
  1. From the Okta AdminAn abbreviation of administrator. This is the individual(s) who have access to the Okta Administrator Dashboard. They control the provisioning and deprovisioning of end users, the assigning of apps, the resetting of passwords, and the overall end user experience. Only administrators have the Administration button on the upper right side of the My Applications page. Dashboard, go to Security > Device Trust.
  2. In the macOS Device Trust section, click Edit.
  3. In the wizard that launches, select Enable macOS Device Trust.
  4. (Optional) In the Learn more field, you can enter an externally-accessible redirect URL where end usersIn Okta literature, we generally refer to "end users" as the people who have their own Okta home page (My Applications), using chiclets to authenticate into all of their apps. End users do not have any administrative control. When we refer to "users" we are generally referring to the individual(s) who have administrative control. with untrusted devices can find more information. The security message shown to these end usersIn Okta literature, we generally refer to "users" as the people who serve as Okta administrators. When we refer to "end users" we are generally referring to the people who the administrators serve. That is, those who use Okta chiclets to access their apps, but have no administrative control. will include a Learn more link that redirects to your specified URL.ClosedScreenshot

    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. ClosedScreenshot

  5. In Trust is established by, select Jamf Pro.
  6. Enter information about the Jamf Pro API, such as the Jamf Pro tenant URL (for example, https://example.jamfcloud.com, not the API URL), credentials, and key.

    This information allows Okta to verify that end user devices are managed by your MDM provider at the time of certificate enrollment. For Jamf Pro, you need at least these READ privileges to access Jamf APIs in order for Okta to verify that the device is managed:

    7. Important:Okta strongly recommends that you create a separate user for API access that is separate from the user your organization uses to access the Jamf Pro admin interface.

  7. Click Test API credentials. A success message appears if a connection is established with your MDM provider's API.
  8. Click Next.
  9. On the Configure MDM Provider screen, click Download to obtain a python script. You'll modify the script in Part Ⓑ below.
  10. To copy the provided Secret Key Value and Org URL to your clipboard, click the copy icon adjacent to the fields.

    11. Important: Make a note of the provided Secret Key Value and Org URL, as this is the only time these will appear in Okta. Also, if you later want to edit your configuration and generate a new secret Key through the Reset macOS secret Key button, you must perform this procedure again.

  11. Click Done.
  12. Modify the downloaded Okta Device Registration Task as described in Part Ⓑ.

    The latest version of the Okta Device Registration Task is also available from the Settings > Downloads page of the Okta Admin Console.


ClosedPart Ⓑ — On Admin's computer: Modify the Okta Device Registration Task

ClosedUsing endpoint protection software?


The Mutual TLS certificate exchange (handshake) in this Device Trust flow occurs on Okta URLs that are separate from your Okta org URL (indicated by the wildcard character (*) in the example below). If you implement endpoint protection software, make sure to configure it in a way that does not block your clients from completing the certificate exchange with Okta. For example, if your organization uses a whitelist to limit outbound traffic, add these exact URLs to the whitelist, including the wildcard character (*), as shown here:

*.okta.com

*.okta-emea.com


  1. Go to your Downloads folder and open the script you downloaded from Okta.
  2. Modify the script by pasting in the Secret Key Value and Org URL you generated in Part Ⓐ.

    3. When entering the key and the URL, retain the single quotation marks ( ' ) but replace the parentheses and the placeholder text with the actual Secret Key Value and Org URL, as shown in the following example:


    Example: Script before modification


    Example: Modified script. Note that you must retain the single quotation marks but not the parentheses.

  3. Save the script.
  4. Proceed to Part Ⓒ.

ClosedPart Ⓒ — In Jamf Pro: Add the modified Okta Device Registration Task to your MDM app and distribute it to macOS devices

ClosedClick: About the Okta Device Registration Task

The Okta Device Registration Task is a script that is distributed by your MDM provider to the macOS devices you have targeted for this Device Trust solution. When deployed on the device, the Okta Device Registration Task does the following:

Jamf Pro

Create the workflows that make sense for your organization, making sure that the script runs at least once successfully to enroll the Okta certificate.

  1. In Jamf Pro click the gear icon to go to All Settings.
  2. Go to Computer Management > Scripts.
  3. Create a new script and paste into it the Okta Device Registration Task you downloaded from Okta in Part Ⓐ and modified in Part Ⓑ.
  4. Save the script.
  5. Create a policy to deploy the script to one or more Target Computers and/or Target Users:
    1. Go to Computers > Policies.
    2. Click + New.
    3. Click General in the left pane.
    4. Give the policy a name.
    5.  Select the following Trigger events that will initiate the policy:
      • Enrollment Complete – the script runs immediately after devices complete the enrollment process.
      • Recurring Check-in – the script runs according to the recurring check-in frequency configured in Jamf Pro.
    6. Set the Execution Frequency to Once per computer per user.

      Note: There are other approaches that you can implement in Jamf Pro to trigger deployment of the script (for example, Extension Attributes, which allow you to validate that the certificate is on the device and to deploy the certificate if it is missing).

    7. Click Scripts and add the script you created earlier to this policy.
    8. Click ScopeA scope is an indication by the client that it wants to access some resource..
    9. In Target Computers and/or Target Users, specify the computers and users to whom the policy will apply.
    10. Save the policy.
  6. (Recommended) To prevent iCloud from transferring the Okta keychain from Device Trust-secured macOS devices to other Apple devices, you should create a Configuration Profile in Jamf Pro that disables Allow iCloud Keychain syncing. ClosedScreenshot

  7. Check the log in Jamf Pro to verify that the Okta Device Registration Task ran successfully.
    1. Go to Policies and click your policy.
    2. Click Logs at the bottom of the screen.
  8. Proceed to Part Ⓓ.

ClosedPart Ⓓ — In Okta: Configure app Sign On policy rules in Okta

ClosedClick: Important to know before you begin
  • Only Super Admins, App Admins, and API AM Admins can configure app Sign On policies.

  • To secure Microsoft Office apps with this Device Trust solution they must be enabled to support Modern Authentication. For more information, see this Microsoft article. For information about securing Office 365 clients that use legacy protocols, see Office 365 Client Access Policies.

  • Before you configure the Trusted option for apps in App Sign On Policy rules, make sure that certificates are installed in the keychain on the devices you have targeted for this Device Trust solution. If certificates are not installed and the Trusted setting is enabled, users are denied access to the app 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).

  • Do not disable the macOS Device Trust setting on the Security > Device Trust page if you have also configured an app sign on policy that allows trusted macOS devices. Otherwise, your Device Trust configuration will be in an inconsistent state. To disable Device Trust for your org, first remove any app sign on policies that contain a Device Trust setting, then disable macOS Device Trust in Security > Device Trust.

  • If you 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.

Overview

By default, all ClientEssentially, a client is anything that talks to the Okta service. Within the traditional client-server model, Okta is the server. The client might be an agent, an Okta mobile app, or a browser plugin. options in the App Sign On Rule dialog box are pre-selected. Notice that the Trusted and Not trusted options in the Device Trust section are not available unless you deselect all options in the Client section except the following, as applicable:

  • Web browser (this option is available only when configuring Office 365 apps)
  • Modern Auth client (this option is available only when configuring Office 365 apps)
  • iOS and/or Windows and/or macOS and/or Android, as applicable

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
ClosedWhitelist approach to creating Sign On policy rules

Procedure

Note: This example shows 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.

  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.

Whitelist example

ClosedExample Rule 1 – Exchange ActiveSync; All platforms; Any trust; Allow access

ClosedScreenshot

  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 must 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 must be the same for all the rules you create for 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 selected.

    þ Android is selected.

    þ Other mobile is selected.

    Desktop:

    þ Windows is selected.

    þ macOS is selected.

    þ Other desktop is selected.

  4. Configure Device Trust.

    5. þ Any is selected.

    ¨ Trusted is unselected.

    ¨ Not trusted is unselected.

ACTIONS

  1. Configure Access:

    2. Allowed is selected.

    ¨ Prompt for factor is unselected.

  2. Click Save.
  3. Create Rule 2.
ClosedExample Rule 2 – Web browser or Modern Auth; macOS; Trusted; Allow access

ClosedScreenshot

  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 must 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 must 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 unselected.

    ¨ Android is unselected.

    ¨ Other mobile is unselected.

    Desktop:

    ¨ Windows is unselected.

    þ macOS is selected.

    ¨ Other desktop is unselected

  4. Configure Device Trust.

    5. Note: In order for options in the Device Trust section to be available, you must deselect all options in the Client section except Web browser or Modern Auth client and macOS.

    ¨ Any is unselected.

    þ Trusted is selected.

    ¨ Not trusted is unselected.

ACTIONS

  1. Configure Access.

    2. Allowed is selected.

    ¨ Prompt for factor is unselected.

  2. Click Save.
  3. Create Rule 3.
ClosedExample Rule 3 – Web browser or Modern Auth; All platforms except macOS; Any Trust; Allow access + MFA

ClosedScreenshot

  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 must be the same for all 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 must be the same for all rules you create for this example.
  3. Configure client settings:

    4. Type:

    þ Web browser or Modern Auth client selected.

    ¨ Exchange ActiveSync client is unselected.

    Mobile:

    ¨ iOS is unselected.

    þ Android is selected.

    þ Other mobile is selected.

    Desktop:

    þ Windows is selected.

    þ macOS is selected.

    þ Other desktop is selected.

  4. Configure Device Trust.

    5. Note: In order for options in the Device Trust section to be available, you must deselect all options in the Client section except Web browser or Modern Auth client and macOS.

    þ Any is selected.

    ¨ Trusted is unselected.

    ¨ Not trusted is unselected.

ACTIONS

  1. Configure Access.

    2. Allowed is selected.

    þ Prompt for factor is selected.

  2. Click Save.
  3. Create Rule 4.
ClosedExample Rule 4 – Any client type; All platforms; Any Trust; Deny access

ClosedScreenshot

  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 must be the same for all 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 must be the same for all 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.

  4. Configure Device Trust.

    5. þ Any is selected.

    ¨ Trusted is unselected.

    ¨ Not trusted is unselected.

ACTIONS

  1. Configure Access.

    2. Denied is selected.

  2. Click Save.
ClosedRule 5 — Default sign on rule – Any client, All platforms; Any Trust; Allow access

The Default sign on rule is already created and cannot be edited. In this example, the Default rule is never reached because it is effectively negated by Rule 4.

ClosedScreenshot



ClosedPart Ⓔ — In Okta: 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, or if the end user is deactivated. To re-secure an end user's computer with Device Trust after revoking their Device Trust certificate(s), you need to remove the revoked certificate from their computer before enrolling a new certificate.

ClosedClick: 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 macOS computers. In order to re-secure a macOS 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.
  • When an end user deactivated Okta also revokes their Device Trust certificate from the Okta Certificate Authority automatically (but does not remove the certificate from their computer). To remove the certificate from the computer, use either removal method described in Step 5.

  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. ClosedScreenshot

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

  5. To remove the Device Trust certificate for any reason (such as prior to re-securing a computer with Device Trust), first remove any existing Device Trust certificate from the computer. You can use a command line or create an uninstall script in Jamf Pro.
    • Remove through a command line — Open a terminal on the target computer and issue the command python <fileName>.py uninstall where <fileName> is the name of Okta Device Registration Task. For example, if the name of the Okta Registration Task is MacOktaDeviceRegistrationTaskSetup.1.0.2.py, you would issue this command:

      python MacOktaDeviceRegistrationTaskSetup.1.0.2.py uninstall

    • Remove with an uninstall script — Create an uninstall script in Jamf Pro configured to pass the uninstall parameter. For details, see the procedure Adding a Script to Jamf Pro in Jamf Pro documentation.

ClosedPart Ⓕ — In Jamf Pro and on macOS computers: View certificate enrollment logs (optional)

ClosedView logs in Jamf Pro

During deployment, the Okta Device Registration Task publishes logs in Jamf at three log levels (INFO, WARN, ERROR). To diagnose deployment issues, Jamf administrators can view deployment logs on a policy or individual computer basis. In addition, end users can view log messages on their local macOS computers. 

ClosedView logs on macOS computers

You can watch and monitor Okta-related log messages during certificate enrollment. The method depends on the operating system running on the device.

If running version 10.11.6 (OS X El Capitan):


  1. Open Utilities > Console.
  2. Click All Messages.
  3. Type Okta in the search field and press Enter to filter all Okta-related messages.


If running either of these operating systems:

  • macOS 10.12.6 (Sierra)
  • macOS 10.13.4 (High Sierra)
  1. Open Utilities > Console.
  2. Click your device under Devices in the left pane.
  3. Type Okta in the search field and press Enter to filter all Okta-related messages.


To view past logs for all supported operating systems:

  1. Open Utilities > Console.
  2. Go to /var/log > asl in the left pane.
  3. Select the date you want to search on.
  4. Type Okta in the search field and press Enter to filter all Okta-related messages.


ClosedCaveats
  • Modern Authentication required for securing Microsoft Office apps — To secure Microsoft Office apps with this Device Trust solution they must be enabled to support Modern Authentication. For more information, see this Microsoft article. For information about securing Office 365 clients that use legacy protocols, see Office 365 Client Access Policies.

  • Device Trust is not supported with all versions of Microsoft Office thick clients — This Device Trust solution has been tested to work with Microsoft Office thick client versions 16.13.1 and 16.15. However, it does not work with Microsoft Office thick client version 16.14 (build 180610).

  • Prevent iCloud from transferring the Okta keychain to other Apple devices — To prevent iCloud from transferring the Okta keychain from DT-secured macOS devices to other Apple devices, Okta strongly recommends that you create a Configuration Profile in Jamf Pro that disables Allow iCloud Keychain syncing. (Note: Be aware that disabling syncing blocks all keychain transfers.) For details, see the Jamf Pro procedure in Part Ⓒ.

  • Webview must have access to the device keychain — Device Trust for managed macOS computers works with any SAML/WS-Fed-enabled app that supports authentication through a webview. The webview in which authentication is performed must have access to the Okta Keychain on the device. To prevent end users from being prompted for consent when the certificate is used in the authentication flow, Okta whitelists the following apps:

    • Box
    • Chrome
    • Safari
    • Microsoft Office
    • Skype for Business
    • Google Drive
  • Per-device enrollment limit — No macOS device can be enrolled in this Device Trust solution more than five times.

  • Ensure clients can complete the MTLS handshake — If your org implements endpoint protection software, make sure to configure it in a way that does not block the Mutual TLS certificate exchange (handshake) that occurs during this Device Trust flow. For details, see Prerequisites.

  • Shared-terminal scenarios are not supported — This Device Trust solution does not support shared-terminal scenarios in which multiple Okta end users log in to the same account from the same macOS workstation.
  • Device Trust enrollment not supported when Okta is read-only mode — Devices that you have targeted for this Device Trust solution cannot be enrolled in Device Trust if the cell in which your Okta org resides is in read-only modeA mode during which most administrative operations are disabled and a banner is displayed in the admin (not end-user) Dashboard. During read-only mode, all background jobs such as imports, OMM enrollment, OMM deprovisioning, and JIT provisioning are queued, and all are restarted when read-only mode is disabled..
  • End users may need to clear the browser cache — Some browsers (for example, Chrome) cache the Device Trust certificate. After the certificate is renewed automatically (once per year), these browsers may continue to present the expired certificate to Okta instead of the new certificate. In that case, end users are shown the Security requirements message and are denied access to Device Trust-secured apps. Okta recommends that you advise affected end users to clear browser cache by quitting and then restarting the browser (not just closing the browser window).
  • Device Trust-secured apps are shown as locked on end user Okta Home pages — On end-user Okta Home pages, a lock icon appears on all Device Trust-secured app chicletsThe "buttons" that appear on an end user's Home page and represent each application they wish to access through Okta. Clicking the chiclet allows the end user to instantly sign in and authenticate themselves into their chosen app. if (1) the device is not trusted, and (2) the end user tried to access any Device Trust-secured app from their Home page. The lock icon remains for the duration of the session.

ClosedKnown Issues
  • Security requirements page not shown when accessing O365 native apps — End users with unmanaged macOS devices are not shown the Security requirements page when they try to access Office O365 native apps secured by this Device Trust solution. (This problem occurs only with Office Native apps; it does not occur when trying to access O365 apps through desktop browsers like Chrome and Safari.) ClosedScreenshot

  • Problem accessing Google Backup and Sync app — When signing in to the Backup and Sync app (part of Google Drive), the authentication flow stops on the Google Account page instead of progressing to the app. Google is aware of this issue. To complete signing in, click the Sign in with your browser instead link in the lower portion of the page.

ClosedRelated topics

From Okta

Device Trust

Office 365 Client Access Policies

Configuring Microsoft Exchange ActiveSync (EAS)


External resources

Microsoft

How modern authentication works for Office 2013 and Office 2016 client apps

Office 365: Enable Modern Authentication

Updated Office 365 modern authentication

Office 2013 and Office 365 ProPlus modern authentication and client access filtering policies


Jamf Pro

Computer Extension Attributes

Introduction to Extension Attributes (video)

Managing Scripts

QuickStart Guide for Managing Computers 10.4.0

QuickStart Guide for Managing Mobile Devices 10.4.0

Jamf Pro Installation and Configuration Guide for Mac 10.4.0

Jamf Pro Administrator's Guide 10.4.0

Top

© Copyright 2018 Okta, Inc