# ldapwhoami
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind: 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)
OpenLdap with SASL GSSAPI
Kerberos KDC server (with the openLdap as the DB backend)
I have a ticket cache created for user1
to use for GSSAPI authentication.
I have my krb5.keytab configured and set for the openLdap to use to authenticate with the KDC, as ldap/ldap.example.com@EXAMPLE.COM
ticket cache:
# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: user1@EXAMPLE.COM
Valid starting Expires Service principal
03/24/24 03:38:17 03/24/24 15:38:17 krbtgt/EXAMPLE.COM@EXAMPLE.COM
renew until 03/31/24 03:38:12
03/24/24 03:39:05 03/24/24 15:38:17 ldap/ldap.example.com@EXAMPLE.COM
renew until 03/31/24 03:38:12
keytab:
klist -k /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
2 ldap/ldap.example.com@EXAMPLE.COM
2 ldap/ldap.example.com@EXAMPLE.COM
What am I missing?
In my case the issue ended up being the file permissions on the krb5.keytab
for openLdap to use.
My slapd
was running using the ldap
user. But the ldap
user did not have read access to the krb5.keytab
file, only the root
user did.
Before:
# ls /etc/krb5.keytab -la
-rw------- 1 root root 170 Mar 23 06:25 /etc/krb5.keytab
After:
# chmod 777 /etc/krb5.keytab
/ # ls /etc/krb5.keytab -la
-rwxrwxrwx 1 root root 170 Mar 23 06:25 /etc/krb5.keytab
After updating the file permission to give the ldap
user read access, everything worked as expected! (777 probably wasn't necessary, I believe only read permission was needed.)
Successful GSSAPI authentication after:
# ldapwhoami -H ldap://ldap.example.com
SASL/GSSAPI authentication started
SASL username: user1@EXAMPLE.COM
SASL SSF: 56
SASL data security layer installed.
dn:uid=user1,cn=gssapi,cn=auth