Intended Audience: System architects, developers and system administrators
- Client parameters
- PAM/NSS services
- SSH proxy
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 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:
- Filter for searching a particular account...
- ...by username
- ...by e-mail address
- Additionally ensure the found user has login right on your system:
Bear in mind that your system always must bind to be granted access for searching users and groups etc.
Clear-text connections are strictly disallowed. Therefore your system has to know the following parameters for estabilishing a validated TLS connection:
- CA certificate
- strict validation mode
- strong cipher suites matching what's configured with slapd.conf directive TLSCipherSuite
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):
- Server services (application/service login):
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:
- client public-key certificate and key
- private client key (matching client cert)
- Subject DN of client cert must be written to attribute seeAlso in aeService entry in LDAP string representation.
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 leverage any of its special features.
The following diagram illustrates the integration of sssd into Linux login:
Two example configuration files for simple bind and SASL/EXTERNAL bind
with TLS client certs:
Example ansible role:
(set ansible variable nsswitch_module to "sss")
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
Example ansible role:
(set ansible variable nsswitch_module to "ldap")
Smart PAM/NSS clients
Smart clients optimized for Æ-DIR should do the following:
Bind to Æ-DIR either with
- simple bind (short-DN form)
- SASL/EXTERNAL bind when using TLS client certs
- Send LDAP Who Am I? extended operation (see RFC 4352) to find the real DN of their own aeHost entry for determining aeSrvGroup membership.
- Send Session Tracking extended control with the IP address of the client system accessing the service (see draft-wahl-ldap-session)
Construct the search filters for searching user, group and sudoers
entries based on the attributes found in all relevant
entries searched before:
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.