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.
While the System Security Services Daemon (SSSD) for Linux provides lots of special features for enforcing security policies locally the configuration of sssd-ldap(5) for Æ-DIR deliberately does not make use of them.
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: client-examples/sssd
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 client-examples/nss-pam-ldapd
Example ansible role:
(set ansible variable nsswitch_module to "ldap")
It is possible to implement an authorizing SSH proxy which queries exactly the same Æ-DIR login relationship to check whether an user is allowed to login to a specific target SSH host through the SSH proxy.
- The aeSrvGroup of the SSH proxy's aeHost must have attribute aeProxyFor set referencing the aeSrvGroup of the target system or must have the general role Æ Login Proxy.
- The user authentication at the SSH proxy is done via SSH authorized key and PAM using password + OTP.
- The user has to use ProxyCommand to open the proxy connection prior to the SSH connection to the target host.
- ControlMaster connection should be used by the client to avoid reauthentication at the SSH proxy for subsequent connections to target systems.
- ForceCommand in sshd_config restricts normal users to only invoke a wrapper script which sets up a simple TCP relay. The wrapper script is run as the AE-DIR user connecting to the SSH proxy.
- A small demon on the SSH proxy queried by the wrapper script over a Unix domain socket for deciding whether to actually allow the login or not. It queries Æ-DIR login relationship defined for the aeSrvGroup of the target system.
- 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: client-examples/slapd-ldap
- 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.