Enterprise customers may integrate their Chrome OS devices into a Microsoft® Active Directory® (AD) environment. This integration joins devices to the AD domain. Users do not need Gaia identities; they sign in using their AD credentials. Admins manage sessions and push policies to users and devices from their AD servers using group policy. There is no need to synchronize users to Google.
Google Chrome Enterprise Help article
Google domains can either be set up for (regular) cloud management or AD management. If during enterprise enrollment a device is registered with a domain set up for AD management, the device management (DM) server replies with DeviceRegisterResponse::CHROME_AD, which turns the device into DEVICE_MODE_ENTERPRISE_AD. This mode gets written to install attributes. For devices in this mode we show an additional step for Active Directory® domain join.
If a device was joined to an AD domain, Chrome OS shows a custom dialog for user sign-in.
Chrome does not talk to the AD server directly. Instead, all communication, i.e. domain join, user auth, policy fetch, user status queries, Kerberos files queries, is relayed through the authpolicy system daemon.
Policies pulled from AD group policy objects (GPOs) have POLICY_SOURCE_ACTIVE_DIRECTORY, which translates to “Local Server” on the Chrome policy page. The conversion from GPO to protobuf happens in DevicePolicyEncoder and UserPolicyEncoder. Note that a protofiles uprev is necessary to get the latest policies.
The following Chrome classes are most relevant for the AD integration: AuthPolicyClient is the D-Bus client for the authpolicy daemon. All authpolicy D-Bus calls are routed through it. The AuthPolicyHelper is a thin abstraction layer on top of the AuthPolicyClient to handle cancellation and other stuff. The AuthPolicyCredentialsManager keeps track of user credential status, shows notifications if the Kerberos ticket expires and handles network connection changes. The ActiveDirectoryPolicyManager is the AD equivalent of the CloudPolicyManager and handles policy for AD-managed devices.
Users do not need a Google identity to sign in and Chrome is not signed in. Thus, no Google services are available by default unless the user signs in from the content area.
Moreover, users may sign up for a Play Store account from within their user session, see step 5 of the Help article. For this purpose, DM Server creates a LaForge account for the user. A LaForge account is a shadow Gaia account with scope limited to the Play Store. To prove the user's identity, a SAML flow is employed with DM Server as service provider and AD (or really any other) as identity provider. The SAML flow is triggered by ArcActiveDirectoryEnrollmentTokenFetcher.
See go/cros-ad-test-env for setting up an Active Directory® test environment.
See go/streamlinesteps to check out streamline domain join.