[Date Prev][Date Next] [Chronological] [Thread] [Top]

slurpd with SASL (ITS#655)



I was working on making slurpd work with more than simple authentication
since I wanted SASL authentication, so I made a quick patch in
the servers/slurpd/ tree that would allows the of use Kerberos V4 under
SASL when slurpd connects to slave servers. The patch is against
OpenLDAP 2.0 Beta, and is available at

   http://nil.andrew.cmu.edu/ldap/slurpd_sasl.gdiff

It includes a short update to the slapd.conf(5) man page.

The patch does not include code to fetch a Kerberos service ticket from
the /etc/srvtab file, since that breaks the intent of SASL (which is to
free the application from having to write mechanism specific code).
Therefore, if a SASL mechanism that uses Kerberos (i.e. KERBEROS_V4 or
GSSAPI) is to be used, the slurpd process needs to run as the child of a
ticket refreshing program like "reauth" or "kauth".


The slapd.conf on the master slapd will need lines like

  replica host=ldap2.andrew.cmu.edu \
    bindmethod=SASL \
    saslmech=KERBEROS_V4 \
    bindprincipal=ldapserver.ldap1


and the slapd.conf on the slave will need an updatedn line that gives the
SASL name. Running slapd with -d128 will produce "acl_mask" lines that
tell the SASL name that the server applies to bound connections.

  updatedn "UID=U:LDAPSERVER.LDAP1+REALM=ANDREW.CMU.EDU"

  access to attr=entry
    by dn="UID=U:LDAPSERVER.LDAP1+REALM=ANDREW.CMU.EDU" write
    <...>


(The "access" line is provided just to show how SASL names can be put into
an ACL, and that the updatedn will probably be adding/removing entries and
attributes.)



   -Mark Adamson
    Carnegie Mellon