[ Team LiB ]
10.4 Kerberos Referrals
As originally implemented in MIT Kerberos 5, each Kerberos client requires detailed configuration information about all realms the client participates in. With Unix clients, the information is coded in the
etckrb5.conf file. This file must be kept up to date and distributed to all clients, which, in large and complex network environments, can quickly become an unwieldy and unmanageable task. Furthermore,
machines that are not centrally managed or mobile machines such as laptops are even more problematic, as distributing changes to the Kerberos configuration files to these machines is nearly impossible.
Microsoft recognized the need for a new method for handling this configuration information in a centralized place when it implemented Kerberos in its Windows 2000 operating system, and created a
system by which the KDC can provide clients correct replies, even when queries are misdirected or malformed. Through this mechanism, clients only require minimal configuration, enough to find their local
Kerberos realm, and all queries are directed to the local KDC, even cross-realm queries destined for a foreign Kerberos realm. The Kerberos support in Microsofts Windows 2000 and later operating
systems includes support for—and, indeed, depends on—the functioning of Kerberos referrals for Windows domain operations.
There are three classes of information that the Microsoft implementation of Kerberos referrals handles for Kerberos clients: user and service principal name canonicalization through the AS and TGS
exchanges respectively, and cross-realm trust relationships. Extensions to the Kerberos protocol are used to provide this capability and retain backwards compatibility with implementations that do not
understand Kerberos referrals.
But first, what is name canonicalization? Both people and hosts can be known by several names, such as in the case of hostname aliases or multihomed hosts. Each user can have several names associated with
him as well, such as his email address or his Kerberos principal name. Since Kerberos associates a single principal with a single key, it is required that these names be changed into a normalized format and
name, so that there is a single Kerberos principal that refers uniquely to a given user or host. For example, a host with several IP addresses and several hostnames must be assigned a single official
hostname. This hostname is referred to as the hosts canonical hostname. Kerberos referrals move the burden of name canonicalization from the client and DNS to the KDC.
10.4.1 User Principal Canonicalization
KDC-side user principal canonicalization provides for both user and administrator convenience. Similar to passwords, users want to remember only one identifying principal. For example, a users email
address may be different than his Kerberos principal name. Furthermore, the Kerberos principal name associated with the user may change if he moves between departments, while his email address stays the
same.
Therefore, Kerberos referrals provide a new field in the AS exchange for clients to send an alternative name when acquiring the initial TGT. When the KDC receives an AS request with this field filled in, the
KDC will search a directory to map the user name given to a principal that exists in the local Kerberos database. If the user does not exist in the local realm, the KDC may instead use the cross-realm referral
[ Team LiB ]
[ Team LiB ]
Kategori