The Windows Google SSO Policy configures Google sign-in on company-owned Windows devices through Google Credential Provider for Windows (GCPW). Employees use their work or school Google Account to sign in to Windows, while administrators configure permitted domains, offline access, multi-user sign-in, and Windows profile associations through Swif.

This policy supports Windows device sign-in. Signing in to the Swif dashboard with Google is a separate integration.

Use currently serviced Windows and Chrome releases. The minimums above describe GCPW compatibility, not recommended software versions.

Compatibility note: Google's installation guide currently states that GCPW is not compatible with third-party MDM providers. Swif provides this integration, but that does not establish Google support for the combined deployment. Validate it with Swif Support and a pilot group. Disabling Google automatic device-management enrollment avoids requesting that enrollment; it does not remove Google's broader compatibility limitation. See Google's GCPW installation requirements.

GCPW adds Google authentication to the Windows sign-in experience. Depending on the account configuration, first sign-in can create a new Windows profile or associate the Google Account with an existing profile.

Plan which outcome you want before employees sign in:

Profile association preserves access to the selected profile; it is not a tool for merging two profiles or moving data between computers. Google also documents a separate Directory-attribute association method for local and Active Directory accounts. See Associate Google accounts with existing Windows profiles.

The additional settings appear when Enable Google SSO is enabled.

Choose important values explicitly. An omitted field should not be treated as proof that an existing registry value or Google Admin setting has been cleared.

Enables or disables the Google SSO integration managed by this policy.

Enable it to configure the remaining options. Before disabling it on a production device, verify an alternative sign-in method. The supplied policy definition does not specify whether disabling the integration uninstalls GCPW or removes existing account associations.

Enter the GCPW enrollment token from your organization's Google Admin console:

The token associates GCPW with your organization's Admin-console configuration. It is not an employee password or a Swif enrollment code. Keep it out of public screenshots and support logs.

Token-based GCPW configuration and automatic Google Windows device-management enrollment are separate functions. A token does not require you to enable the latter.

Specify which domains are permitted to use Google SSO for Windows login. This ensures that only authorized users from your organization can log in.

Controls automatic enrollment into Google's Windows device management when a user first signs in through GCPW.

This setting does not enroll the device in Swif.

For a deployment intended to remain managed by Swif, explicitly set this to Disabled and review the effective Google Admin setting as well. Do not assume leaving the field at its enabled default is appropriate for an already managed device.

Google management has separate licensing and enrollment requirements. Disabling automatic enrollment also should not be treated as unenrolling a device that is already enrolled.

Sets how long users may sign in through GCPW offline before online authentication is required.

The Swif field accepts values of zero or greater. Select a period that accommodates travel, unreliable connectivity, and your account-verification requirements.

This is not a screen-lock timeout or a guarantee that every Windows unlock will perform Google authentication. Test online, offline, password, and Windows Hello flows used in your environment.

Controls whether multiple Google Workspace accounts can sign in to the device through GCPW.

This does not configure Windows Fast User Switching or delete existing accounts. If Google's Windows device management is used, only one user can be enrolled in that management per device even when multiple GCPW users are allowed.

Controls the Windows account name generated when GCPW creates a new profile.

For example, the shorter-name option uses alex as the naming basis for alex@example.com.

This setting is for new profiles. It does not rename an existing Windows account or profile folder. Consider collisions when different permitted domains have users with the same email prefix.

Associates a Google work or school account with an existing local Windows profile so the user can begin using GCPW without selecting Add Work Account for that first association.

Each mapping requires:

The mapping sets:

To find the current user's SID, run this command while signed in as that employee:

Check the execution context: Running this through a remote command as SYSTEM or another administrator returns that account's SID, not the employee's. Verify the account name and target device before adding the mapping.

Keep SID mappings scoped to the correct devices. Do not assign one employee's device-specific mapping to an organization-wide group. Do not associate an employee with a shared administrator or service account.

Google Admin-console GCPW settings override corresponding registry settings when both are configured. If Swif is intended to manage a setting locally, leave the matching Google setting Not configured where available and verify the resulting value.

Permitted domains can also be maintained in Google under GCPW setup > Permitted domains. Allow up to an hour for Google's GCPW settings to synchronize. This is separate from the device receiving its Swif policy. See Google's configuration instructions.

For shared devices, enable multi-user login and test each intended account. These are deployment suggestions, not Swif defaults or a guarantee of compatibility.

At the Windows sign-in screen, use the Google sign-in option. An unmapped first-time user may need to select Add Work Account. Enter the work or school Google email and complete authentication, including any applicable Google 2-Step Verification challenge.

Google confirms that GCPW supports 2-Step Verification, but not passwordless Google sign-ins. Do not describe this policy as requiring a new MFA challenge on every unlock. See Google's GCPW FAQ.

After sign-in, confirm the expected desktop, files, and account permissions. A successful Google authentication alone does not prove the correct Windows profile was selected.

The existing Swif guide describes a GCPW helper account, such as gaia, and a Windows user associated with the employee's Google account. Account counts depend on existing-profile associations and the number of users. Do not assume deployment always creates exactly two new accounts.

Do not remove a GCPW helper account solely because it is unfamiliar. Also verify the employee's actual group membership rather than assuming this SSO policy makes every account a standard user. An existing profile can retain permissions that require separate management.

Use a read-only registry inspection for relevant settings if troubleshooting. Avoid exporting the entire GCPW registry tree into a ticket because it can contain tokens and account information.

Check policy application, GCPW installation, supported Windows edition and architecture, and Chrome availability. Restart after saving work if installation requires it. Review other credential providers and Windows Logon Policy settings that may affect the sign-in interface.

Verify the domain spelling, the effective permitted-domain list, and Google Admin overrides. If managing domains from Google, check the token and allow time for synchronization.

Stop before moving or deleting files. Compare the signed-in account with the intended existing account, then verify the SID, email, and policy target. A missing or incorrect association can result in a separate profile. Shorter account names do not merge profiles.

Check the effective offline validity period and whether the user has completed initial online authentication. A value of 0 or an expired offline allowance requires connectivity. Review Google Admin settings as well as the Swif value.

Check Enable Device Management Enrollment, existing enrollment, Google licensing, and Google Admin overrides. For the intended Swif-managed configuration, verify that automatic Google enrollment is disabled. Escalate unresolved compatibility issues to Swif Support; do not remove a working MDM enrollment as an unplanned troubleshooting step.

Verify whether the Google and Windows passwords are synchronized and follow the GCPW prompts. Password changes made through another tool can require reconciliation. Avoid repeatedly resetting passwords through different systems. Review Google's profile association guidance and use your approved account recovery process.

Check internet access before Windows sign-in, proxy requirements, device time, and Google endpoint reachability. Use the current proxy endpoint list in Google's GCPW FAQ rather than assuming access to Gmail alone is sufficient.

Before changing domains, profile associations, or disabling SSO, confirm that affected employees and administrators can still sign in.

Deploy changes to a test device, review the effective configuration, and test after restart. Removing the policy should not be assumed to uninstall GCPW, delete Google or Windows accounts, restore earlier registry values, or remove an existing Google management enrollment. Plan those actions separately when required.