Applies to managed Chrome browsers and ChromeOS devices.
As an admin, you can configure Chrome Enterprise device trust connectors to share context-aware signals from managed Chrome browsers, managed Chrome profiles and ChromeOS devices with third-party Identity Providers (IdPs). This integration allows device trust signals as inputs in authentication and authorization policies. This solution provides enhanced security and less dependence on the network as a trust factor.
Device signals include device ID, serial number, secure mode state, OS version, firewall status, and more. For more information, go to Data sent from Chrome to the IdP.
On all supported platforms, signals are shared from the browser in-session. For ChromeOS, signals are shared from both the browser in-session and the sign in page as part of user authentication.
Note: Chrome Enterprise device trust connectors are not supported on ChromeOS Flex.
Before you begin
You can use device trust connectors for managed devices—Chrome browser and ChromeOS—and for managed Chrome profiles on Chrome browser.
Chrome browser
- Sign up for Chrome Enterprise Core and enroll devices into the organizational unit where you want to configure the device trust connector. For information about getting started with Chrome Enterprise Core, go to Set up Chrome Enterprise Core.
- For unmanaged devices, you can configure the device trust connector for users with managed Chrome profiles based on their organizational unit. User consent is required on devices not managed by your organization. See User consent.
ChromeOS
- Sign up for Chrome Enterprise Upgrade and enroll ChromeOS devices into the organizational unit where you want to configure the device trust connector. For information about getting started with Chrome Enterprise Upgrade, go to About ChromeOS device management.
-
To enable signal sharing for the sign-in page only, add the devices to an organizational unit in which you want to configure the device trust connector.
-
To enable signal sharing for the sign-in page and for the browser in-session, you need to do one of the following:
- Add the devices and users to the same organizational unit in which you want to configure the device trust connector.
-
If devices and users are not in the same organizational unit, apply the same IdP configuration to all applicable organizational units. See Add new IdP configurations below.
Step 1: Add new IdP configurations
-
Sign in to your Google Admin console.
Sign in using your administrator account (does not end in @gmail.com).
-
In the Admin console, go to Menu
Devices
Chrome
- At the top, click + New provider configuration.
- In the panel that appears on the right, find the IdP that you want.
- Click Set up.
- Enter the configuration details. For information, see Provider configuration details below.
- (Optional) Select how you want to apply the configuration—Managed Browsers Only, Managed Profiles Only, or both Managed Browser and Profiles.
Note: This applies to Chrome browser only; it's always applied in ChromeOS. - Click Add configuration.
Configurations are added for your entire organization. Then, you can use them in any organizational unit, as needed.
Step 2: Apply settings to organizational unit
After you add a new (IdP) Identity Provider configuration, it's listed on the Connectors page. You can see the configurations that you added for each provider and the number of organizational units where it’s connected.
To choose which configuration to use:
-
In the Admin console, go to Menu
- Select a child organizational unit.
- For Device trust connectors, select the configuration that you want to use.
- Click Save.
Provider configuration details
Cisco Duo
| Field | Description |
|---|---|
|
Configuration name |
The name that’s shown on the Connectors page under Device trust connectors. |
|
URL patterns to allow, one per line |
Provided by Cisco Duo—Follow instructions in the Cisco Duo console. |
|
Services accounts, one per line |
Provided by Cisco Duo—Follow instructions in the Cisco Duo console. |
Refer to the guide below for details on setting up the integration between Chrome Device Trust Connector and Cisco Duo users.
Okta (Okta Identity Engine Users)
| Field | Description |
|---|---|
|
Configuration name |
The name that’s shown on the Connectors page under Device trust connectors. |
|
URL patterns to allow, one per line |
Provided by Okta—Follow instructions in the Okta console. |
|
Services accounts, one per line |
Provided by Okta—Follow instructions in the Okta console. |
Refer to the guide below for details on setting up the integration between Chrome Device Trust Connector and Okta Identity Engine users.
Omnissa
| Field | Description |
|---|---|
|
Configuration name |
The name that’s shown on the Connectors page under Device trust connectors. |
|
URL patterns to allow, one per line |
Provided by Omnissa—Follow instructions in the Omnissa console. |
|
Services accounts, one per line |
Provided by Omnissa—Follow instructions in the Omnissa console. |
Refer to the guide below for details on setting up the integration between Chrome Device Trust Connector and Omnissa users.
PingFederate
| Field | Description |
|---|---|
|
Configuration name |
The name that’s shown on the Connectors page under Device trust connectors. |
|
URL patterns to allow, one per line |
In the Ping Federate Console, navigate to System Protocol Settings Federation to determine the URL. |
|
Services accounts, one per line |
The service account is generated using GCP. The steps required to set up a GCP Project and Service Account are detailed in the Integrate Ping Identity with Chrome Enterprise guide below. |
Refer to the guide below for details on setting up the integration between Chrome Device Trust Connector and PingFederate users.
PingOne DaVinci
| Field | Description |
|---|---|
|
Configuration name |
The name that’s shown on the Connectors page under Device trust connectors. |
|
URL patterns to allow, one per line |
https://auth.pingone.com |
|
Services accounts, one per line |
The service account is generated using Google Cloud Platform (GCP). The steps required to set up a GCP Project and Service Account are detailed in the Integrate Ping Identity with Chrome Enterprise guide below. |
Refer to the guide below for details on setting up the integration between Chrome Device Trust Connector and Ping Identity for DaVinci users.
Verify device trust connector configuration
First, make sure that the managed device is enrolled and listed in the Google Admin console in an organizational unit where you configured the connector.
Verify that policies are applied
On a managed device:
- Navigate to chrome://policy.
- Click Reload policies.
- Windows and macOS only:
- For BrowserContextAwareAccessSignalsAllowlist, make sure that Status is set to OK.
- For BrowserContextAwareAccessSignalsAllowlist, click Show value and make sure that the value field is the same as what you set for URL patterns to allow, one per line.
- ChromeOS only:
- For DeviceLoginScreenContextAwareAccessSignalsAllowlist, make sure that Status is set to OK.
- For DeviceLoginScreenContextAwareAccessSignalsAllowlist, click Show value and make sure that the value field is the same as what you set for URL patterns to allow, one per line.
Check the state of device trust connector
On a managed browser or device:
- Navigate to chrome://connectors-internals.
- Check for these required values:
Is Enabled: trueKey Manager Initialized: trueKey Sync: Success (200)
The connector can only provide device identity attestation if the key synchronization was successful.
If there is no value next to Key Manager Initialized, refresh the page until a value appears. If Is Enabled: true, it shouldn't take more than a minute.
Note: ChromeOS devices do not have a Key Manager because they use TPM-backed certificates that are native to the OS.
Definition of values on chrome://connectors-internals
Is enabled:Verifies that the policy is enabled on the device.Key Manager Initialized:Chrome has loaded the key or created a key if no key was created already.Key Type:RSA or EC (Elliptic Curve).Trust Level:HW or SW.- HW (hardware) means that the key is stored in the device's hardware. For example, on Mac with Secure Enclave or Windows when a TPM is present.
- SW (software) means that the key is stored at the OS level. For example, in a file, like on Linux.
SPKI Hash:A hash of the private key.Key Sync:The response status + code from the latest attempted key upload. Chrome tries to re-upload the key every time it starts.Signals:An overview of the signals that can be sent from the device.
Clearing a context-aware access key
Windows and Mac only
Admins with access to the Admin Console can clear a trusted public key for a specific browser. This can help with troubleshooting if a user is experiencing access issues; such as a managed browser no longer having access to the trusted key pair.
-
Sign in to your Google Admin console.
Sign in using your administrator account (does not end in @gmail.com).
-
In the Admin console, go to Menu
If you signed up for Chrome Enterprise Core, go to Menu
Chrome browser
- Select the organizational unit where the browser is located.
- Select the browser with the key to clear.
- Under the Managed Browser details box on the left hand side, click Configure Key.
- Select Clear Key.
When the key is cleared from the Admin console, the managed browser synchronizes its key on restart and re-establishes trust again.
Note: If you cannot click Configure Key, the key might not exist on the server.
Data sent from Chrome to the IdP
Data sent from Chrome browsers and ChromeOS devices to the IdP is defined here. As an admin, you can decide which of these signals you want to use in the context-aware access rules.
User Consent
User consent is required on devices not managed by your organization. On unmanaged devices the browser asks the user to consent to the device posture being shared with your organization.
Google and related marks and logos are trademarks of Google LLC. All other company and product names are trademarks of the companies with which they are associated.