# 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/[email protected]
ticket cache:
# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: [email protected]
Valid starting Expires Service principal
03/24/24 03:38:17 03/24/24 15:38:17 krbtgt/[email protected]
renew until 03/31/24 03:38:12
03/24/24 03:39:05 03/24/24 15:38:17 ldap/[email protected]
renew until 03/31/24 03:38:12
keytab:
klist -k /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
2 ldap/[email protected]
2 ldap/[email protected]
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: [email protected]
SASL SSF: 56
SASL data security layer installed.
dn:uid=user1,cn=gssapi,cn=auth