Slapd (meta backend openldap) and Google Workspace

Organizing an LDAP directory in Google Workspace with Slapd (meta backend openldap)

If you came here looking for information about OpenLDAP, Slapd, and its meta backend, I assume you’ve encountered one of those obscure corners that exist in every infrastructure—robust like a clay golem, with “comprehensive” and cryptic documentation that’s your only shield against a lack of community posts less than a decade old.

The idea of Slapd is to act as an LDAP interface responding to multiple unified backends, which can also be rewritten if necessary. For example, in my case, the need arose to manage multiple domains within Google Workspace (GW) LDAP. In this instance, the primary domain was example.com, but within the same Google account, I also maintained some users with emails using the example.it or example.com.es domains. Furthermore, users within these domains belonged to specific Organizational Units (OUs) in GW. The original bind paths for searching users in these domains would be:

  • ou=officeA,ou=Users,dc=example,dc=com
  • ou=officeB,ou=Users,dc=example,dc=it
  • ou=officeC,ou=Users,dc=example,dc=com,dc=es

In applications like GitLab, when connecting to LDAP, we need to set a single fixed bind path. Considering all LDAP clients read these paths from right to left, it became necessary to get rid of the TLDs (.com, .it, .com.es).

For this, I used Debian 12 to install the Slapd server that would act as a proxy between the clients and Google Workspace LDAP.

We install the required packages and create the directory structure:

apt install slapd # It will prompt for a manager password, which won’t be used later.
mkdir -p /ldapcerts/ca 

Place the LDAP client certificates (example_slapd.key and example_slapd.crt) for Google Workspace in /ldapcerts. In /ldapcerts/ca, place Google’s certificates (https://pki.goog/repository/)—just one is sufficient.

The slapd service implemented by default on Debian 12 and the current version, based on my limited findings online, has an issue where it doesn’t recognize the tls_ variables required to authenticate with Google Workspace LDAP (source). Therefore, we need to create a new startup script that includes these variables.

Create the /etc/ldap/start-slapd.sh script, make it executable, and include the following content:

#!/bin/bash 

LDAPTLS_CERT="/ldapcerts/example_slapd.crt" LDAPTLS_KEY="/ldapcerts/example_slapd.key" LDAPTLS_CACERT="/ldapcerts/ca/r1.pem" LDAPTLS_CACERTDOR="/etc/ssl/certs" /usr/sbin/slapd -h ldap://:389/ -f /etc/ldap/slapd.conf -d1 

(I recommend changing the default port to avoid exposing your LDAP too much.)

Next, create the /lib/systemd/system/slapd-custom.service file with the following content:

[Unit]
Description=slapd custom

[Service]
ExecStart=/etc/ldap/start-slapd.sh
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

Disable the original slapd service:

systemctl disable slapd

Enable the new one:

systemctl enable slapd-custom

Finally, create the /etc/ldap/slapd.conf file with the following backend configuration:

include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/nis.schema

modulepath 	/usr/lib/ldap
moduleload 	back_meta.la
moduleload  back_ldap.la
moduleload	rwm.la

database meta

suffix	"dc=example"
rootdn	"cn=slapd,dc=example"
rootpw  "<secure_password>"

rebind-as-user yes

## example.com 
uri             "ldaps://ldap.google.com/ou=officeA,ou=Users,dc=example"
suffixmassage   "ou=officeA,ou=Users,dc=example" "ou=officeA,ou=Users,dc=example,dc=com"
lastmod  off
readonly on
timeout 360
idassert-bind   bindmethod=sasl
	       saslmech=external
	       flags=override
	       tls_cert=/ldapcerts/example_slapd.crt 
	       tls_key=/ldapcerts/example_slapd.key 
	       tls_cacert=/ldapcerts/ca/r1.pem 
	       tls_cacertdir=/etc/ssl/certs

## Repeat for example.it and example.com.es as shown in the original content.

Note: Restart the server to ensure the script starts correctly. Alternatively, kill the default slapd process and manually run systemctl start slapd.

You can now query using a simplified bind path such as:

  • ou=officeA,ou=Users,dc=example
  • ou=officeB,ou=Users,dc=example
  • ou=officeC,ou=Users,dc=example

I hope this saves you the torment of dealing with OpenLDAP, Slapd, and Google Workspace <3.

(Translated using ChatGPT)