Bug#629589: segfault gone, but problems remain

Dan White dwhite at olp.net
Sat Jun 11 23:51:48 UTC 2011


On 11/06/11 10:54 -0700, Richard A Nelson wrote:
>$ ldapwhoami
>SASL/GSSAPI authentication started
>ldap_sasl_interactive_bind_s: Invalid credentials (49)
>       additional info: SASL(-13): authentication failure: GSSAPI Failure:
>gss_accept_sec_context
>
>$ ldapwhoami
>SASL/GSSAPI authentication started
>SASL username: cowboy@<REALM>
>SASL SSF: 56
>SASL data security layer installed.
>dn:uid=cowboy,ou=users,dc=...
>
>
>$ ldapwhoami
>SASL/GSSAPI authentication started
>ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80)
>       additional info: SASL(-1): generic failure: GSSAPI Error:  No
>credentials were supplied, or the credentials were unavailable or inaccessible.
>(unknown mech-code 0 for mech unknown)

On 11/06/11 15:46:24 -0700, Richard A Nelson wrote:
>No, 'tis using ldapi://

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

>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?

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

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?

-- 
Dan White





More information about the Pkg-cyrus-sasl2-debian-devel mailing list