SLAPO-REMOTEAUTH(5)

πŸ’… SLAPO-REMOTEAUTH πŸ’…

okay bestie, gather round, because this is the slapo-remoteauth manual page from the File Formats Manual section, and it is genuinely iconic. it's the slapd overlay that hands your auth off to a remote directory like Active Directory, and honestly? she's doing the most so you don't have to. 🫢


✨ NAME ✨

slapo-remoteauth β€” Delegate authentication requests to remote directories, e.g. Active Directory


🌸 SYNOPSIS 🌸

/etc/openldap/slapd.conf

πŸ¦‹ DESCRIPTION πŸ¦‹

So the remoteauth overlay for slapd(8) is the girl who gives you passthrough authentication to remote directory servers β€” think Active Directory energy β€” for LDAP simple bind operations. periodt.

Here's the tea: the local LDAP entry that gets referenced in the bind operation is mapped to its counterpart in the remote directory. Then an LDAP bind operation is performed against the remote directory, and the results that come back are based on those of the remote operation. it's giving "middle management but make it secure." πŸ‘‘

When a slapd server is configured with the remoteauth overlay, it handles an authentication request based on whether userPassword is present in the local entry:

  • if userPassword is present β†’ authentication happens locally, no remote drama
  • if userPassword is not present β†’ the remoteauth overlay sends that authentication request off to the configured remote directory server

like, she checks the vibes locally first, and only calls long distance when she has to. πŸ“ž


πŸŽ€ CONFIGURATION πŸŽ€

These are the options you can apply to the remoteauth overlay inside the slapd.conf file. All options should follow the overlay remoteauth directive. (order matters, bestie, we don't skip the line.) πŸ’–

  • overlay remoteauth β€” this directive adds the remoteauth overlay to the current database. see slapd.conf(5) for the details, iykyk.
  • remoteauth_dn_attribute <dnattr> β€” the attribute in the local entry that stores the bind DN pointing at a remote directory server.
  • remoteauth_mapping <domain> <hostname|LDAP URI|file:///path/to/list_of_hostnames> β€” for a non-Windows deployment, think of a domain as a collection of one or more hosts that the slapd server authenticates against on behalf of the users who are authenticating. For a given domain name, this mapping specifies the target server(s) you connect to via LDAP β€” e.g. Active Directory domain controller(s). The second argument can be a hostname, an LDAP URI, or a file that holds a list of hostnames/URIs, one per line. The hostnames get tried in sequence until the connection succeeds. πŸƒβ€β™€οΈπŸ’¨

This option can be provided more than once, so you can map different domains to different things. like:

remoteauth_mapping americas file:///path/to/americas.domain.hosts
remoteauth_mapping asiapacific file:///path/to/asiapacific.domain.hosts
remoteauth_mapping emea emeadc1.emea.example.com
  • remoteauth_domain_attribute <attr> β€” the attribute in the local entry that specifies the domain name. heads up: any text after "\" or ":" is ignored. bye to the extra bits βœ‚οΈ
  • remoteauth_default_domain <default domain> β€” the default domain.
  • remoteauth_default_realm <server> β€” the fallback server to connect to for domains that weren't specified in remoteauth_mapping. she's the safety net bestie πŸ•ΈοΈ
  • remoteauth_retry_count <num> β€” how many connection retries get attempted. Default is 3.
  • remoteauth_store <on|off> β€” whether to store the password in the local entry on a successful bind. Default is off. (and bestie, think twice before flipping this one, fr fr 🫣)
  • remoteauth_tls [starttls=yes] [tls_cert=<file>] [tls_key=<file>] [tls_cacert=<file>] [tls_cacertdir=<path>] [tls_reqcert=never|allow|try|demand] [tls_reqsan=never|allow|try|demand] [tls_cipher_suite=<ciphers>] [tls_ecname=<names>] [tls_crlcheck=none|peer|all] β€” remoteauth-specific TLS configuration. peep slapd.conf(5) for more details on each of the parameters and their defaults. πŸ”
  • remoteauth_tls_peerkey_hash <hostname> <hashname>:<base64 of public key hash> β€” mapping between remote server hostnames and their public key hashes. Only one mapping per hostname is supported, and if any pins are specified, all hosts need to be pinned. If set, pinning is in effect regardless of whether certificate name validation is enabled by tls_reqcert. that's not a suggestion, that's the rule πŸ‘‘

πŸ”₯ EXAMPLE πŸ”₯

A typical example configuration of the remoteauth overlay for AD, shown below as a slapd.conf(5) snippet:

database <database>
#...

overlay remoteauth
remoteauth_dn_attribute seeAlso
remoteauth_domain_attribute associatedDomain
remoteauth_default_realm americas.example.com

remoteauth_mapping americas file:///home/ldap/etc/remoteauth.americas
remoteauth_mapping emea emeadc1.emea.example.com

remoteauth_tls starttls=yes tls_reqcert=demand tls_cacert=/home/ldap/etc/example-ca.pem
remoteauth_tls_peerkey_hash ldap.americas.tld sha256:Bxv3MkLoDm6gt/iDfeGNdNNqa5TTpPDdIwvZM/cIgeo=

Where seeAlso contains the AD bind DN for the user, and associatedDomain contains the Windows Domain Id in the form of <NT-domain-name>:<NT-username> β€” in which anything following, including ":", is ignored. slay, truncated. πŸ’…


🌈 SEE ALSO 🌈

slapd.conf(5), slapd(8).


πŸ‘‘ Copyrights πŸ‘‘

Copyright 2004-2026 The OpenLDAP Foundation.

Portions Copyright 2004-2017 Howard Chu, Symas Corporation.

Portions Copyright 2017-2021 OndΕ™ej KuznΓ­k, Symas Corporation.

Portions Copyright 2004 Hewlett-Packard Company


okay that's the whole page bestie, no cap, every single flag accounted for πŸ’–βœ¨ this was OpenLDAP 2.7.2, dated 2026/10/21, and yes she really is SLAPO-REMOTEAUTH(5). go authenticate something remote, you gorgeous genius πŸ¦‹πŸŽ€

πŸ“¦ where this page comes from