This article will explore how to deploy device management to shared workstations.
- A Shared Workstation is defined as a Desktop Operating System in which individual users sign in to perform tasks separately. Each unique login accesses the computer with its profile and registers its Okta account using the locally installed Okta Verify app on the Desktop.
- Kiosk-style workstations, where multiple individuals use a shared single account to access the workstation, are not supported.
- Okta Identity Engine (OIE)
- Device Management Attestation (Device Trust in OIE)
- Mobile Device Manager (MDM)
The instructions in the manual chapter Configure management attestation for desktop devices often only provide steps for setting up users on dedicated workstations. When multiple user accounts share a single workstation, these instructions will result in only the first user logged in getting a device management certificate from the SCEP profile deployment and showing managed, while all others will not.
- For scenarios where the device is used by a single user, such as an employee laptop, User is the best option, as it ensures that only the designated user will have access to the cert/key.
- For scenarios where the device may be shared between multiple unique users, administrators must deploy to the "Device" to ensure each user is managed on the device.
To configure Device Management for a shared workstation, Okta recommends modifying the SCEP Profile configuration in the Mobile Device Manager (MDM) to deploy the certificate to the Local Machine (Windows) or System Keystore (Mac).
- NOTE: Deploying SCEP Device Management Certificates to the Device/Machine cert store for Windows OS introduces permissions complexity, see below for details.
- Known Issue: Some MDMs will deploy to the TPM by default, and cause issues setting permissions to the cert private key. This is discussed in Device Not Showing Managed When SCEP Profile Certificate Deployed To Machine Store.
- In this instance, change the Key Location to "Software" to store the private key in the device OS.
- Known Issue: Some MDMs will deploy to the TPM by default, and cause issues setting permissions to the cert private key. This is discussed in Device Not Showing Managed When SCEP Profile Certificate Deployed To Machine Store.
Configuring SCEP Profile for Device
For example, in Microsoft MEM (Microsft Endpoint Manager) (Formerly Intune), see Task 5.
In the MDM, under Certificate type, select Device:
To understand the details of this option and learn more about deploying SCEP Configuration Profiles in MEM, see Create and assign SCEP certificate profiles in Intune documentation.
This is defined when configuring the Certificate Template in Workspace One. For reference, see the section "Configuring a Credentials Profile" in VMWare's manual for Workspace One.
The same concept applies across MDMs; Administrators will configure the SCEP profile for the certificate to deploy to the Machine/System store/keychain instead of a personal store.
NOTE:
- Over 5 simultaneous users logged into a shared workstation could cause Okta Verify to experience port exhaustion. This can produce an errant user experience and behavior for FastPass logins, which may prevent users from being able to authenticate.
- By default, the manual advises a Subject name format that identifies the certificate by User Name. For example,
CN={{UserPrincipalName}}managementAttestation {{DeviceId}}.- Okta does not require the subject name to be in any particular format; it is just populated.
- As a best practice, administrators may use profile variables provided by the MDM to configure the certificate with unique identifiers. For a System Certificate, it may make more sense to Okta and MDM admins to configure a Common Name that Identifies the unique machine the certificate will deploy to, as opposed to an email or username identifier (such as UserPrincipalName).
- For specific examples, reference the specific MDM documentation, as advised in the Okta Manual under the "Configure A Certificate Authority" list (reference the specific MDM) in the Configuration Workflow portion of the manual.
- For specific examples, reference the specific MDM documentation, as advised in the Okta Manual under the "Configure A Certificate Authority" list (reference the specific MDM) in the Configuration Workflow portion of the manual.
Permissions settings for the management certificate Private Key
This is usually only required for Windows OS, but may need to be verified for macOS in rare instances. Once the profile is configured to deploy to the "Device" Or "Machine", administrators must ensure that all users logging into the shared workstation can access the machine certificate's private key for devices to register as managed.
To set permissions in Windows:
-
Click the Windows Key or the Windows Logo Start button, and type "Manage Computer Certificates".
- In the Certificate Manager, under Local Machine: Personal > Certificates.
- Right-click the Okta SCEP Device Management Certificate > All Tasks > Manage Private Keys.
-
This creates a standard Windows permissions window where admins can add permissions for users and/or groups.
-
Assign (Add... button) each user who needs device management Read permissions. This may include groups.
NOTE: For Mac Operating Systems, permission issues are not commonly a concern requiring intervention, as with Windows. However, these permissions can be reviewed by:
-
In Finder > Applications > Utilities > Keychain Access.app.
-
In the Keychain Access utility, choose the System folder under the System Keychains.
-
Identify the Cert and Corresponding Private Key deployed to the device for device management, right-click the Private Key, and select Get Info.
-
On the Access Control tab, the Private Key should be set to Allow all applications to access this item.
