----- D R A F T ----- D R A F T ----- D R A F T ----- D R A F T ----- D R A F T ----- D R A F T -----

Review of OpenLDAP DICE client configuration

This document concerns Project 267 - Review of OpenLDAP DICE client configuration and attempts to clarify:

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


1. Current position

1.1 Current client configuration

  1. All DICE clients run their own complete LDAP server, the content of which is sync'ed hourly (†) against the master by the in-house slaprepl script. slaprepl runs via SASL->GSS-API->-Kerberos, so the exchange is both authenticated and encrypted. Machines on the 'stable' release currently synchronise against the single master LDAP server; machines on the 'develop' release sychronise against the slaves, via the DNS round-robin entry dir.inf.ed.ac.uk.

    († The hourly sync does modifications and additions only. An additional daily run does deletions. The separation of these arose because the deletion run was at one stage time-consuming. That might not be the case any more; the separation could be revisited.)

  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(dir.inf.ed.ac.uk)) 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. 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. Currently, the only known source of this hard-coding is the dice-authorize package (see 3.1 below.) We need to establish whether or not this is the only such case.

1.2 Current master/slave server configuration

  1. Synchronisation of data between the master and the slaves is done via the native OpenLDAP mechanism syncrepl. That 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 restricted 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.

2. Requirements of any future client configuration

  1. Any LDAP configuration must be extremely reliable: a broken LDAP means a broken machine.

  2. 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 if the LDAP server is on a different machine than the client.

    († Note that we do not necessarily care whether or not any such data is snoop-able en route.)

  3. It would be preferable if clients were aware of LDAP updates more rapidly than the current replication arrangements (which can mean a delay of up to one hour) permit.

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

3. Technical obstacles to using a standard client<-> server LDAP model

3.1 Hard-coded dependencies

Currently the only known package with a hard-coded dependency to localhost / as the LDAP server is -the dice-authorize package.

dice-authorize package

The dice-authorize package dates back to the original DICE development and provides library calls (†) whose role it is to securely answer the question 'does user x have capability y?'

The package provides the following:

  • pam_diceauth.so
  • libdiceauth.a and libdiceauth.so
  • DICE::Authorize.pm

(† It also provides some other tools - buildcaps and roleupload - which are no longer used.)

pam_diceauth.so uses libdiceauth.so - but we do not use pam_diceauth.so in our PAM stack any more.

Looking at the sources for dice-authorize/libs/c/authorize.c and dice-authorize/libs/perl/Authorize.pm, both appear to be parallel implementations of exactly the same logic. (††) And, currently, both implementations have hard-coded dependencies to 'localhost' as the LDAP server.

The C library would be easy to change to select the LDAP server based on the content of /etc/openldap/ldap.conf, since it uses the OpenLDAP library to do its work. But the Perl module will be less easy since it uses Net::LDAP, which has no knowledge of OpenLDAP.

Is there any good reason why we should have two distinct parallel implementations of this logic? Is there any reason why a Perl module which is just a wrapper calling the C library can't be built?

(†† Some of that logic should probably be cleaned up: e.g. do we still have capabilities called 'user/...' and '<console>'?)

-- IanDurkacz - 19 Mar 2013

Edit | Attach | Print version | History: r9 < r8 < r7 < r6 < r5 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r6 - 29 Mar 2013 - 15:09:13 - 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