Applications

Intended Audience: System architects, developers and system administrators

1. Client parameters
   1. Search parameters
   2. Bind parameters
      1. TLS parameters
      2. Simple bind
      3. SASL/EXTERNAL
2. PAM/NSS services
   1. aehostd -- Custom NSS/PAM demon
   2. sssd
   3. nss-pam-ldapd (aka nslcd)
   4. nsscache
3. OpenSSH Certificate Authority
4. SSH proxy
5. LDAP proxy for another LDAP server
6. Wifi access point

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:

subtree

Various possible filters for searching for all visible users accounts:

• (objectClass=account)
• (objectClass=inetOrgPerson)
• (objectClass=person)

Filter for searching a particular account...

...by username

(uid=<username>)

...by e-mail address

(mail=<e-mail address>)

Additionally ensure the found user has login right on your system:

(&(uid=<username>)(pwdChangedTime=*))

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:

• CA certificate
• strict validation mode
• strong cipher suites matching what's configured with slapd.conf directive TLSCipherSuite

Simple bind

Bind-DN

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

SASL/EXTERNAL

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.

PAM/NSS services

aehostd -- Custom NSS/PAM demon for Æ-DIR

aehostd is the preferred solution to integrate Linux and other POSIX systems. It gives better search performance and has other specific features.

See also:

• aehostd -- Specific features

sssd

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.

See also:

• Blog article: Anatomy of sssd user lookup
• Two example configuration files for simple bind and SASL/EXTERNAL bind with TLS client certs: client-examples/sssd

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

See also:

• nss-pam-ldapd: Design documentation
• nss-pam-ldapd: Documentation
• nslcd.conf(5) manual page

OpenSSH Certificate Authority

To avoid the need for implementing an out-of-band trust process for authorized keys and enforce rotation of user keys it is recommended to issue temporary OpenSSH user certificates only valid for a limited time-span (e.g. a few hours).

While there are several SSH-CA implementations out there the easiest solution is to use the integrated EKCA services.

SSH proxy

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.

Notes:

• 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.

See also:

• 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.

Notes:

• 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).

See also:

• 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.5 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.

Notes:

• 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 section 11.2.5) because Æ-DIR does not grant 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.

See also:

• Example configuration files: client-examples/freeradius
• FreeRADIUS Documentation