Bug#629589: segfault gone, but problems remain

[Richard A Nelson]

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)