[Date Prev][Date Next]
Re: slurpd with SASL
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
>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 \
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
>(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
Yes... and BTW, I use:
and leave rootpw unset.