slurpd with SASL

[Mark Adamson <adamson@andrew.cmu.edu>]

Is anyone actively working on making slurpd work with more than simple
authentication?  I wanted SASL authentication, so I made a quick patch in
the servers/slurpd/ tree that would allow me to use Kerberos V4 under
SASL when slurpd connects to slave servers. If you would like to see the
patch, it's against OpenLDAP 2.0 Beta, and is available at
   http://nil.andrew.cmu.edu/ldap/slurpd_sasl.gdiff

An issue that I know will come up is that SASL+K4 requires a TGT to make
the authentication. I did not want to put Kerberos function calls into
slurpd to fetch a ticket from /etc/srvtab, since that breaks the intent of
SASL, which is to free the application from having to write mechanism
specific code. Therefore, the slurpd process needs to run as the child of
a ticket refreshing program like "reauth" or "kauth".  What do people
think of this requirement?  What requirements are there for other
mechanisms people are using?

  -Mark Adamson   
   Carnegie Mellon




PS  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

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