dcsimg

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:

[libdefaults]
default_realm    EXAMPLE.COM
[realms]
	EXAMPLE.COM = {
        kdc = kerberos.example.com
        admin_server = kerberos.example.com
        default_domain = example.com
    }
[domain_realm]
    .example.com = EXAMPLE.COM
    example.com = EXAMPLE.COM
[login]
    krb4_convert = false
[logging]
    kdc = FILE:/var/log/kerberos/krb5kdc.log
    admin_server = FILE:/var/log/kerberos/kadmin.log
    default = FILE:/var/log/kerberos/krb5lib.log

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 commands to issue from the command line are:

    kdb5_util create -s
    kadmin.local -q "ktadd -k /etc/krb5kdc/kadm5.keytab kadmin/admin"
    kadmin.local -q "ktadd -k /etc/krb5kdc/kadm5.keytab kadmin/changepw"
    kadmin.local -q "addprinc krbadm@EXAMPLE.COM"
    kadmin.local -q "addprinc ldapadm@EXAMPLE.COM"

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:

krbadm@EXAMPLE.COM              *
*/admin@EXAMPLE.COM             *
*/*@EXAMPLE.COM                 i
*@EXAMPLE.COM                   i

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:

[libdefaults]
	default_realm = EXAMPLE.COM
[realms]
	EXAMPLE.COM = {
        kdc = kerberos.example.com
        admin_server = kerberos.example.com
    }
[domain_realm]
	example.com = EXAMPLE.COM
	.example.com = EXAMPLE.COM

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:

# /etc/pam.d/common-auth
auth    sufficient  pam_krb5.so use_first_pass ignore_root forwardable
auth    required    pam_unix.so nullok_secure try_first_pass

# /etc/pam.d/common-session
session         sufficient      pam_unix.so
session         sufficient      pam_krb5.so ignore_root

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:

KerberosAuthentication yes
KerberosOrLocalPasswd yes
KerberosTicketCleanup yes

UsePAM yes
AllowTcpForwarding yes

GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
GssapiKeyExchange yes

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:

addprinc -randkey host/client.example.com
ktadd host/client.example.com

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:

    sudo klist -k /etc/krb5.keytab
    kinit krbadm
    kvno host/client.example.com
    

    If they are not the same, you need to start up kadmin, remove the client principal from the keytab (ktrem), delete it (delprinc), then recreate and re-add it.

Now you should be able to use Kerberos for authentication. The next part of this article will tackle setting up your LDAP server.

Comments on "Integrating LDAP and Kerberos: Part One (Kerberos)"

Here are a few of the web sites we recommend for our visitors.

The time to study or stop by the subject material or web-sites we have linked to beneath.

We came across a cool website which you could possibly appreciate. Take a look when you want.

Just beneath, are a lot of absolutely not connected web-sites to ours, even so, they are surely really worth going over.

Below you?ll discover the link to some internet sites that we feel you must visit.

Usually posts some extremely intriguing stuff like this. If you?re new to this site.

Check beneath, are some entirely unrelated web sites to ours, having said that, they’re most trustworthy sources that we use.

Every after inside a while we pick blogs that we read. Listed beneath are the most recent web pages that we pick.

The time to study or pay a visit to the content or web pages we have linked to beneath.

Here are several of the internet sites we recommend for our visitors.

Please take a look at the internet sites we comply with, like this one particular, as it represents our picks through the web.

Here are some links to websites that we link to since we consider they may be really worth visiting.

We came across a cool web-site that you may possibly delight in. Take a appear in the event you want.

Although internet sites we backlink to beneath are considerably not associated to ours, we feel they are essentially really worth a go through, so possess a look.

Every the moment in a when we decide on blogs that we read. Listed below would be the latest web sites that we pick.

That would be the end of this report. Right here you?ll locate some sites that we assume you will appreciate, just click the links.

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.

Below you?ll uncover the link to some internet sites that we assume you should visit.

We came across a cool web site which you may well delight in. Take a look if you want.

Every when inside a although we opt for blogs that we read. Listed beneath would be the most recent web sites that we opt for.

Just beneath, are many totally not connected sites to ours, nevertheless, they are certainly really worth going over.

Below you will obtain the link to some web-sites that we assume you ought to visit.

Usually posts some extremely interesting stuff like this. If you?re new to this site.

The facts mentioned in the post are some of the ideal obtainable.

Check below, are some totally unrelated sites to ours, on the other hand, they are most trustworthy sources that we use.

Thank you, I’ve just been searching for info about this subject for ages and yours is the best I have discovered till now. But, what about the bottom line? Are you sure about the source?

Here is a great Weblog You may Discover Interesting that we encourage you to visit.

Wonderful story, reckoned we could combine some unrelated data, nonetheless actually really worth taking a look, whoa did 1 understand about Mid East has got far more problerms also.

That could be the finish of this post. Here you will come across some websites that we feel you?ll enjoy, just click the links.

That could be the end of this write-up. Right here you will discover some internet sites that we consider you?ll appreciate, just click the links.

Here are some of the web pages we recommend for our visitors.

Every the moment inside a whilst we pick out blogs that we study. Listed below would be the most recent web pages that we opt for.

Wonderful story, reckoned we could combine a couple of unrelated data, nonetheless definitely really worth taking a look, whoa did one particular learn about Mid East has got a lot more problerms too.

Very couple of web-sites that occur to become comprehensive below, from our point of view are undoubtedly effectively really worth checking out.

Very few websites that transpire to become in depth below, from our point of view are undoubtedly nicely really worth checking out.

Very handful of internet sites that happen to become detailed beneath, from our point of view are undoubtedly very well worth checking out.

Check beneath, are some totally unrelated web-sites to ours, nevertheless, they are most trustworthy sources that we use.

We came across a cool web site that you might love. Take a search should you want.

Very few sites that happen to become in depth below, from our point of view are undoubtedly properly worth checking out.

Leave a Reply