Pass-Through authentication with remoteauth overlay

Presentation

Pass-Through authentication is a mechanism used by some LDAP directories to delegate authentication operations (BIND) to other backends.

It should be distinguished from the external authentication methods, that are managed by the LDAP client to authenticate on a trusted source and then connect to the directory.

Pass-Through authentication is purely transparent for LDAP clients, as they send standard authentication operations to the LDAP directory, which will then handle the delegation and forward the response to the client, as if the authentication had occured locally.

A real world use case is the coexistence between OpenLDAP and Active Directory: a notable scenario could be to let the password into AD, and configure a pass-through authentication between OpenLDAP and AD. With this setup, authentications done on the OpenLDAP are actually delegated to Active Directory.

There are two different solutions for setting up delegation of authentication:

There are some differences between these solutions:

  • SASL method has 3 layers: OpenLDAP — SASL daemon — 3rd party LDAP, whereas remoteauth has 2: OpenLDAP — 3rd party LDAP

  • SASL method allows more fine-grain configuration: domain set-up in the user password, LDAP search options to the 3rd party LDAP, timeout,…, but requires the meta or LDAP backend for dealing with multiple directories

  • remoteauth method is designed for managing multiple directories, grouped by domain. This requires constraints on the LDAP data: delegation is triggered globally for every entry with no userPassword and requires additional attributes for storing the user domain and DN

  • remoteauth is recommended by OpenLDAP core team

Configuration

Ensure you have remoteauth library available in your overlay directories.

remoteauth is part of main OpenLDAP overlays, and can be compiled with --enable-overlays or --enable-remoteauth.

Then configure your OpenLDAP with the appropriate directives (example with slapd.conf 1):

###################
# In global section
###################

modulepath      /usr/local/openldap/libexec/openldap
moduleload      remoteauth.la

[...]


#####################
# in database section
#####################

overlay remoteauth

# DN used to authenticate on the remote directory
remoteauth_dn_attribute seeAlso

# attribute used to resolve the domain
remoteauth_domain_attribute associatedDomain

# default domain if none is present in user entry
remoteauth_default_domain europe

# domain mapping => [ list of hostnames or URIs]
# file europe.list contains a hostname or LDAP URI, one per line
# OpenLDAP tries to connect to first server, then if it fails or timeouts, to second server,...
remoteauth_mapping europe file:///usr/local/openldap/etc/openldap/europe.list
# domain usa will use only one hostname
remoteauth_mapping usa ldap.usa.com

# fallback server to connect if no domain found in domain mapping
remoteauth_default_realm ldap.paris.com

# number of retries attempted
remoteauth_retry_count 1

# store the password in case of successfull bind?
remoteauth_store off

For example, with these LDAP data

dn: uid=test,ou=people,dc=my-domain,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
objectClass: domainRelatedObject
cn: test
givenName: test
mail: test@my-example.com
sn: test
uid: test
seeAlso: uid=myuser,ou=users,dc=example,dc=com
associatedDomain: europe

an authentication with:

ldapwhoami -x -H 'ldap://localhost:389' -D 'uid=test,ou=people,dc=my-domain,dc=com' -w secret

will result in a successful authentication of user uid=myuser,ou=users,dc=example,dc=com on first remote directory found in europe.list file (or second remote directory if the first one doesn’t answer in time)

Footnotes

1

example is given for a slapd.conf configuration. See slapd-config manual for more information about corresponding cn=config configuration