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-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
