Si llegaste buscando información sobre OpenLDAP, Slapd y su backend meta, supongo que te topaste con uno de esos recovecos oscuros que se encuentran en toda infraestructura, robusto como un golem de barro y con una “completa” y críptica documentación que es la única defensa contra la ausencia de posteos de la comunidad con una antigüedad menor a los 10 años.

La idea de Slapd es funcionar como una interfaz LDAP que responde diferentes backends LDAP unificados y , en caso de ser necesario, reescritos. Por ejemplo, en mi caso la necesidad surgió por mantener diferentes dominios dentro del LDAP de Google Workspace (GW). En este caso, el dominio principal era example.com , pero también dentro de la misma cuenta de google mantenía algunos usuarios con correos que tenían dominio example.it o example.com.es. Ademas de esto estos usuarios dentro de estos dominios correspondían a Unidades Organizativas de GW. Los bindpaths originales para hacer una búsqueda en google de usuarios en estos dominios seria:

• 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

En las aplicaciones como por ejemplo Gitlab, cuando nos conectamos a un LDAP, tenemos que establecer un bindpath de busqueda y este es fijo y unico. Teniendo en cuenta que todos los clientes de LDAP leen estos paths de derecha a izquierda era necesario deshacerse de los TLD (.com, .it, .com.es).

En este caso utilice un Debian 12 para instalar el servidor de slapd que serviría como proxy entre los clientes y el LDAP de Google Workspace.

Instalamos los paquetes necesarios y creamos la estructura de directorios:

apt install slapd # nos va a pedir una password de manager que no usaremos luego.
mkdir -p /ldapcerts/ca 

Dentro de /ldapcerts colocaremos los certificados del cliente LDAP (example_slapd.key y example_slapd.crt) de Google Workspace y dentro de /ldapcerts/ca los certificados de Google (https://pki.goog/repository/) (con uno solo es suficiente)

El servicio de slapd que se implementa por defecto en debian 12 y la version actual, por lo poco que pude encontrar en internet, tienen el problema de no reconocer las variables tls_ que son necesarias para autenticar con el LDAP de Google Workspace (https://www.openldap.org/lists/openldap-technical/201302/msg00003.html), por lo que es necesario crear un nuevo script de inicio que se ejecute utilizando estas variables.

Creamos el script /etc/ldap/start-slapd.sh con permisos de ejecucion y con el siguiente contenido:

#!/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 

(Recomiendo cambiar el puerto por defecto para no exponer demasiado nuestro LDAP)

Luego creamos el archivo /lib/systemd/system/slapd-custom.service con el siguiente contenido:

[Unit]
Description=slapd custom

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

[Install]
WantedBy=multi-user.target

Desactivamos el servicio original de slapd:

systemctl disable slapd

Activamos el nuevo:

systemctl enable slapd-custom

Y por ultimo creamos el archivo /etc/ldap/slapd.conf que contiene toda la configuración del backend:

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  "<password_segura>"


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

## example.it 
uri             "ldaps://ldap.google.com/ou=officeB,ou=Users,dc=example"
suffixmassage   "ou=officeB,ou=Users,dc=example" "ou=officeB,ou=Users,dc=example,dc=it"
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

## example.com.es
uri             "ldaps://ldap.google.com/ou=officeC,ou=Users,dc=example"
suffixmassage   "ou=officeC,ou=Users,dc=example" "ou=officeC,ou=Users,dc=example,dc=com,dc=es"
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


#### re-escritura de atributos

#overlay rwm
#rwm-map attribute uid usuario

(En mi caso no utilizo ninguna re-escritura rwm pero dejo las opciones comentadas por si son útiles.)

Mi consejo es reiniciar el equipo para asegurarnos de que el script inicie correctamente por si solo, pero en caso de no poder hacerlo es necesario matar el proceso anterior de slapd que se inicia automáticamente cuando lo instalamos y ejecutar manualmente systemctl start slapd.

A esta altura ya podemos hacer consultas con un bindpath que solamente es ou=Users,dc=example

por ej:

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

Espero haberte ahorrado el martirio de tener que lidiar con OpenLDAP, Slapd y Google Workspace <3