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.
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.
|
|