Am Fri, 14 Apr 2017 14:35:37 +0200 schrieb Jaap Winius jwinius@umrk.nl:
Hi folks,
My new Debian stretch slapd consumer configuration is suffering from a Kerberos authentication problem that looks like a bug. It is apparently unable to read the Kerberos keytab file and instead authenticates to its provider as (for my realm) ldap/localhost@EXAMPLE.COM. The error I keep getting is:
slapd[1668]: GSSAPI Error: Unspecified GSS failure. \ Minor code may provide more information \ (Server ldap/localhost@EXAMPLE.COM not found in Kerberos database)
The software I'm using is:
- Debian stretch
- MIT Kerberos 1.15-1
- slapd 2.4.44+dfsg-3
- libsasl2-modules-gssapi-mit 2.1.27~101-g0780600+dfsg-3
The usual way to get slapd to use a Kerberos principal to authenticate to a provider is by telling it where the Kerberos key table file is. On Debian systems, slapd looks in a default location first (/etc/krb5.keytab), but an alternate keytab can be set in /etc/default/slapd with e.g.:
export KRB5_KTNAME=/etc/ldap/krb5-ldap.keytab
Just ensure that the openldap group can read the keytab file. This works on Debian wheezy with slapd 2.4.31-2+deb7u2, but for some reason it's not working at all on Debian stretch.
Other things I have checked are:
- /etc/hostname
- hostnamectl status
- /etc/hosts (contains only '127.0.0.1 localhost' and linklocal
addresses)
- DNS forward and reverse lookups
So, is this a slapd problem, or maybe something to do with a SASL/GSSAPI library, such as libsasl2-modules-gssapi-mit?
From our conversation on cyrus.sasl list I can tell it is definitely not an OpenLDAP Project problem, it is most likely a distribution problem. Check the libraries, openLDAP has been linked to. Otherwise you may file a bug report with your distribution.
-Dieter