To properly enable GSSAPI authentication in OpenLDAP, you'll need to ensure these components are correctly configured:

1. MIT Kerberos or Heimdal Kerberos installed
2. OpenLDAP compiled with Cyrus SASL support
3. Properly configured service principal
4. Correct keytab file permissions

First confirm your OpenLDAP was built with Cyrus SASL:

ldapsearch -H ldapi:/// -Y EXTERNAL -b "cn=config" "(objectClass=olcGlobal)" olcSaslSecProps
slaptest -V | grep -i sasl

Add these directives to your slapd configuration (either in slapd.conf or via ldapmodify for cn=config):

dn: cn=config
changetype: modify
add: olcSaslSecProps
olcSaslSecProps: noanonymous,noplain,noactive

dn: cn=config
changetype: modify
add: olcAuthzRegexp
olcAuthzRegexp: uid=([^,]*),cn=[^,]*,cn=auth uid=$1,ou=People,dc=example,dc=com

Your keytab setup looks correct, but let's verify the permissions:

ls -l /etc/ldap/ldap.keytab
chown openldap:openldap /etc/ldap/ldap.keytab
chmod 400 /etc/ldap/ldap.keytab

First obtain a Kerberos ticket, then test the bind:

kinit exampleuser
ldapwhoami -Y GSSAPI -H ldap://ldap.example.com -vvv

If you encounter problems, check these logs:

journalctl -u slapd --since "1 hour ago"
tail -f /var/log/syslog | grep -i sasl
klist -kte /etc/ldap/ldap.keytab

After applying all changes, restart slapd and verify:

systemctl restart slapd
ldapsearch -H ldapi:/// -b "" -s base supportedSASLMechanisms

---

When trying to implement Kerberos authentication with OpenLDAP, many administrators encounter the frustrating situation where GSSAPI doesn't appear in the supportedSASLMechanisms list. The error message typically looks like:

ldap_sasl_interactive_bind_s: Authentication method not supported (7)
additional info: SASL(-4): no mechanism available: Couldn't find mech GSSAPI

Before enabling GSSAPI, ensure your system meets these requirements:

• OpenLDAP 2.4 or later installed
• MIT Kerberos or Heimdal Kerberos installed
• Properly configured krb5.conf file
• Service principal created for LDAP

First, create the service principal and keytab:

kadmin -q "addprinc -randkey ldap/ldap.example.com@EXAMPLE.COM"
kadmin -q "ktadd -k /etc/ldap/ldap.keytab ldap/ldap.example.com@EXAMPLE.COM"

On Debian/Ubuntu systems:

apt-get install libsasl2-modules-gssapi-mit

On RHEL/CentOS:

yum install cyrus-sasl-gssapi

Edit your slapd configuration (typically in cn=config or slapd.conf):

dn: cn=config
changetype: modify
add: olcSaslSecProps
olcSaslSecProps: noanonymous,noplain,noactive,nodict

add: olcSaslHost
olcSaslHost: ldap.example.com

add: olcSaslRealm
olcSaslRealm: EXAMPLE.COM

Create or modify /etc/sasl2/slapd.conf:

mech_list: gssapi
keytab: /etc/ldap/ldap.keytab

Ensure these variables are set in your slapd startup script (/etc/default/slapd):

export KRB5_KTNAME=/etc/ldap/ldap.keytab
export SASL_MECH=gssapi

After restarting slapd, verify GSSAPI is available:

ldapsearch -x -H ldapi:/// -b "" -LLL -s base supportedSASLMechanisms

You should now see GSSAPI in the list of supported mechanisms.

If you encounter problems:

1. Verify keytab permissions (should be readable by ldap user)
2. Check system logs for SASL errors
3. Test Kerberos authentication independently with kinit
4. Ensure DNS resolution matches your principal names

For clients to use GSSAPI, configure /etc/ldap/ldap.conf:

URI ldap://ldap.example.com
BASE dc=example,dc=com
SASL_MECH GSSAPI

Test with:

ldapsearch -Y GSSAPI -H ldap://ldap.example.com -b "dc=example,dc=com" "(uid=testuser)"