LDAP and Kerberos

Two of the core problems in running a IT environment are authentication and authorization. Authentication is the process of proving one's identity to others, and authorization is the process of granting rights to the individual based on the proven identity. Although the 2 tasks are clearly defined, they are deeply related. The best tools for authorization and authentication are LDAP and Kerberos; which can work hand in hand and produce a nice and secure IT infrastructure. However, these tools are not fool safe and some understanding and configuration are needed.

LDAP

LDAP fundimentally is a database. It is a database built for a special purpose, which is to store a directory and associated data. Some rigidly defined schemas are provided so the data stored within are always consistant and consise. Among other things, group memberships, login shells and home directories are stored here so it can play a important role in the authroization process. Another good thing about using a centrally managed database is that it provide the same data for all hosts, services and users which is very nice for the administators.

LDAP can also store user password (as a security hash in most cases) so it can also act as a authentication backend. If password matches, LDAP can bind the user to a identity (DN in LDAP jargon); authentication frontends can leverage this capability so all passwords can be centrally stored and unified; users only need to remember one password to access all services.

Kerberos

Kerberos is a tools for a single purpose, which is authentication. It aims to solve the following problems:

• Not only users need to prove their identity, services need to do the same as well. (Rogue services that harvest password and other user information are not good)
• Access shall have a time limit. (Shells left open for indefinitly are not good)
• Transimission of password, even in a encrypted channel, is not secure.
• Storing of password, even in an one way hash, is not secure.
• Users don't want to type passwords, even the same one, repeatly to access multiple services. (Single Sign On rules)

Their interaction

One can use LDAP or Kerberos, but for the best results you want to use Kerberos for authentication and LDAP for authorization. The tools can run seperately fufilling their jobs; or they can have stronger interactions:

1. Kerberos can use LDAP as a database backend.
2. LDAP can be kerberosized, which mean its access can be authenticated by kerberos
3. LDAP can use kerberos as a password checker, so simple bind still works, now with the kerberos password

1 does not provide new functionality; and unless you have a very large domain, one KDC with builtin database is good enough. So let's skip that to avoid unnecessary complication. 2 is important because LDAP contains sensitive imformation; we want to make sure the authentication is secure.

Although 3 seems to downgrade kerberos back to simple password checker, it is actually very important:

• Many services are not kerberosized, you still want to use the same password at least
• It provides a smooth migration path, so services can gradually become kerberosized
• Kerberosized services need kerberosized clients, which may not be available to your users

There is one downside, which is you cannot change password through the LDAP bridge (or any other bridge). It would be very insecure anyway. LDAP is not the only way to use kerberos as password checker, PAM and SASL are 2 other ways. However, LDAP is widely supported, for example in web services.

To configure LDAP and Kerberos is not easy and beyond the scope of this article.

Pointers to documents

Documents on how to setup LDAP (OpenLDAP) and Kerberos (MIT Kerberos) can be found in their websites:

• http://www.openldap.org
• http://web.mit.edu/kerberos

Those documents are a little hard to follow though. There are some howtos on the web, one of them is:

• http://www.rjsystems.nl/en/2100.php

Services and kerberos

Services that has to use Kerberos

OpenAFS

OpenAFS has to use Kerberos for authentication. Authorization is not based on LDAP though, it has it own authorization backend.

Services that can use Kerberos

The following services can be configured to use kerberos, and is recommended to do so.

PAM (Linux Login)

Actually login is half kerberos in this way. It use PAM, which takes passwords but verify the password with kerberos and grant you a ticket so you are in. If your ticket expired, you are still in the system, but without a ticket.

LDAP

You have to have a ticket first (using kerberos's kinit or Linux login), and then you can access LDAP as the identiry proven.

NFS v4

With Kerberos identity (tickets) you can access NFS v4 that is configured with kerberos. Authorization (group membership) is often still done with LDAP.

SAMBA

Like NFS v4, Samba can use kerberos.

SSH

Like PAM, it can check password with kerberos and grant you access and a ticket. Better yet the ticket can be forwarded so once you are in you can login to other similiar configured host without a password. If you use public key to login then you will not have a ticket so you will have to kinit to get one.

Services that can use Kerberos, but likely not

Some services can be configured to use kerberos authentication, however due to the ubiquitousness of clients that do not support kerberos, the use of kerberos is impractical:

• SMTP
• IMAP
• XMPP

Services that does not support Kerberos

Most web services do not support Kerberos. So most likely you have to rely on the LDAP bridge.

Webauth

webauth is a framework for web services to use kerberos as the authentification method. It is still SSL/cookie based; so it is very compatible with the current network environment, at the same time no more secure than simple password authentification. The real benifit is single sign on for all participating web services; too bad it is not widely used.

The documents is at: http://webauth.stanford.edu/weblogin-config.html To use webauth you need to have:

• webkdc, which is a module running in apache. It hands out security cookies based on info obtained from kerberos
• weblogin, which is a bunch a CGI scripts that handle login/logout/pwchange for the users. It communicates with the webkdc in the backend. weblogin is commonly run on the same apache server.
• web services using webauth. By using webauth the services redirect the login/louout/pwchange requests to weblogin, and once logged in, the web services automatically have the username setup from an env variable by the webauth module. Also requires apache.

Do you have kerberos

Easy enough on the commandline:

derek@kclient:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: derek@SHANNON-DATA.COM

Valid starting       Expires              Service principal
10/09/2015 11:11:39  10/09/2015 21:11:39
krbtgt/SHANNON-DATA.COM@SHANNON-DATA.COM
renew until 10/10/2015 11:11:39
10/09/2015 11:11:48  10/09/2015 21:11:39
ldap/kerb.shannon-data.com@SHANNON-DATA.COM

derek@kclient:~$ ldapwhoami
SASL/GSSAPI authentication started
SASL username: derek@SHANNON-DATA.COM
SASL SSF: 56
SASL data security layer installed.
dn:uid=derek,ou=people,dc=shannon-data,dc=com

Watch out for the expiration:

derek@kclient:~$ krenew
krenew: error renewing credentials: Ticket expired

If that happens, you have to login again. There are ways for automatic renewal, but even that can be

Summary

LDAP and Kerberos combined is nice and secure. The setup is not easy and to use it you need to get used to a few things.