Intended Audience: System architects, developers and system administrators
- Client parameters
- PAM/NSS services
- SSH proxy
- LDAP proxy for another LDAP server
- Wifi access point
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.
aehostd -- Custom NSS/PAM demon
While you can integrate your Linux systems with any NSS/PAM service demon it is highly recommended to use aehostd which gives better search performance and has features specifically useful when using Æ-DIR.
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:
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")
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 Multiplexing
- Ansible FAQ: How do I configure a jump host to access servers that I have no direct access to?
LDAP proxy for another LDAP server
If you want to secure administrative access to another LDAP server you can use OpenLDAP's slapd-ldap(5) (aka back-ldap) for integrated authentication and authorization.
The following picture shows an example for a separate LDAP server serving DNS and DHCP data (or anything else) which gets maintained via LDAPS.
- The admin is authenticated via LDAP simple bind pass-through.
- With its service entry the LDAP proxy queries users and groups from Æ-DIR and uses that for authorizing administrative access to the entries stored in the local database backend.
- It is recommended to use the TLS server certificate of the external LDAP server also for authentication to Æ-DIR to avoid the need for maintaining another system credential (e.g. service password).
Example configuration file with SASL/EXTERNAL bind with TLS client cert:
- OpenLDAP man-page slapd-ldap(5)
- LDAP backend in OpenLDAP Software 2.4 Administrator's Guide
Wifi access point
For setting up a very simple wireless access point using WPA2 enterprise authentication you can install hostapd and FreeRADIUS on one system and configure the latter as LDAP client as shown in the following picture.
- With its service entry the RADIUS service queries users and groups from Æ-DIR and uses that for authorizing access to your Wifi network(s).
- The client must use EAP-TTLS with PAP in inner tunnel (see also RFC 5281) because Æ-DIR does not give read access to attribute userPassword and the user's password is stored as salted hash. It is highly recommended to disable all other mechanisms in FreeRADIUS config to avoid e.g. Windows insisting on using MSCHAP or other challenge-response mechs.
- It is recommended to use the EAP-TLS server certificate of the RADIUS service also for authentication to Æ-DIR to avoid the need for maintaining another system credential (e.g. service password).
- The RADIUS shared secret for hostapd is a purely local matter. It is not used to secure a remote RADIUS access. So no need to manage it centrally.
Example configuration files:
- FreeRADIUS Documentation