There seems to be plenty of HOWTO's on getting Kerberos working with LDAP, with step by step instructions through the process. I found http://aput.net/~jheiss/krbldap/howto.html very good. I have documented here, not a step by step guide, but a list of the issues I faced configuring Kerberos to work with LDAP when things didn't go the way the HOWTO said it would. Hopefully each issue will be accompanied by a solution.
When using kerberos with various server/service principals it is inevitable that you will need to add some of these to /etc/krb5.keytab or some other keytab file. At times I found that after logging in to kadmin.local and typing ktadd host/myserver.example.com that nothing happened. The command just hung.
I solved this by:
[root]# cp /etc/krb5.keytab /etc/krb5.keytab.old [root]# rm /etc/krb5.keytab [root]# mv /etc/krb5.keytab.old /etc/krb5.keytab [root]# kadmin.local Authenticating as principal root/admin@EXAMPLE.COM with password. kadmin.local: ktadd host/myserver.example.com Entry for principal host/myserver.example.com with kvno 11, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/myserver.example.com with kvno 11, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/myserver.example.com with kvno 11, encryption type DES with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/myserver.example.com with kvno 11, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/etc/krb5.keytab.
Maybe some file locking issue?
Doing an LDAP search with a SASL bind e.g.
[lance]% ldapsearch -LLL -s base -b '' '(objectClass=*)' + ldap_sasl_interactive_bind_s: No such object (32)
instead of:
[lance]% ldapsearch -LLL -s base -b '' '(objectClass=*)' + SASL/GSSAPI authentication started SASL username: lance@EXAMPLE.COM SASL SSF: 56 SASL installing layers dn: namingContexts: dc=example,dc=com supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: CRAM-MD5 subschemaSubentry: cn=Subschema
This error will occur when the LDAP server doesn't provide a root DSE1. This may be due to access controls.
In your slapd.conf file you will need something like:
access to dn.base="" attrs=supportedSASLMechanisms,namingContexts,subschemaSubentry,objectClass,entry
by domain.subtree="example.com" read
by peername.ip="127.0.0.1" read
by peername.ip="112.123.123.12" read
by peername.ip="112.123.123.13" read
by * none
by peername="112.123.123.*" read is reported to work but I can't get a result from this. Let me know if you can get peername wildcards to work.
[lance]% ldapsearch -LLL -s base -b '' '(objectClass=*)' +
ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
You are using the TLS_CACERT configuration option in your ldap.conf file on the client machine, however the file you have designated does not contain the CA certificate matching the one that was used to sign the LDAP server's certificate. Keep in mind that the TLS_CACERT file can contain multiple CA certificates - just concatenate them together. This can be useful if you are phasing in a new CA certificate and/or LDAP server certificate.
[lance]% ldapwhoami ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (No credentials cache found)
You have not done a kinit i.e. you have not authenticated against your kerberos server.
[lance]% klist klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0) Kerberos 4 ticket cache: /tmp/tkt0 klist: You have no tickets cached [lance]% kinit lance Password for lance@EXAMPLE.COM [lance]% klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: lance@EXAMPLE.COM Valid starting Expires Service principal 02/02/07 13:33:46 02/02/07 21:33:46 krbtgt/EXAMPLE.COM@EXAMPLE.COM Kerberos 4 ticket cache: /tmp/tkt0 klist: You have no tickets cached [lance]% ldapwhoami SASL/GSSAPI authentication started SASL username: lance@EXAMPLE.COM SASL SSF: 56 SASL installing layers dn:uid=lance,cn=users,dc=example,dc=com [lance]%
[lance]% ldapsearch -LLL -s base -b '' '(objectClass=*)' +
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (Ticket expired)
Very similar to the previous error. Again, you need to do a kinit. Your Kerberos ticket has expired.
[lance]# ldapsearch -LLL -s base -b '' '(objectClass=*)' +
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Internal (implementation specific) error (80)
additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (No principal in keytab matches desired name)
This error would be much easier to debug if the error message would include the principal that it is looking for.
The LDAP server may not be able to find the keytab file. You will need to tell slapd where to find the keytab in your startup script. You can do this directly on your init script (but see note below for Redhat systems).
[root]# vi /etc/init.d/slapd #!/sbin/sh # /etc/init.d/slapd -- Start slapd. # KRB5_KTNAME="FILE:/etc/openldap/ldap.keytab" export KRB5_KTNAME
Using Redhat you can simply edit /etc/sysconfig/ldap
[root]# vi /etc/sysconfig/ldap export KRB5_KTNAME="FILE:/etc/openldap/ldap.keytab" [root]# service ldap start
The other possibility is that there really is a problem with the naming of the principal. The kerberos principal has to match the FQDN of the LDAP server. Make sure the DNS CNAME matches your hostname and that there is no ambiguity in your /etc/hosts file. If your server is ldap.example.com then your principal will likely be ldap/ldap.example.com. Also, keep in mind the curiously named sasl-host line in your slapd.conf. This refers to the LDAP server not your KDC server. (It took me three hours to find that out).
[lance]# ldapsearch -LLL -s base -b '' '(objectClass=*)' +
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Internal (implementation specific) error (80)
additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (Permission denied)
The LDAP server cannot read the keytab file. /etc/krb5.keytab is readable only by root and should NOT be made available to the LDAP server. The keytab file that the LDAP server uses must be readable by the owner of the slapd service (in this case ldap).
[root]# chgrp ldap /etc/openldap/ldap.keytab [root]# chmod 640 /etc/openldap/ldap.keytab [root]# ls -l /etc/openldap/ldap.keytab -rw-r----- 1 root ldap 1826 Oct 25 13:28 /etc/openldap/ldap.keytab
[lance]# ldapsearch -LLL -s base -b '' '(objectClass=*)' SASL/GSSAPI authentication started SASL username: lance/admin@EXAMPLE.COM SASL SSF: 56 SASL installing layers dn: objectClass: top objectClass: OpenLDAProotDSE [lance]# [lance]# ldapsearch -LLL -s base -b '' '(objectClass=*)' + SASL/GSSAPI authentication started SASL username: lance/admin@EXAMPLE.COM SASL SSF: 56 SASL installing layers dn: namingContexts: dc=example,dc=com supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: CRAM-MD5 subschemaSubentry: cn=Subschema
1 DSE DSA Specific Entry. DSA in turn stands for Directory System Agent (any directory enabled service providing DAP or LDAP access)
Author: Lance Rathbone
Last modified: Wednesday June 18, 2008
Home