Re: slurpd with SASL

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 05:21 PM 8/9/00 -0400, Mark Adamson wrote:
>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?

I've been meaning to do something similar for SASL/GSSAPI.  So, THANKS!

>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

That seems reasonable.


>and the slapd.conf on the slave will need
>
>  updatedn "UID=U:LDAPSERVER.LDAP1+REALM=ANDREW.CMU.EDU"

Shouldn't that be "UID=LDAPSERVER.LDAP1+REALM=ANDREW.CMU.EDU"?
It was my intent to replace the authzId u:foo with the
authzDN uid=foo.

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

Yes... and BTW, I use:

rootdn          uid=ldap/root@K5.REALM

and leave rootpw unset.