Intended Audience: System architects, developers and system administrators

  1. Client parameters
    1. Search parameters
    2. Bind parameters
      1. TLS parameters
      2. Simple bind
  2. PAM/NSS services
    1. Simple PAM/NSS clients
      1. sssd
      2. nss-pam-ldapd (aka nslcd)
      3. nsscache
    2. Smart PAM/NSS clients
  3. SSH proxy

Client parameters

Integrating an LDAP-enabled application/system with Æ-DIR does not require detailed configuration tweaking. In general setting less special parameters are better than more because Æ-DIR ACLs internally sort out most stuff.

Search parameters

Search base:
ou=ae-dir (or whatever you configured in ansible default variable aedir_suffix)
Search scope:
Various possible filters for searching for all visible users accounts:
  • (objectClass=account)
  • (objectClass=inetOrgPerson)
  • (objectClass=person)
Filter for searching a particular account... username
(uid=<username>) e-mail address
(mail=<e-mail address>)
Additionally ensure the found user has login right on your system:

Bind parameters

Bear in mind that your system always must bind to be granted access for searching users and groups etc.

TLS parameters

Clear-text connections are strictly disallowed. Therefore your system has to know the following parameters for estabilishing a validated TLS connection:

Simple bind


The bind-DN in client configuration files should be the unique short-form instead of the complete DN. This allows moving the accompanying host or service entry within the DIT to another zone and/or beneath another service group without having to reconfigure the client side.

Hosts (OS login):
host=<canonical hostname>,ou=ae-dir
Server services (application/service login):
uid=<service name>,ou=ae-dir


The OpenLDAP server can use authentication credentials available at the transport layer to authenticate the client if it connects via LDAP over IPC (LDAPI) or with TLS encryption and sends a SASL bind operation with mechanism EXTERNAL.

In case of TLS with client cert authentication the configuration requires these parameters to be set:

PAM/NSS services

Simple PAM/NSS clients

Simple PAM/NSS clients do not have any special knowledge about Æ-DIR DIT and schema.


While the System Security Services Daemon (SSSD) for Linux is not a simple component the configuration of sssd-ldap(5) for Æ-DIR does deliberately not use any of its special features.

The following diagram illustrates the integration of sssd into Linux login:

Æ-DIR integration of Linux with sssd components

Two example configuration files for simple bind and SASL/EXTERNAL bind with TLS client certs: client-examples/sssd/

Example ansible role: ansible/roles/ae-dir-linux-client/ (set ansible variable nsswitch_module to "sss")

See also:

nss-pam-ldapd (aka nslcd)

Arthur de Jong's nss-pam-ldapd is also a demon providing NSS and PAM services and runs on various POSIX (non-Linux) platforms.

Example nslcd.conf in directory client-examples/nss-pam-ldapd/

Example ansible role: ansible/roles/ae-dir-linux-client/ (set ansible variable nsswitch_module to "ldap")

See also:


If you like syncing the NSS maps locally for off-line use you can look at nsscache and its NSS module libnss-cache.

Smart PAM/NSS clients

Smart clients optimized for Æ-DIR should do the following:

SSH proxy

It is possible to implement an authorizing SSH proxy which uses exactly the same Æ-DIR entry references to check whether a user is allowed to login to target SSH host.

SSH proxy integrated with Æ-DIR

See also: