On Sat, 11 Jun 2011, Dan White wrote:

Yes, interestingly, this shows up for both failure modes:
Jun 11 15:37:02 sparks-ave ldapwhoami: canonuserfunc error -7
Jun 11 15:37:02 sparks-ave ldapwhoami: _sasl_plugin_load failed on
sasl_canonuser_init for plugin: ldapdb

The ldapdb error probably isn't related. You should be able to add:
ldapdb_uri: ldapi:///

to /etc/sasl2/slapd.conf or /usr/lib/sasl2/slapd.conf to stop it from
complaining.

Doesn't help -

/etc/sasl2/slapd.conf:
allowanonymouslogin: 1
allowplaintext: 1
ldapdb_uri: ldapi:///

and even after the below info, and restarting slapd & saslauthd
I'm still getting this in /var/log/auth.log:
Jun 11 18:40:36 sparks-ave ldapwhoami: canonuserfunc error -7
Jun 11 18:40:36 sparks-ave ldapwhoami: _sasl_plugin_load failed on
                                       sasl_canonuser_init for plugin: ldapdb
Jun 11 18:40:36 sparks-ave ldapwhoami: DIGEST-MD5 common mech free

This one for the succes case:
Jun 11 15:37:02 sparks-ave ldapwhoami: DIGEST-MD5 common mech free

/etc/ldap/ldap.conf:
BASE    dc=<...>
URI     ldapi:///
TLS_CACERT /etc/ssl/certs/ca-certificates.crt
TLS_CACERTDIR /etc/ssl/certs
TLS_CRLCHECK none
TLS_REQCERT allow

~/.ldaprc:
SASL_MECH gssapi

I haven't done gssapi over ldapi:/// before - how does your (client) gssapi
mech know which kerberos service ticket to submit to the server
(ldap/<hostname>@REALM) for authentication? Maybe it just uses the local
hostname?

Good question !

It apparently does use the canonical host name - I have a ticket for:
krbtgt/<realm>@<REALM>
ldap/sparks-ave.<domain>@<REALM>


Does it make any difference if you use ldap://hostname instead?

Actually, I think you fixed it by mistake :) intermittent reverse
resolution issues (I got an error saying couldn't find
a ticket for 192.168.1.12@<REALM> ... instead of sparks-ave !

When there's a failure, are you getting the ldap/<hostname>@REALM service
ticket from your kerberos server? Does klist look the same between failures
and successes?

The testing has all been done under the same session, after login in,
and not resetting krbt credentials:
krbtgt/
ldap/sparks-ave
host/sparks-ave
imap/sparks-ave
smtp/sparks-ave

I think we can chock this up to operator error due to flaky DNS - why it
worked ~25% of the time is a mystery... krb is pretty sensitive to forward, reverse, and cononical host names.

Thanks... looks like 'tis time to update more machines now :)
--
Rick Nelson
"...you might as well skip the Xmas celebration completely, and instead
sit in front of your linux computer playing with the
all-new-and-improved linux kernel version."
(By Linus Torvalds)



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to