[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