How to Configure Google Workspace Secure LDAP for Legacy Applications

The Authentication Gap

In a modern cloud-first enterprise, employees authenticate to everything (Salesforce, Slack, Zoom) using Google Workspace credentials via SAML or OIDC (OAuth 2.0). However, most corporate networks still harbor “legacy” infrastructure—on-premise VPN appliances (like Cisco AnyConnect or OpenVPN), ancient ERP systems, or local NAS drives—that absolutely cannot speak modern cloud protocols. They only know how to verify passwords using LDAP (Lightweight Directory Access Protocol), historically pointing to an on-premise Active Directory server.

If an organization wants to completely decommission their on-premise Active Directory servers and move 100% to Google Workspace, they face a critical roadblock: How do the legacy VPN routers authenticate users if there is no local LDAP server to talk to?

Google solved this by introducing Google Workspace Secure LDAP. This service acts as a virtual, cloud-hosted LDAP server. Your legacy on-premise appliances point their authentication queries directly to Google’s cloud via a highly secure, certificate-based TLS tunnel.

Step 1: Creating the Secure LDAP Client

You cannot simply point an appliance to Google and expect it to work. You must explicitly define and authorize the client within the Admin Console.

1. Log into the Google Workspace Admin Console.
2. Navigate to Apps > LDAP > Add Client.
3. Provide a descriptive name (e.g., “Cisco VPN Appliance”) and click Continue.

Step 2: Defining Access Permissions

You must strictly limit what the LDAP client is allowed to query. You do not want a VPN appliance to have the ability to read the passwords of the entire corporate directory.

1. Verify user credentials: Select Entire domain (or limit it to a specific Organizational Unit, like Engineering, if only they need VPN access).
2. Read user information: Limit this to Entire domain so the VPN can verify email addresses and names.
3. Click Add LDAP Client.

Step 3: Generating the Cryptographic Certificates

Because Google’s Secure LDAP service is exposed to the public internet, it does not allow connections via simple username/password binds. It strictly enforces mutually authenticated TLS (mTLS).

1. Upon creating the client, Google will prompt you to Download certificate.
2. Download the generated .zip file. It contains a digital certificate (.crt) and a private key (.key).
3. Store this securely. This certificate is the only way the legacy appliance will be allowed to communicate with Google’s LDAP endpoint.

Step 4: Configuring the Service Status

By default, the new LDAP client is turned off. You must enable it.

1. Click on the newly created client in the Admin Console.
2. Click the Service status panel.
3. Change it from “Off” to On for everyone and click Save.

Step 5: Configuring the Legacy Appliance

You must now log into the administrative interface of your legacy hardware (e.g., the Cisco VPN router) and configure its authentication settings.

• LDAP Server IP/Hostname: ldap.google.com
• Port: 636 (Strictly LDAPS / TLS). Port 389 is completely blocked by Google.
• Base DN: Your domain in LDAP format (e.g., if your domain is corp.com, the Base DN is dc=corp,dc=com).
• Authentication Method: Select Certificate-based authentication and upload the .crt and .key files you downloaded from Google in Step 3.

When an employee connects to the VPN and types their Google Workspace email and password, the Cisco router will encrypt the credentials, wrap them in the mTLS certificate, and send them to ldap.google.com:636. Google validates the certificate, verifies the password against the cloud directory, and returns an LDAP “Success” message to the router, granting the user access to the network without a single on-premise server involved.