OpenLDAP, Kerberos, GSSAPI

From Docupedia

• • • WARNING ***

This doc is my dumping ground. It is not organized or coherent. Hopefully you find it helpful until I have time to properly structure it... Ben Klang

The Basics

• Make sure OpenLDAP has been compiled with --enable-spasswd (it is by default with SuSE 9.3)
• Have a working Kerberos realm. See Tim's excellent document on the subject at https://www.stoo.org/horde/wicked/display.php?page=KerberosAFSOpenSSH
• Ensure you have a working SASL library installed with GSSAPI. On SuSE this includes installing the packages cyrus-sasl-gssapi
• Persuant to the above goal, make sure you have properly working forward and reverse DNS. I know it's been said before but it bears repeating, here, again.

Create the Keytabs

Host Service Keytab

$ sudo kadmin -p user/admin
Password:   # This is your user pw for sudo
Authenticating as principal bklang/admin with password.
Password for bklang/admin@ALKALOID.NET: # This is your kerberos admin principal pw
kadmin:  addprinc -randkey host/hostname.example.com
WARNING: no policy specified for host/hostname.example.com@EXAMPLE.COM; defaulting to no policy
Principal "host/hostname.example.com@EXAMPLE.COM" created.

In the above entry the host/ part is literal but you'll need to replace hostname.example.com with the host you're trying to add.

Next add that principal to the local keytab:

kadmin:  ktadd host/hostname.example.com
Entry for principal host/hostname.example.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/hostname.example.com with kvno 3, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5.keytab.

LDAP Service Keytab

Do the same procedure as the Host Service Keytab, but use the principal

ldap/hostname.example.com 

NOTE: This time you're going to be adding the principal to a separate keytab so OpenLDAP can read from it without exposing the system keytab:

kadmin:  addprinc -randkey ldap/hostname.example.com
WARNING: no policy specified for ldap/hostname.example.com@EXAMPLE.COM; defaulting to no policy
Principal "ldap/hostname.example.com@EXAMPLE.COM" created.
kadmin:  ktadd -k /etc/ldap.keytab ldap/hostname.example.com
Entry for principal ldap/hostname.example.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/ldap.keytab.
Entry for principal ldap/hostname.example.com with kvno 3, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/etc/ldap.keytab.

Exit kadmin and chown ldap.keytab to make it available to OpenLDAP:

$ sudo chown ldap /etc/ldap.keytab

Finally ensure that the OpenLDAP daemon, slapd, starts with the following environment variable set:

export KRB5_KTNAME="/etc/ldap.keytab"

This is required to make sure slapd sees the LDAP service keytab as opposed to the host keytab stored in the Kerberos default location of /etc/krb5.keytab. Rather than editing the init script directly try adding this environment variable line to one of the following files:

/etc/sysconfig/openldap # SuSE
/etc/sysconfig/ldap # Red Hat
/opt/csw/etc/openldaprc # Blastwave (Solaris)
/etc/default/slapd # Debian, Ubuntu, Nexenta

Saslauthd

Start saslauthd as appropriate for your distribution:

SuSE

Edit the file /etc/sysconfig/saslauthd and put "kerberos5" in place of "pam" on the line defining SASLAUTHD_AUTHMECH. Then sudo rcsaslauthd restart to activate that daemon. Don't forget to ensure saslauthd starts at boot!

Red Hat

Edit the file /etc/default/saslauthd and define MECH as "kerberos5". Then restart saslauthd: /etc/init.d/saslauthd restart Don't forget to ensure saslauthd starts at boot!

Debian/Ubuntu/Nexenta

Edit the file /etc/default/saslauthd and define MECHANISMS as "kerberos5". Then restart saslauthd: /etc/init.d/saslauthd restart Don't forget to ensure saslauthd starts at boot!

Edit the file /etc/sysconfig/saslauthd and If you're on a generic Unix/Linux host, start saslauthd:

$ sudo saslauthd -a kerberos5

Enabling the Users

To enable your your users to continue to authenticate via legacy LDAP simple authentication using their Kerberbos password, replace their userPassword attribute (which may look like "{CRYPT}longpasswordhashhere") with {SASL}user@REALM. It is for this compatibility that saslauthd was started above and allows a single password for the user, whether they authentiate with SASL or LDAP simple.

Troubleshooting

GSSAPI: gss_accept_sec_context

If you run into the dreaded "GSSAPI: gss_accept_sec_context" problem try the following (courtesy http://mah.everybody.org/docs/sasl-gssapi/):

Starting SASL negotiation: authentication failure (GSSAPI: gss_accept_sec_context: Miscellaneous failure; Key version number for principal in key table is incorrect; ) The version of the key in your keytab file is out of sync with what is in the kerberos database or your ticket cache contains an old principal.

The fix:

First try to reauthenticate (kinit -R or kinit). If that does not solve the problem, the culprit is likely a stale or out of sync keytab. Recreate the LDAP keytab:

kadmin: ktrem -k /etc/ldap.keytab ldap/FQDN
kadmin: ktadd -k /etc/ldap.keytab ldap/FQDN

It is a good idea to re-verify the file permissions before continuing. Ensure the OpenLDAP user ID has read access to the keytab file.

Miscellaneous "Strange" Errors on Red Hat or SuSE

These are often caused by SELinux (on Red Hat) or AppArmor (on SuSE). The easy out is to disable these engines. For Red Hat edit the file /etc/sysconfig/selinux and change the SELinux mode from "enforcing" to "permissive":

SELINUX=permissive

Similarly you can disable AppArmor on SuSE.

However, that would be the wrong answer. The better answer would be to update the policy for the respective engine and apply it. In the future I will post my modified policies in hopes that other administrators will use them rather than just disable the squeaky wheel.