Google Cloud Directory Sync (GCDS) Explained: What It Syncs and When You Need It
By Patronum
November 05, 2026
Read Time: 7 mins

By Patronum
November 05, 2026
Read Time: 7 mins

Google Cloud Directory Sync (GCDS) is a Google tool you install on your own server to copy users, groups, organizational units, shared contacts and calendar resources from Microsoft Active Directory or another LDAP directory into Google Workspace or Cloud Identity. The sync runs one way: Google says data on your LDAP server “is never updated or altered.” Active Directory passwords are usually handled by a separate tool, Password Sync, and Google now offers two cloud-based alternatives to GCDS: Directory Sync and Inbound SCIM.
GCDS makes your Google directory match your LDAP directory. On each run it exports objects from LDAP, compares them with your Google account, updates Google to match and emails you a report.
Three consequences surprise admins new to it:
| In your LDAP directory | Becomes in Google | Notes from Google’s documentation |
|---|---|---|
| Organizational units | Organizational units | Where users land depends on your OU sync rules |
| Users (including admins) | Users | Aliases sync as email aliases; phone numbers, addresses and other extended fields sync to the user profile |
| Mailing lists | Google Groups | GCDS manages only admin-created groups; it doesn’t sync security groups as security groups |
| Rooms | Calendar resources | |
| Contacts | Shared external contacts | Personal contacts aren’t synced |
| Passwords | Passwords | “Not all password formats are supported” |
Field mapping is a GCDS strength: up to 35 system attributes plus custom attributes, which matters if signatures or policies downstream rely on fields like department or job title.
Partly. Google’s FAQ says GCDS password settings mainly “define how GCDS creates passwords for new user accounts,” and it can sync some stored password formats, but not all.
For Active Directory, Google’s answer is Password Sync, a separate tool that keeps Google passwords matched to AD and “immediately pushes the change” when a user changes theirs. It’s one way, it must be installed on all domain controllers, and it needs Active Directory Domain Services (AD LDS isn’t supported).
So the usual on-premises pattern is GCDS for accounts, groups and OUs, plus Password Sync on the domain controllers. If users sign in through single sign-on, check whether Google passwords are used at all first.
From Google’s system requirements:
You set GCDS up in Configuration Manager, a step-by-step interface where you connect to Google and LDAP, write search rules for what to sync (at least one user rule is required), add exclusion rules, set up notifications, then simulate before running a real sync. Google is blunt about skipping the simulation: you could “accidentally delete an account or restrict a user.” Simulate again after every upgrade or configuration change.
Once a manual sync looks right, automate it with the command-line tool. Without -a, sync-cmd only simulates:
sync-cmd -c /path/gcds-config.xml
sync-cmd -a -c /path/gcds-config.xml
Schedule the second line with Task Scheduler on Windows or cron on Linux. Google says most automatic syncs run every 1 to 6 hours.
Most incidents involve accounts that exist in Google but not in LDAP. Google’s best practices:
Google’s comparison page covers three routes. Directory Sync is set up in the Admin console and is in public beta. Inbound SCIM, also cloud-based, takes users and groups pushed from any identity provider, HR system or custom app that supports SCIM 2.0; Google lists no OU mapping for it. The table compares GCDS and Directory Sync:
| GCDS | Directory Sync (beta) | |
|---|---|---|
| Install | On-premises software | None; runs in Google’s cloud |
| Sources | Any LDAP directory, including Active Directory and OpenLDAP | Active Directory and Entra ID (Google’s page says Azure AD) |
| Reaching on-premises AD | Runs on your network | Cloud VPN or Cloud Interconnect, or AD hosted on Compute Engine |
| What syncs | Users (including admins), groups, calendar resources, external contacts, passwords | Non-admin users and groups |
| Attribute mapping | Up to 35 system attributes plus custom attributes | First name, last name, email, recovery phone, recovery email |
| Schedule | You choose; needs your own scheduler | Full sync starts one hour after the previous one; fixed |
You can combine them: Directory Sync for users and groups, GCDS for objects like shared contacts. Google says that if you sync both users and groups, the same tool must handle both.
In short: Directory Sync suits Entra ID, or AD with an existing VPN to Google Cloud, when names and emails are enough. Inbound SCIM suits a SCIM-capable identity provider or HR system you already treat as the source of record, if you don’t need OUs mapped. GCDS fits when you need rich attributes, admin accounts, calendar resources or a non-Microsoft LDAP directory. For a wider view of provisioning routes, see our guide to Google Workspace user provisioning.
If Google is your only directory, and you create users in the Admin console, by CSV or through a provisioning tool, there’s nothing for GCDS to sync from. That covers most cloud-first small and mid-sized companies. Your job then is keeping the Google directory itself accurate, which we cover in why an accurate Google directory matters and how to build a company directory in Google Workspace.
GCDS decides who exists and where they sit. Patronum, a Google Workspace management tool, decides what happens to them next. Its policies read the Google Directory, including custom schema attributes, are scoped to all users, an organizational unit or a Google Group, and can be narrowed by conditions such as Department or Job Title. Once activated, they run hourly by default.
So a new starter GCDS creates in the Sales OU can fall into an onboarding policy for that OU, which manages group membership, shared calendars, Drive shortcuts and the Gmail signature. A job-title change in AD reaches the signature only after GCDS syncs it, the policy runs and Gmail picks it up, so don’t promise a fixed time.
Because GCDS undoes Google-side changes to data it manages, plan for three conflicts:
This chain suits planned changes only; a sync every few hours plus an hourly policy cycle adds up. For an urgent exit, follow the emergency offboarding process and coordinate the source-directory update at the same time: disable or move the user in AD straight away, and check that the next sync can’t undo the containment steps (for example by reactivating the account or restoring group memberships). Whether it could depends on your GCDS configuration.
Say a company runs Active Directory on-premises, users sign in to Google with AD passwords, and HR updates job titles in AD. A sensible setup:
The result to check: a test AD user with a department, job title and one synced group appears in the Admin console with all three after the first sync, and still has all three after a second sync. Then move them to the leavers OU in AD and confirm they land in the right Google OU. If anything reverts, fix the search rules before going live.