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)"

racerx

Here again – I would love to see someone do an article on one-way syncing from Active Directory to and ldap server.

Reply
jmpoth

this is a very relevant article.

Reply
jbuurman

One-way syncing of AD is also an issue at my work. Love to read something more about that.

Reply
mlix

Actually as I know red hat is doing some project

freeipa.org I think will integrate DS and kerberos.

also it will support migrate from AD to IPA.

Cheers

Reply
bsdlogical

While following this article (and Part Two), I finally managed to install Kerberos and OpenLDAP together. However, I ran into some problems with the howto posted here on the way. I’ve made an effort to describe how I fixed them as well as I can, and I hope it helps others attempting to do the same thing. I installed this on Ubuntu 8.04, and some of the corrections come from a partially finished guide at https://help.ubuntu.com/community/SingleSignOn. However, if I’ve inadvertently made any mistakes in these comments, please post that as well so others won’t be misled.

Problems/Comments in Part 1:
1) I had to run sudo dpkg-reconfigure krb5-kdc before starting up the KDC and admin server with /etc/init.d/krb5-admin-server start and /etc/init.d/krb5-kdc start. The answers to the questions in order were: Yes to Create Kerberos KDC configuration automatically, Disable Kerberos v4 compatibility mode, No to run a ticket conversion daemon, and No to purging data when krb5-kdc package is removed. See also #3.
2) There’s a significant problem in the example krb5.conf posted above that took me ages to figure out. There’s actually an equals sign missing after the default_realm parameter.
3) I also had to set up the database (by running kdb5_util, as well as everything in the Setting up the database section) before starting the KDC and admin server.
4) In Ubuntu, libsasl2-gssapi-mit is no longer available. It’s replaced by libsasl2-modules-gssapi-mit. I executed the following: apt-get install libpam-krb5 libsasl2-dev libsasl2-modules-gssapi-mit libsasl2-modules
5) I was not able to login as a principal I just added, even with the PAM configuration correct (under the Testing section). I had to get LDAP up and running first.

(continued in Part 2)

Reply
jwilleke

Please explain your statement: “…Kerberos is a massive security increase over LDAP authentication.”

Thanks
-jim

Reply
dbmethods

I hope this can be more clear such as from start up.
Showing

$ hostname

$ ping or Kerberos utlilites

$ dnsdomainname

And how to set this up with MySQL to have single sign on on 2 nodes?
If I get errors, how to trace them and fix that.

Reply
opc0d3

Nice article

Reply

I will right away take hold of your rss as I can’t find your e-mail subscription hyperlink or newsletter service. Do you have any? Kindly permit me understand in order that I could subscribe. Thanks.

Reply

This is a great article, but I have some basic questions. I hope you would be able to provide answers in your busy schedule.

Would I be able to create a domain with domain users and systems and not to use Kerberos?

In case I want Kerberos for authentication, is it mandatory that I should give the same domain name for Kerberos “realm” value? Is it that “realm” is nothing but a representation of a group of users/systems who would be authenticated using Kerberos? In short what exactly is a realm?

In the article you showed how to add users to Kerberos. Is it possible that instead of adding the username and passwords of the domain users to Kerberos, we can provide all that information to LDAP, and then Kerberos download that username/password information to its database and further use it? This might not be a good idea, but I still want to know whether it is possible.

In the above article, you added the LDAP admin user to Kerberos, what is the reason behind doing it?

In a normal windows authentication mechanism, when a user logs in from his machine, here does LDAP come into picture?

Reply

Thanks for sharing, this is a fantastic article post.Really thank you! Much obliged.

Reply

magnificent post, very informative. I wonder why the other specialists of this sector don’t notice this. You must continue your writing. I’m confident, you have a huge readers’ base already!

Reply

Hello, Neat post. There is a problem along with your website in web explorer, could check this… IE nonetheless is the market leader and a big part of other people will omit your magnificent writing due to this problem.

Reply

T?ese ar? genuinely wonderful id?as in about blogging.
You have touc?ed some nice fa?tors here.
Any way keep up wrinting.

Look into my site: tablet pcs available

Reply

I got what you mean , thanks for posting.Woh I am pleased to find this website through google. “Being intelligent is not a felony, but most societies evaluate it as at least a misdemeanor.” by Lazarus Long.

Reply

I see something really interesting about your web site so I saved to fav.

Reply

Hi this is somewhat of off topic but I was wanting to know if blogs use WYSIWYG editors or if you have to manually code with HTML.

I’m starting a blog soon but have no coding experience
so I wanted to get guidance from someone with experience.
Any help would be enormously appreciated!

Reply

I consider something really special in this website .

Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>