Hello,
I have a demo setup with slapd on Debian Stable, and a while back followed Debian's Switch to Buster, with slapd 2.4.47. Since about that time, slapd stopped recognising its SASL realm.
This is in a dev/demo/test environment in Docker, so naming is a bit silly, but that always worked. Config and such are shown at https://github.com/arpa2/docker-demo/tree/master/demo-reservoir
Using "ldapsearch -Y GSSAPI -H ldap://reservoir.arpa2:1388 -b ou=Reservoir,o=arpa2.net,ou=InternetWide" gives the message
SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No key table entry found matching ldap/reservoir.arpa2@)
**In this output, note the lacking realm after the @.** This appears to be a server-side issue, because the client had the realm in the klist output and that name is present in the keytab:
02/29/20 11:54:53 02/29/20 21:47:26 ldap/reservoir.arpa2@ARPA2.NET renew until 03/01/20 11:47:22
The configuration of the server in /etc/ldap/slapd.conf still says:
sasl-host reservoir.arpa2 sasl-realm ARPA2.NET
FWIW, slapd runs as
/usr/sbin/slapd -d any -h "ldapi://%2ftmp%2fldap-socket ldap://:1388/"
Have I missed changes to slapd? Are there log messages that I overlooked (or should selected for)?
Thanks! -Rick
openldap-technical@openldap.org