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



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