Okta Secure Web Authentication Plug-in is a convenient browser extension that is designed with the end user in mind while empowering admins with the best in class single sign-on security.
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.Here's how SAML works through Okta:SP-initiated flow: the end user requests (principally through a browser) a service from the SP. The SP requests and obtains an identity assertion from the IdP (in this case, Okta). On the basis of this assertion, the SP can decide whether or not to authorize or authenticate the service for the end user.IdP-initiated flow: with Okta as the IdP, an end user goes to the Okta browser and clicks on a chiclet, sending a SAMLResponse to the configured SP. A session is established with the SP, and the end user is authenticated. and WS-Fed cloud apps. Device Trust ensures that only known and secured devices can access your Okta-managed applications.
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:
The Okta Device Registration Task is a script that is distributed by Jamf Pro 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:
Okta Client For Mac
Create the workflows that make sense for your organization, making sure that the script runs at least once successfully to enroll the Okta certificate.
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 selectable unless you deselect the following options in the Client section Screenshot:
To configure more granular access to the app, selectively apply conditions as you create one or more prioritized rules based on:
For important information about creating Sign On policy rules, see Add Sign On policies for applications.
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.
Whitelist exampleExample Rule 1 â Exchange ActiveSync; All platforms; Any trust; Allow access
CONDITIONS
ACTIONS
CONDITIONS
ACTIONS
CONDITIONS
ACTIONS
CONDITIONS
ACTIONS
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.
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.
Click: Important to know before you begin
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. To generate more granular logs, use the verbose option as the Parameter Value in Jamf Pro. Screenshot
In addition, end users can view log messages on their local macOS computers by having the Console app open while the script runs on their computer.
View 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):
If running either of these operating systems:
To view past logs for all supported operating systems:
To see the system calls executed on the device, run the following command and then execute the Device Registration Task:
The Okta Device Registration Task whitelists some popular apps by default so that end users aren't prompted for the keychain password when trying to access them. You can customize the default whitelist as described in this procedure.
Click: Important to know before you begin
Best practice â Keep a copy of your preferred whitelist. Your modified whitelist is overwritten whenever you push a new Okta Device Registration Task to your targeted macOS computers, so you'll have to recreate it.
The Okta Device Registration Task is a python script that you obtain from Okta, modify, and then upload to Jamf Pro for distribution to the macOS devices you have targeted for this Device Trust solution. More.
When deployed on the device, the Okta Device Registration Task does the following:
Okta Verify
The two problems that you are most likely to encounter are:
If you encounter either problem, try to correct it by performing Basic Troubleshooting. If the problem persists, perform Advanced Troubleshooting.
To perform basic troubleshooting, review the following areas:
Enablement
Verify the following:
Verify that you have correctly configured Jamf Pro to distribute the Device Registration Task to targeted macOS devices as detailed in Part C.
You can use the following query to determine which version of the Registration Task is running on the device:
python ~/Library/Okta/okta_device_trust.py version
Certificate
Verify that the certificate is installed
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 in your App Sign On Policy, 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).
To verify installation from a terminal:
Show keychain infoShow the certificate
security find-certificate -a -c 'Okta MTLS' -Z -p okta.keychain
Show the passwordFtp Client For MacTo verify installation through the GUI on targeted devices:
Prevent an auth failure caused by blocked Mutual TLS certificate exchange
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 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 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:
Sign On Policy
Verify that you have configured a Sign On Policy that:
Verify Device Trust events
Review the System Log to verify the following Device Trust System Log events:
Authentication
Enrollment
Issuance
Revocation
Renewal
View unique device IDs in DebugContext
DebugData shows the unique ID of the devices associated with Device Trust events and is useful for debugging purposes. This information can also help you verify that Device Trust is being enforced on devices in your device inventory, which may be useful prior to rolling out the feature to a large group of users.
Important: The information contained in debugContext.debugData is intended to add context when troubleshooting customer platform issues. Note that key names and values are subject to change without notice and should be used primarily as a debugging aid, not as a data contract. For more about the DebugContext, see the DebugContext Object in Okta Developer documentation.
If Basic Troubleshooting did not resolve the problem you are experiencing, and the certificate is not installed on the macOS device, check in the following locations:
In the Okta Admin app
Verify that the end user of the macOS device is present and Activated in Directory > People.
On the macOS device
Confirm that auto certificate settings are configured in Chrome:
Verify that native apps are whitelisted in the keychain![]()
Issue the following command to verify that whitelisted appsMicrosoft Office 365, Box, Google Drive, Skype for Business, Slack (Part G) can access the certificate: Screenshot
Validate remediation
Try to access a Device Trust-secured app from a browser or thick client. If an error displays while trying to access the app, Quit and Close the browser (Chrome or Safari), then relaunch the browser and try to access the app again.
Caveats
From OktaExternal resources
Microsoft
Jamf Pro
Top
If you are working in a managed IT environment and remotely installing the browser plugin to managed computers, you can install the plugin silently using policy settings. During silent installation, no dialog boxes appear that require user interaction and users cannot change the installation settings. See the procedure below appropriate for your browser.
Note: Currently, Microsoft Edge and Safari browsers do not support silent installation of extensions such as the Okta browser plugin.
Internet ExplorerInstallation options
You have several installation options when installing the Okta browser plugin 5.x for IE. The following chart may help you choose the best options for your environment.
This procedure has two parts:
Part ⶠâ Enable Silent Mode
Note: If you're installing in silent mode on Windows 7, users are prompted to restart their browsers.
Configure whitelisting to suppress the appearance of the Choose add-ons button during the plugin installation so that end users cannot interfere with the installation.
For a Windows OS, Internet Explorer uses a CLSID (class identifier) to set the whitelisting policy. To set this policy on your system, do the following:
Now users are not prompted to enable or disable the plugin installation process during silent installation.
Chrome
For more information, see the Google article Install Chrome extensions via group policy or master_preferences
Firefox
For more information on Firefox extensions, see https://developer.mozilla.org/en-US/docs/Installing_extensions.
Top
Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |