Taming the Dogs of Hell

In many enterprises, Linux and Windows now live together in peace. Very often, heterogeneous networks rely on Windows-dominated office software and traditional Unix-style servers. The Active Directory service, which Microsoft introduced with Windows 2000 Server, is often used for centralized user information management.

Linux typically uses the legacy /etc/passwd system or a distributed solution such as NIS or LDAP, but if you are willing to configure a number of freely available tools and components, you can easily integrate your Linux systems into the Active Directory infrastructure.

In this article, I assume that you have an Active Directory server that manages a complete domain structure on Windows. With this, I'll show you how to configure your Linux clients to log in (authenticate), gain access (authorize), and leverage the domain infrastructure. The icing on the cake is single sign-on functionality, and the cherry on top is the ability to automatically create user directories on the client side.

The example in this article relies on the Samba project's Winbind service and Kerberos 5 for authentication. Of course, Kerberos was not invented by the software engineers in Redmond; Microsoft adopted this authentication method from the Unix world. Kerberos was originally developed at the Massachusetts Institute of Technology (MIT) in the 1980s. Both the free Heimdal [1] project and the MIT reference application [2] offer full Kerberos 5 support. Shishi [3] is another free implementation.

Well-Kept Secrets

Kerberos is a ticket-based network authentication service that relies on shared secrets. The system guards a logically separate area known as a realm, which can include a number of clients and services.

In this example, the clients and a number of services, such as a file server, run on Linux. Windows handles directory services and authentication via the Key Distribution Center. The KDC is a central component in Kerberos (Figure 1) that includes the Authentication Server (AS) and the Ticket Granting Server (TGS).

At the start of a session, each member (or principal) of the realm demonstrates its authenticity once only. To do so, the principal requests an initial Ticket Granting Ticket (TGT) from the AS. It uses this ticket to apply to the TGS for further service tickets.

What Kerberos refers to as a ticket is an electronic credential. Once a principal has received a credential, it is granted access to "kerberized" applications that require proof of identity without the need to enter a password. Users just need to enter a password to receive the TGT.

Tickets Please!

The login program requests a TGT on behalf of the client (see Figure 2). Alternatively, the kinit can issue a request after the user logs on. The AS searches Active Directory for the requesting principal. Once the AS has found the principal, it issues a TGT.

The AS then encrypts the TGT with the principal's key and returns the hash to the requesting entity. If the requesting entity is a client, the KDC extracts the key from the user's password, encrypts it, and stores the hash in its principal database. The login program, or the kinit, calculates the secret key from the password entered by the user client-side and decrypts the TGT. The password is never transmitted in the clear.

When a user needs to access a kerberized service on a network, the user presents the TGT to the TGS and requests a service ticket for the service. The TGS issues the ticket in the background. Now that the client has the service ticket, it can automatically log the user in to the requested service without asking for a password.

Kerberos tickets have a limited lifetime. The time problem makes it essential to synchronize the system time on all the computers in the realm. The Kerberos server will refuse to issue an initial ticket to a machine that is out of sync by more than five minutes.

Although you can change the maximum clock skew through the Kerberos client or the Active Directory server, it makes more sense to set up a central timeserver to allow clients to synchronize.

The clients must also be capable of resolving the Kerberos server's DNS name. If necessary, you can add a record on the central nameserver or simply maintain the static /etc/hosts file on all the systems involved in the exchange.

Installing Kerberos

After attending to the time and name resolution requirements, you can install Kerberos on your Linux clients from your distribution's packages. For the MIT variant with Ubuntu, you need the krb5-user and krb5-config packages from the Universe repository, or, if you use Fedora, krb5-workstation and krb5-auth- dialog. As an alternative, you might prefer to build the MIT sources.

To configure Kerberos, modify the /etc/kr5b.conf file. Listing 1 shows a minimal but functional configuration with the MIT package; clients need this to set up a connection to the Kerberos server. The other Kerberos implementations use more or less the same syntax.