DekGenius.com
[ Team LiB ] Previous Section Next Section

2.2 Directories

A common misconception surrounding Kerberos and other authentication technologies is that they somehow replace directories, such as the Unix /etc/passwd file, NIS, NetInfo, or LDAP. Along the same lines, another common misconception is that directories make good authentication systems by themselves. Therefore, a distinction needs to be made between authentication, authorization, and directories. For a real-life analogy of what roles each of these components play, see the sidebar Confusing Authentication, Authorization, and Directories.

Directories contain data describing resources, such as computers, printers, and user accounts that are contained within a particular network. Directories can be as simple as a text file, such as the /etc/passwd and /etc/group files on traditional Unix systems, which list the active user accounts and their group permissions. Or a directory can be a complex LDAP directory structure, such as Microsoft's Active Directory.

Directories can contain authentication data. Authenticating "against" a directory takes two forms: a client machine can contact a directory, obtain the hashed version of the user's password, hash the password given by the user, and compare the two. This method is used by NIS, for example. The other form, employed by most LDAP authentication mechanisms, is to attempt to bind to the LDAP directory using the credentials that the user provided. If the user is granted access to the directory, the authentication is successful. The pam_ldap PAM module uses this latter method to authenticate against an LDAP directory.

Using Kerberos to handle authentication is superior to these methods for several reasons:

  • Using Kerberos tickets, users can be granted single-sign-on access to all network resources without requiring the client machine to cache the user's password. Kerberos tickets are cryptographic messages that are only valid for a relatively short period of time, typically 8-24 hours. The compromise of a user's password, on the other hand, provides an attacker the ability to masquerade as the legitimate user for a much longer period of time—specifically, until the password is changed or expires.

  • With Kerberos, the user's password is never sent in the clear over the network during the login process.

  • Kerberos defines a widely adopted and standardized protocol that is suited for authentication.

Therefore, while a directory may contain authentication information (for example, Microsoft's Active Directory stores the Kerberos database in its LDAP store), it is preferable to use Kerberos to perform authentication rather than using the directory for authentication directly.

Confusing Authentication, Authorization, and Directories

Many authentication systems also include authorization functions, so these concepts can be easily confused with each other. For example, the traditional Unix /etc/passwd file contains both authentication and authorization data. To make matters worse, it also functions as a directory! So it is very easy to get confused when reading about the differences between all of these concepts when the distinction has never been made in the past.

To help make the distinction clear, let's say that you want to get in to the hottest local nightclub. We'll examine what steps you have to take in order to gain access to the bar.

First, you are authenticated. By issuing a driver's license from the Department of Motor Vehicles (analogous to the Kerberos Key Distribution Center), the state confirms your identity and generates a license, which includes data about you. That data includes information such as your name, your birthdate, your picture, and so on. In Kerberos parlance, this ticket that you've been issued proves your identity. Anyone possessing your ticket can masquerade as you, provided that the ticket is still valid (Kerberos tickets have limited lifetimes, as we'll discuss later; usually, the lifetime is one day).

Next, you make your way to the club, license in hand. Once you arrive, the bouncer obtains your name from your license and makes an authorization decision: is your name on the guest list? The guest list acts as a primitive directory, which simply lists the people who are authorized to enter. If your name appears, then you are allowed access into the club.

In this (rather simplified) analogy, there is a clear separation between the entity that performs authentication (the state government), and the entity that performs authorization (the club bouncer). This crude analogy is intended to demonstrate that just because a user possesses a valid Kerberos ticket, he is not necessarily authorized to use any network resources.

    [ Team LiB ] Previous Section Next Section