In a previous post I expanded on Google’s suggestion to use stunnel to proxy queries to Google’s LDAP (and any other LDAP server of course, including AD). The problem with this approach is that it does not offer much for debugging if things go wrong. And since we do not control the receiving end of the queries, that makes us fly blind. Wouldn’t it be better if there was a more LDAP aware proxy server of some kind to use instead.
It turns out there is one: lloadd, the stand-alone LDAP daemon by the OpenLDAP project. It listens for LDAP connections on any number of ports (default 389), forwarding the LDAP operations it receives over these connections to be handled by the configured backends. Curiously it seems not to come with the slapd/openldap packages available for Ubuntu 22.04, so I had to compile it from the source:
./configure --prefix=/opt/ldap --enable-balancer --with-tls
make depend
make
sudo make install
You can now find the daemon sitting on /opt/ldap/libexec/lloadd. Let’s see how we can use it now. It requires a configuration file:
# /opt/ldap/etc/openldap/lloadd.conf
feature proxyauthz
bindconf
bindmethod=simple
binddn=UserNameFromGoogleLDAP
credentials=PasswordFromGoogleLDAP
tls_key=/opt/ldap/etc/openldap/Google_123456.key
tls_cert=/opt/ldap/etc/openldap/Google_123456.crt
tier roundrobin
backend-server
uri=ldaps://ldap.google.com:636
numconns=3
bindconns=2
retry=5000
max-pending-ops=5
conn-max-pending=3
starttls=yes
The above configuration connects to Google’s LDAP using the key/cert pair and username / password obtained from admin.google.com for your Workspace. Note how we (ab)use the roundrobin tier with just one backend to proxy instead of loadbalancing between multiple servers.
We now need to run the daemon, so we use the following systemd file
# /etc/systemd/system/lloadd.service
[Unit]
Description=lloadd
[Service]
User=nobody
WorkingDirectory=/tmp
ExecStart=/opt/ldap/libexec/lloadd -4 -f /opt/ldap/etc/openldap/lloadd.conf -h ldap://127.0.0.1:1389 -d stats
[Install]
WantedBy=multi-user.target
Using the above after sudo systemctl daemon-reload and systemctl start lloadd we have an LDAP proxy listening in 127.0.0.1:1389 and by adjusting the loglevel (either in the configuration file, or in the command line) we can achieve more visibility.
Again, thanks for sharing this.
The process of looking at documentation, and have the ability to easily compile from source and test things, is something that comes by default for sysadmins of our generation.
But I wonder, how many younger people these days would do the same? Please, surprise me pleasantly!
Only a few I think would be interested in `./configure` and the like. The ones with an interest to produce a docker image