This article assumes that you have read and followed the SASL chapter of the OpenLDAP? Administrator's Guide [1]. You should have a Kerberos server installed (such as Heimdal or MIT), and created all the appropriate principals (client and service) necessary.

To verify that you have the Cyrus GSSAPI mechanism properly installed, use the pluginviewer command. For instance:

server:~# pluginviewer  | grep -i gssapi
CRAM-MD5 PLAIN NTLM GSSAPI OTP DIGEST-MD5 ANONYMOUS LOGIN EXTERNAL 
Plugin "gssapiv2" [loaded],     API version: 4         
        SASL mechanism: GSSAPI, best SSF: 56, supports setpass: no 
CRAM-MD5 PLAIN NTLM GSSAPI OTP DIGEST-MD5 ANONYMOUS LOGIN EXTERNAL 
Plugin "gssapiv2" [loaded],     API version: 4         
        SASL mechanism: GSSAPI, best SSF: 56 

Both your server and client systems will need to have this mechanism installed. If not, you may find the mechanism located in a binary package that you do not yet have installed, or you may need to recompile your Cyrus SASL installation.

On your client system, search the Root DSE of the server to view advertised mechanisms:

client:~# ldapsearch -LLL -x -H ldap://ldap.example.org -s "base" -b "" supportedSASLMechanisms 
dn: 
supportedSASLMechanisms: DIGEST-MD5 
supportedSASLMechanisms: NTLM 
supportedSASLMechanisms: GSSAPI 
supportedSASLMechanisms: OTP 
supportedSASLMechanisms: CRAM-MD5 

If you received a No Such Object error, you may have an ACL misconfiguration on your server. See [3].

If you do not see GSSAPI listed, verify that the server can read the appropriate keytab. The default is /etc/krb5.keytab and is typically only readable by the root user. If your Kerberos library supports it, you can create a keytab in an alternate location, such as /etc/krb5.keytab-ldap, with only your LDAP service principal, and read permissions for your OpenLDAP? user.

If your OpenLDAP? server is looking for an unexpected principal within your keytab, use sasl-host and sasl-realm to influence which principal it will use (see the slapd.conf man page).

For more control over how the SASL library operates within the OpenLDAP? server, you can create a slapd.conf SASL configuration. This is not the same configuration file as the OpenLDAP? configuration (slapd.conf). The location of this file is dependent how on Cyrus SASL was compiled (via the --with-plugindir option during configure). It is the directory where your plugins are installed.

For instance, if you create /usr/lib/sasl2/slapd.conf (assuming that is the correct location on your system) with the following contents:

keytab: /etc/krb5.keytab-ldap 
mech_list: CRAM-MD5 DIGEST-MD5 GSSAPI 

then the server will search within /etc/krb5.keytab-ldap when initializing the GSSAPI plugin. The server will only offer the mechanisms listed in mech_list. If mech_list is not specified, the server will offer all the mechanisms available, and that it can initialize.

Once you have verified that the server is advertising GSSAPI support, then try:

client:~# ldapsearch -LLL -Y GSSAPI -H ldap://ldap.example.org -s "base" -b "" supportedSASLMechanisms 
SASL/GSSAPI authentication started 
SASL username: host/client.example.org@EXAMPLE.ORG 
SASL SSF: 56 SASL data security layer installed. 
dn: 
supportedSASLMechanisms: DIGEST-MD5 
supportedSASLMechanisms: NTLM 
supportedSASLMechanisms: GSSAPI 
supportedSASLMechanisms: OTP 
supportedSASLMechanisms: CRAM-MD5 

If you receive a list of mechanisms, then congratulations, you're done.

If instead you receive an error, then it's possible that your client is requesting a service principal that mismatches what your server is using.

Verify that you have received a TGT ticket from your kerberos server, and that you have also received a service principal ticket for the server (e.g. ldap/ldap.example.org@EXAMPLE.ORG). Use klist to verify:

client:~# klist
Credentials cache: FILE:/tmp/krb5cc_0
        Principal: host/client.example.org@EXAMPLE.ORG

  Issued           Expires          Principal
Feb 22 11:00:02  Feb 22 21:00:01  krbtgt/EXAMPLE.ORG@EXAMPLE.ORG
Feb 22 11:24:39  Feb 22 21:00:01  ldap/ldap.example.org@EXAMPLE.ORG

If not, then a network capture utility, such as wireshark, offers a good way to show you which service principal your client is requesting, and what errors are being returned by the server.

If you wish to also view the interaction with the LDAP server with a capture utility, you will need to negotiate a SASL layer without encryption. You can specify '-O maxssf=1' in your client side command (ldapwhoami, ldapsearch etc.), e.g.:

client:~# ldapsearch -LLL -Y GSSAPI -H ldap://ldap.example.org -O maxssf=1 -s "base" -b "" supportedSASLMechanisms 

You might find it easier to specify defaults on your client system, to keep your commands shorter. See the man page for ldap.conf for details. You can specify the default server in your ldap.conf file:

URI    ldap://ldap.example.org 

And you can specify the default mechanism in ~/.ldaprc (in your home directory):

SASL_MECH GSSAPI 

References:

1. http://www.openldap.org/doc/admin24/sasl.html
2. https://bugzilla.andrew.cmu.edu/cgi-bin/cvsweb.cgi/~checkout~/src/sasl/doc/gssapi.html?rev=1.4;content-type=text%2Fhtml
3. http://www.openldap.org/doc/admin24/appendix-common-errors.html#ldap_sasl_interactive_bind_s: ..