Review of OpenLDAP DICE client configuration

This is an initial list of thoughts about Project 267 - Review of OpenLDAP DICE client configuration in order to try to clarify:

  • what are the objectives of the project;
  • what we consider the current problems with LDAP here to be;
  • what we would prefer as outcomes for a revamped system.

To try to clarify my thinking, here is what I think is the current position. If any of the following is wrong, please tell me.

Current client configuration

  1. All DICE clients run their own complete LDAP server, the content of which is sync'ed daily or so against the master by the in-house slaprepl script. slaprepl runs via SASL->GSS-API->-Kerberos, so the exchange is both authenticated and encrypted.

  2. A DICE client in current standard configuration makes all LDAP lookups against its own server, but no DICE client ever writes to its own LDAP server. The only LDAP server ever written to is the single master.

  3. When a user process on a DICE client does an nss LDAP lookup (i.e. a lookup originating from a glibc call, e.g. getpwnam), that lookup always proceeds via the nslcd daemon. The LDAP server therefore has no knowledge of the UID of the actual process which made the lookup request. No Kerberos/SASL authentication or encryption is involved: the LDAP request is done via anonymous bind, and transmitted in plain-text.

    The use of nslcd appeared by default in the transition from SL5 to SL6; it was not particularly planned for, and there are alternatives - e.g. the use of no cache'ing daemon whatsoever; or the replacement of nslcd by sssd. It is not clear what we are trying to gain by the use of a cache'ing daemon.

    On a DICE client, an explicit LDAP lookup via ldapsearch normally (†) proceeds via SASL and Kerberos, so the exchange is both authenticated and encrypted. († The normal behaviour is configured by compiled-in defaults; it can be overridden, and an anonymous lookup done, by use of the -x switch.)

    In the normal course of events, all of the above lookups on a DICE client take place entirely within the local machine. However, if a DICE client machine is configured to use an alternative LDAP server (e.g. !openldap.server mSET( then the same authentication/encryption setups apply.

    Specifically that means that, on our setup, no authentication or encryption is used for remote (i.e. off-machine) LDAP lookups which are done via the nslcd daemon. All such lookups are done via anonymous binds and proceed over unencrypted links.

  4. It might be the case that some DICE applications on DICE clients use the hard-coded address of 'localhost' as the location of the LDAP server against which they expect to do a lookup. But what such applications are - if any - isn't known. Empirically, a DICE client seems to run okay without its own local LDAP server process.

Current master/slave server configuration

  1. Synchronisation of data between the master and the slaves is done via the native OpenLDAP mechanism. syncrepl runs via SASL->GSS-API->-Kerberos, so the exchange is both authenticated and encrypted.

  2. None of our LDAP servers currently support TLS/SSL connections.

  3. Connections from clients are accepted either as anonymous binds, or as SASL->GSS-API->-Kerberos binds.

  4. LDAP bind access to the servers is restrcited by IP address range.

  5. After a successful bind, access to certain LDAP data is restricted by slapd ACL lists. We don't appear to have a obvious human-readable list of what such access restrictions are, or what their intent is.

  6. The privacy requirements of the data held in our LDAP servers isn't currently made explicit in design notes or otherwise.

Requirements of any future client configuration

  1. The client must be guaranteed that all data returned from LDAP is correct. All such data must therefore transmitted by a mechanism which guarantees it originates from a bona-fide Informatics LDAP server, and which guarantees that the data cannot be altered en route (†). This means, for example, that non-TSL/SSL anonymous lookups cannot be used. († Note that we do not necessarily care if any such data is snoop-able en route.)

  2. It is likely that client-side cacheing of LDAP data is necessary, or at least helpful, for performance and responsiveness. But this is just a claim which needs to be proven.

-- IanDurkacz - 19 Mar 2013

Edit | Attach | Print version | History: r9 | r6 < r5 < r4 < r3 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r4 - 20 Mar 2013 - 16:08:25 - IanDurkacz
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies