Integrating LDAP and Kerberos: Part One (Kerberos)

Kerberos and LDAP are popular, separately, but if you put them together they provide a powerful solution for secure authentication. In the first of two tutorials, Juliet Kemp walks through installation and configuration of Kerberos.

LDAP and Kerberos are widely used, separately, yet integrating them seems less popular. This is a shame, as they fit together very well — in particular, you should avoid using LDAP for authentication, for which it is not well designed. Security is increasingly important for all sites, and Kerberos is a massive security increase over LDAP authentication.

What is LDAP?

LDAP stands for Lightweight Directory Access Protocol — it is not itself either hardware or software, but a protocol to define how a client and server interact with each other. An LDAP directory is used to describe a directory whose server corresponds to this protocol.

LDAP works by the client asking the server for particular information, the server runs the appropriate search (e.g. to find the entry for a given uid), and returns that information to the client. An entry is a structure which holds information about an object, and entries are arranged in a tree structure.

Schemas are used to prescribe the syntax and structure for particular types of object and particular object attributes. Plenty of standard schemas are available, and you can also create your own schemas or add to existing ones, in order to meet the needs of your site.

LDAP can run either (using SSL, on port 636 as ldaps:///) or over a unsecured connection (on port 389 as ldap:///). The next part of this piece will explain how to set up a secure LDAP server, using OpenLDAP.

What is Kerberos?

Kerberos only handles authentication, of machines or of users. When a user logs in to their machine, they request a Ticket-Granting Ticket (TGT) from the Key Distribution Center (your main Kerberos server, or a slave server). The KDC finds the user in its database, then sends back a TGT encrypted using their key. That TGT is decrypted at the other end with the user’s password. Therefore the password isn’t sent over the network, increasing security.

After that, any kerberized service uses this TGT to ask for a service-specific ticket: the user doesn’t need to enter their password again until the TGT expires (usually 10 hours), or is deleted. So, for example, if your entire system is Kerberos authenticated, you can log on once and then ssh to any system without having to re-authenticate.

The process works similarly for services or machines — except that a locally stored key is used instead of a password.

If you want more information, there’s an excellent and very readable explanation of how Kerberos works on the MIT Web site.

The rest of this article will deal with setting up Kerberos (the MIT version) — it’s easier (in my experience) to set up Kerberos first, then LDAP, than the other way around.

Kerberos server setup

Let’s start with installation and configuration. Kerberos should be available from any distribution — or, of course, you can compile from source. The Debian/Ubuntu packages needed are krb5-kdc, krb5-admin-server, libkrb5-dev, krb5-config, krb5-user, krb5-clients, and libkadm55.

During the installation of the packages you’ll be asked for the hostname of your server. This should be the fully qualified domain name (FQDN) of your server — e.g.kerberos.example.com.

Most of the configuration is done in /etc/krb5.conf. Edit this to look as follows:

Your realm should match your local domain, as illustrated above. The [logging] section is optional, but simplifies debugging.

If you want to set up a slave kerberos server as well as the master, you can have multiple KDC lines. The KDC, as mentioned above, does the giving out of TGTs, and you can have as many as you like. However, you only have a single admin server, which acts as the master KDC.

Start the kerberos admin server and the KDC (/etc/init.d/krb5-admin-server start; /etc/init.d/krb5-kdc start). It’s normal for it to take some time to start the admin server — so be patient.

Setting up the database

Now you’ll need to create the initial database and populate it with your inital admin user(s).

Initially, you use kadmin.local for this — this only ever runs locally on the master server, and does not use Kerberos to authenticate to that server. So, before you have a Kerberos database, it’s the only way to talk to the server! After you have your admin user set up, you should use kadmin instead.

The first command creates your database, and the next two are needed to enable admin changes to happen. The final two commands create a Kerberos admin principle (krbadm) and an LDAP admin principal (ldapadm) — you’ll be asked to provide a password.

Obviously, your choice of usernames in the last two lines is up to you! Or you can have a single admin user. Some sites prefer to create admin users that look like krbadm/admin@EXAMPLE.COM to make it clear which users have admin privileges.

You also need to edit the ACL (access control), in the file /etc/krb5kdc/kadm5.acl. A very basic example corresponding to the above setup is as follows:

This gives all access to the Kerberos admin user, and to any /admin user, and read-only access to all principals in the domain (note that */* and * are both required — just as user/admin@EXAMPLE.COM and user@EXAMPLE.COM are both different).

Edit /etc/krb5kdc/kdc.conf to set EXAMPLE.COM as the realm, and ensure that the database, keytab, and ACL locations match what you set in the database creation above. Note that the admin_keytab location must be specified as FILE:/etc/krb5kc/kadm5.keytab, not just as the bare filename.

Restart krb5-kdc and krb5-admin-server for the changes to take effect. From now on, you use kadmin -p krbadm to make changes.

Check that all is working by typing kinit krbadm — you should be challenged for the password. Then type klist and you will see that you have an authorized principal krbadm.

Kerberos client setup

The Debian packages needed are: krb5-user (for klist and kinit), ntpdate (the time on server and client must match), and libsasl2-gssapi-mit. Edit /etc/krb5.conf to make sure that the following entries are correctly set:

This may already have been done by the Debian package configuration, if you answered the questions correctly.

SSH and logon

You next need to set up both server and clients to use Kerberos for logon and for SSH logon. Debian users will need to install libpam-krb5, openssh-server, libsasl2-dev, libsasl2-gssapi-mit, and libsasl2-modules. The same packages should be available for Ubuntu and other distros, but (in some cases) with different names.

Edit /etc/pam.d/common-auth and /etc/pam.d/common-session to use pam_krb5.so.1, as follows:

The sufficient line enables local login (e.g. by root) if necessary. At least one line in common-auth must be required, or you will be able to log in without a password, which probably isn’t desirable.

The use_first_pass and try_first_pass options mean that you get asked for your password only once, whichever module is used. ignore_root means that the kerberos module is not used for root login — this is more secure.

For ssh, edit /etc/ssh/sshd_config to set the various Kerberos options as follows:

Then edit /etc/ssh/ssh_config to set both GSSAPIAuthentication and GSSAPIDelegateCredentials to Yes.

You need to add the server host to the keytab in order to enable ssh to transfer the Kerberos credentials. From the client, run kadmin -p krbadm (authenticating you as the admin user) and execute these commands:

The -randkey option generates a random key rather than asking for a password — this is obviously preferable for a non-person entity.

Testing

Now it’s time to ensure that everything is in working order. Create a test user via kadmin:

addprinc test@EXAMPLE.COM

Test the setup by first logging on with console, then with graphical logon, and then via ssh. Once logged on to one kerberized machine, you should be able to ssh to another kerberized machine without typing your password again.

Troubleshooting

Things to check if it doesn’t work smoothly:

Check the time on the KDC and the client machine — they must be the same. (There’s a tolerance of 5 minutes by default).

Check that you can ping the KDC and that there aren’t any other network problems.

Check that the host key has the correct number, by executing the following on the client:

Wonderful story, reckoned we could combine a number of unrelated information, nevertheless really worth taking a appear, whoa did one find out about Mid East has got far more problerms at the same time.