Patronum Logo
00%
Patronum Logo
menu-icon

Google Cloud Directory Sync (GCDS) Explained: What It Syncs and When You Need It

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.

What does GCDS do?

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:

  • LDAP is the source of truth. Edit a synced field in the Admin console and GCDS treats it as a mismatch. Google’s FAQ: “If the data doesn’t match, GCDS undoes the change made in the Google Account.”
  • It only moves identity data. GCDS “doesn’t migrate any content (such as email messages, calendar events, or files).”
  • It runs on your network. It’s on-premises software, though it doesn’t need to run on the LDAP server itself.

What does GCDS sync?

In your LDAP directoryBecomes in GoogleNotes from Google’s documentation
Organizational unitsOrganizational unitsWhere users land depends on your OU sync rules
Users (including admins)UsersAliases sync as email aliases; phone numbers, addresses and other extended fields sync to the user profile
Mailing listsGoogle GroupsGCDS manages only admin-created groups; it doesn’t sync security groups as security groups
RoomsCalendar resources
ContactsShared external contactsPersonal contacts aren’t synced
PasswordsPasswords“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.

Does GCDS sync passwords? GCDS vs Password Sync

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.

What do you need to run GCDS?

From Google’s system requirements:

  • A server: Windows or Linux. Google’s supported list goes back to Windows 7 and Server 2008, but that’s compatibility, not advice: use a current, patched OS. On Linux you need a graphical interface on the GCDS server or access to another server with one.
  • Recommended hardware: 2 cores, 5 GB of disk for logs and data, and 1 GB of free RAM under 10,000 users, groups, members, OUs and contacts, rising to 8 GB over 200,000.
  • Network: ports 80 and 443 open to Google, directly or through a proxy, plus port 25, 465 or 587 for notification emails.
  • Accounts: an LDAP admin with read access to the OUs you sync, and a Google super administrator. Microsoft Entra ID (formerly Azure AD) isn’t supported as a source; Google points Entra ID tenants to Directory Sync.

How does a GCDS sync work?

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.

What can go wrong with GCDS?

Most incidents involve accounts that exist in Google but not in LDAP. Google’s best practices:

  • Protect Google-only accounts and groups with exclusion rules, or GCDS will treat them as leftovers. “Why is my Google Workspace user account being suspended after I run GCDS?” is a question in Google’s own FAQ.
  • Suspend, don’t delete, users missing from LDAP. Deleted accounts can’t be retrieved after 20 days; suspended accounts keep their data.
  • Set delete limits that fit your account size, so one bad search rule can’t remove half your groups.
  • Treat the server as sensitive. Credentials in the XML configuration are encrypted, but someone with access to the machine can get both the file and the key.

GCDS vs Directory Sync vs Inbound SCIM: which should you use?

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:

GCDSDirectory Sync (beta)
InstallOn-premises softwareNone; runs in Google’s cloud
SourcesAny LDAP directory, including Active Directory and OpenLDAPActive Directory and Entra ID (Google’s page says Azure AD)
Reaching on-premises ADRuns on your networkCloud VPN or Cloud Interconnect, or AD hosted on Compute Engine
What syncsUsers (including admins), groups, calendar resources, external contacts, passwordsNon-admin users and groups
Attribute mappingUp to 35 system attributes plus custom attributesFirst name, last name, email, recovery phone, recovery email
ScheduleYou choose; needs your own schedulerFull 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.

When don’t you need GCDS?

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.

Where Patronum fits once your directory syncs

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:

  • OUs. Make offboarding moves in AD and scope the offboarding policy to the matching Google OU. That works only if your GCDS search rules and OU mapping cover that AD OU.
  • Profile fields. If a policy edits a field GCDS also syncs, the next sync may reverse it.
  • Group memberships. If a policy changes members of a group GCDS manages, pick one source of authority per group (for example, exclude it from GCDS), or the two may undo each other. Check this in your configuration before going live.

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.

Applying it: a 400-person company with Active Directory

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:

  1. GCDS on a server next to AD, simulating every config change, syncing users every two hours and contacts nightly.
  2. Password Sync on every domain controller.
  3. Exclusion rules for Google-only accounts and groups, and “suspend, don’t delete” for missing users.
  4. A leavers OU in AD with a GCDS rule mapping it to a Google OU, for planned exits only.
  5. Directory Sync rejected for now: it would drop the job-title and department mapping the signatures depend on.

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.

Sources