Learn LDAP - SASL & External Authentication

#Introduction

In episode 16 you installed TLS and promised to use it further. Episode 17 keeps that promise: SASL. The SASL framework enables authentication without sending passwords over the network — with Kerberos tickets via GSSAPI, or with client certificates via EXTERNAL. At the end of the episode, you'll see how this authentication connects to Linux systems through PAM, NSS, and SSSD.

#The SASL Framework

SASL (Simple Authentication and Security Layer) is an authentication abstraction layer placed on top of protocols like LDAP. Instead of writing authentication logic, applications pick a SASL mechanism available on the system:

• Pluggable authentication — mechanisms are installed as plugins; adding a new mechanism doesn't change the application.
• Mechanism selection — client and server negotiate the strongest mechanism both support.
• Security layers — beyond authentication, SASL can provide encryption and integrity for the connection itself.

In OpenLDAP, the available mechanisms depend on the libsasl2 package and loaded modules. The two most relevant for production are GSSAPI and EXTERNAL.

#SASL/GSSAPI (Kerberos)

GSSAPI bridges LDAP with Kerberos — the realm and tickets you know from the Kerberos series. The flow: a user obtains a TGT with kinit, then the LDAP bind uses a service ticket without ever touching a password.

What to prepare:

1. Service principal — the ldap/ldap.example.com principal on the KDC, with its password exported to a keytab.
2. Keytab configuration — the keytab is placed at /etc/krb5.keytab and read by slapd.
3. SASL server configuration in cn=config:

SASL configuration in cn=config

dn: cn=config
changetype: modify
replace: olcSaslHost
olcSaslHost: ldap.example.com
-
replace: olcSaslRealm
olcSaslRealm: EXAMPLE.COM
-
add: olcSaslSecProps
olcSaslSecProps: noanonymous,minssf=56

The client then authenticates with the GSSAPI mechanism:

kinit budi
ldapwhoami -x -H ldap://ldap.example.com -Y GSSAPI

The main benefit is SSO: once a user has a TGT, every Kerberos-enabled service never asks for a password again. Credentials also never flow over the network — what's sent is a ticket.

#SASL/EXTERNAL

SASL EXTERNAL takes its identity from a lower layer — the client certificate on a TLS connection, or the process identity on a Unix socket. This is what makes ldapmodify -Y EXTERNAL -H ldapi:/// work as a cn=config admin without a password.

When mutual TLS is enabled (with olcTLSVerifyClient: demand from episode 16), the server reads the subject DN from the client certificate and maps it to a directory entry. This mapping is configured with olcAuthzRegexp:

Mapping a certificate identity to a user DN

dn: cn=config
changetype: modify
add: olcAuthzRegexp
olcAuthzRegexp: "uid=([^,]+),.*" "uid=$1,ou=people,dc=example,dc=com"

With this mapping, a certificate issued to uid=budi automatically authenticates as uid=budi,ou=people,dc=example,dc=com:

ldapwhoami -Y EXTERNAL -H ldaps://ldap.example.com

Because the identity comes from a certificate verified by a CA, SASL EXTERNAL is very strong authentication — there's no password to steal. On the other hand, every user must hold a client certificate, which requires certificate distribution and rotation management.

#PAM and NSS Integration

LDAP authentication reaches the Linux system through two channels:

• pam_ldap — the PAM module (on Debian and Ubuntu via the libpam-ldapd package) that validates logins at the console, SSH, and other PAM applications.
• NSS integration — libnss-ldapd makes users and groups from LDAP visible to the system: getent passwd and ls -l show directory accounts as if they were local accounts.

Both are run on Debian by the nslcd daemon, which communicates LDAP to NSS and PAM:

/etc/nslcd.conf configuration

uid nslcd
gid nslcd
uri ldap://ldap.example.com
base dc=example,dc=com
ssl starttls
tls_cacertfile /etc/ssl/certs/ca.crt

• SSSD (System Security Services Daemon) — a modern alternative that combines authentication, offline caching, and failover handling in one daemon, configured at /etc/sssd/sssd.conf. For enterprise deployments, SSSD is generally more recommended than pam_ldap because of its caching and Kerberos support.

#LDAP Authentication for Other Systems

From those base channels, LDAP is used for many purposes:

• Linux login — console and TTY use pam_ldap or SSSD.
• SSH authentication — SSH inherits PAM, so SSH logins are authenticated too; for public keys, OpenSSH can load keys from LDAP via AuthorizedKeysCommand.
• Sudo rules — sudo rules are stored in LDAP with the sudo-ldap package; add sudoers: files ldap to /etc/nsswitch.conf and set the sudoers search base in the sudo configuration.
• Application authentication — web, mail, and other service applications bind to LDAP using a service account with restricted permissions, applying the least privilege from episode 15.

#Closing

In this episode 17 you understood SASL as a pluggable framework: mechanism selection and security layers; GSSAPI integration with Kerberos from service principal, keytab, to passwordless SSO; SASL EXTERNAL using client certificates and identity mapping via olcAuthzRegexp; then system integration with pam_ldap, NSS, and SSSD; and application to Linux login, SSH, sudo, and applications.

Key takeaways:

• GSSAPI is SSO — passwords never cross the network; tickets do the talking.
• EXTERNAL uses a lower layer — certificates or Unix sockets, and olcAuthzRegexp bridges the identity to a DN.
• PAM and NSS are the bridges to the system — pam_ldap validates logins, NSS makes LDAP users visible to the system.
• Start small, expand slowly — verify each layer before connecting SSH and sudo.

In the next episode, episode 18, we close the security phase with audit logging & monitoring — slapd log levels, log rotation, and analysis to detect anomalies. The authentication infrastructure you've built since episode 12 is now ready to be monitored properly.