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.

1. Current position

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.

  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. We need to establish whether or not this is the only such case.

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.

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 if any such data is snoop-able en route.)

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

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

-- IanDurkacz - 19 Mar 2013

Edit | Attach | Print version | History: r9 | r7 < r6 < r5 < r4 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r5 - 29 Mar 2013 - 12:37:59 - 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