Name Canonicalization and SASL
Chapter 8. Advanced Topics
So far, we have covered enough of the Kerberos authentication system to establish useful Kerberos realms and enable Kerberos support in applications to take advantage of a single-sign-on environment.
This chapter will prepare you to create networks with multiple Kerberos realms and interoperate
between different Kerberos implementations. It also discusses some issues to be aware of when working with multiple Kerberos implementations.
[ Team LiB ]
[ Team LiB ]
8.1 Cross-Realm Authentication
All of the Kerberos discussion so far has assumed that all users and resources on your network are located in a single Kerberos realm. However, what if there are several departments, locations, or other divisions that are under different administrative control, each with their own Kerberos realm? These users want to access not only resources in their local Kerberos realm, but also resources in the other realms as well, with a minimum of hassle. Kerberos cross-realm authentication can solve this problem.
In Kerberos, cross-realm is implemented by sharing an encryption key between two realms. The key that is shared is the Ticket Granting Service principal's key. A typical Ticket Granting Service principal for a single realm looks like:
krbtgt/WEDGIE.ORG@WEDGIE.ORG
Note that the instance is the same as the realm name. In cross-realm, two principals are created on each participating realm. For two realms, ONE.COM and TWO.COM, these principals would be:
krbtgt/TWO.COM@ONE.COM krbtgt/ONE.COM@TWO.COM
These principals have to be created on both realms, and are known as remote Ticket Granting Server principals. The Kerberos trust can be one way or both ways; since there are two separate, shared keys involved, one realm can choose to trust the other realm's tickets, but not the other way around.
When a user who is in the ONE.COM realm wishes to communicate with a Kerberized service in TWO.COM, the client program first requests a ticket for the remote realm's Ticket Granting Server, the krbtgt/TWO.COM@ONE.COM principal above. Using that intermediate Ticket Granting Ticket, the client is then able to acquire a service ticket directly for the requested service in the TWO.COM realm.
This is called direct cross-realm trust, and is the only type of cross-realm trust supported in the older Kerberos 4 protocol. In direct cross-realm trust, every two realms that wish to communicate must share a separate set of keys. Of course, this can get rather unwieldy as the number of shared keys grows exponentially with the increasing number of realms. This can be managed somewhat by building a certification path between several realms, a feature introduced with the Kerberos 5 protocol. A certification path defines realms that may be used as intermediaries when acquiring service tickets in foreign realms. Direct cross-realm requires every foreign realm be directly connected, through a shared key, to the local realm, creating a full mesh configuration between the realms. Certification paths allow multiple realms to use another realm as an intermediary, creating hub-and-spoke systems in which multiple realms share a key with a single intermediary realm.
Let's take an example. There are several universities collaborating on a project to produce workable cold fusion together with a fictitious government agency, the National Energy Research Directive (NERD). Obviously, these organizations want to utilize each other's resources, and researchers don't like to memorize numerous logins and passwords, so cross-realm Kerberos is proposed as a solution to the authentication needs of all the organizations involved. However, direct cross-realm between all of these organizations would require approximately n2 different keys, where n is the number of participating Kerberos realms. This is a management nightmare, especially if, in this example, more universities are added to the project as time goes on. A diagram of these cross-realm relationships in a full mesh configuration is shown in Figure 8-1.
Figure 8-1. Full mesh cross-realm configuration
To solve this problem, each university decides to share a set of cross-realm keys with one organization, namely the NERD government agency. Then, if a set of Kerberos clients and servers wish to
communicate between two different universities, NERD can be used as an intermediary realm.
The certification path must be encoded into each client and server's Kerberos configuration in each participating realm. Clients and servers use this information somewhat differently. Clients use the certification path to determine what KDCs to communicate with in order to reach one realm from another. Servers use the certification path to validate that incoming tickets presented for authentication have passed through a satisfactory path, and no untrusted intermediary realms were used to obtain the service ticket. This information is included in the capaths stanza of the /etc/krb5.conf file. As an example, the above trust relationship would be represented in an MIT-style /etc/krb5.conf file installed on hosts in the PRINCETON.EDU realm, as follows:
The capaths stanza defines the trust relationships necessary to reach every connected Kerberos realm.
Inside of the capaths stanza, a key-value pair exists for every participating realm, and the value is an array of more key-value pairs, defining a link in the certification chain.
Each innermost key-value pair defines two realms that are related as a link in a cross-realm trust. The key defines a destination realm in the realm certification path, and the value is either another realm, which is used as an intermediary, or a period (.) that indicates the a cross-realm key is directly shared between the realms defined by the inner key and the outer key.
Figure 8-2 depicts the cross-realm relationship described by the above krb5.conf capaths stanza, and shows the certification path that a cross-realm request would take between Princeton and Caltech. Note that since no cross-realm key is directly shared between Princeton and Caltech, the request is routed through the intermediary NERD.GOV realm.
Figure 8-2. Sample cross-realm relationship; the dotted line shows the path a request from Princeton to Caltech would take
However, this certification path method has its own downside: the distribution of a large amount of configuration information to all machines on all participating realms (not to mention the trouble involved in creating this configuration information in the first place). Therefore, Kerberos 5 also supports
hierarchical trust.
With hierarchical trust, all participating realms in the cross-realm trust are subdomains of a larger realm.
For example, a company has a Kerberos realm named COMPANY.COM. The company has several offices with their own Kerberos realms, named NEWYORK.COMPANY.COM,
PARIS.COMPANY.COM, etc. Each of these realms shares a key with the "parent" realm, COMPANY.COM.
Since NEWYORK.COMPANY.COM trusts the parent, COMPANY.COM (they share a key between them), then NEWYORK.COMPANY.COM implicitly trusts PARIS.COMPANY.COM as well, even though no explicit key is shared between the New York and Paris realms. This is simply a special case of the certification path described above; the common DNS suffix between the two Kerberos realms creates an implicit certification path between all subordinate realms and the parent realm.
8.1.1 Implementing Cross-Realm Relationships
Establishing a cross-realm trust between two Kerberos realms is rather easy. Microsoft's Active Directory will automatically create implicit trusts between member domains in a forest, so no manual configuration is needed. Those administering MIT- or Heimdal-based Kerberos realms will need to manually create the appropriate Ticket Granting Server principals to create the cross-realm trust, and if the trust is not a cross-realm or hierarchical trust, a certification path will need to be defined in each client's /etc/krb5.conf, as described above.
Each of the two shared keys involved in the cross-realm trust can have a separate secret key associated with it. Currently, the only way to enter a shared key across two MIT or Heimdal Kerberos realms is to use a password, by using the same password for one of the cross-realm principals on both realms. Since these passwords will never have to be used by a human, and the security of the trust depends on the passwords, choose highly secure passwords of at least 16 characters in length that use a combination of printable characters, generated by a good, random password-generator. As an example, let's establish a two-way cross-realm relationship between SAMPLE.COM and EXAMPLE.COM, using MIT
Kerberos. First, we must create two secure random passwords—one will be used for the krbtgt/SAMPLE.COM@EXAMPLE.COM principal and the other for the
krbtgt/EXAMPLE.COM@SAMPLE.COM principal. Now we can log into each realm through kadmin and create the principals with the passwords:
host.sample.com% kadmin
Authenticating as principal jgarman/admin@SAMPLE.COM with password.
Enter password:
kadmin: addprinc krbtgt/SAMPLE.COM@EXAMPLE.COM
WARNING: no policy specified for krbtgt/SAMPLE.COM@EXAMPLE.COM; defaulting to no policy
Enter password for principal "krbtgt/SAMPLE.COM@EXAMPLE.COM": abcd Re-enter password for principal "krbtgt/SAMPLE.COM@EXAMPLE.COM": abcd Principal "krbtgt/SAMPLE.COM@EXAMPLE.COM" created.
kadmin: addprinc krbtgt/EXAMPLE.COM@SAMPLE.COM
WARNING: no policy specified for krbtgt/EXAMPLE.COM@SAMPLE.COM; defaulting to no policy
Enter password for principal "krbtgt/EXAMPLE.COM@SAMPLE.COM": defg Re-enter password for principal "krbtgt/EXAMPLE.COM@SAMPLE.COM": defg Principal "krbtgt/EXAMPLE.COM@SAMPLE.COM" created.
host.example.com% kadmin
Authenticating as principal jgarman/admin@EXAMPLE.COM with password.
Enter password:
kadmin: addprinc krbtgt/SAMPLE.COM@EXAMPLE.COM
WARNING: no policy specified for krbtgt/SAMPLE.COM@EXAMPLE.COM; defaulting to no policy
Enter password for principal "krbtgt/SAMPLE.COM@EXAMPLE.COM": abcd Re-enter password for principal "krbtgt/SAMPLE.COM@EXAMPLE.COM": abcd Principal "krbtgt/SAMPLE.COM@EXAMPLE.COM" created.
kadmin: addprinc krbtgt/EXAMPLE.COM@SAMPLE.COM
WARNING: no policy specified for krbtgt/EXAMPLE.COM@SAMPLE.COM; defaulting to no policy
Enter password for principal "krbtgt/EXAMPLE.COM@SAMPLE.COM": defg Re-enter password for principal "krbtgt/EXAMPLE.COM@SAMPLE.COM": defg Principal "krbtgt/EXAMPLE.COM@SAMPLE.COM" created.
Remember that Access Control Lists will need to be updated so that users from one realm will be able to access resources in the other.
[ Team LiB ]
[ Team LiB ]
8.2 Using Kerberos 4 Services with Kerberos 5
Those who have Kerberos 4 services that need to be integrated into a Kerberos 5 realm need to implement the Kerberos 5-to-4 ticket translator daemon. Both MIT and Heimdal include support for this protocol, the krb524 protocol. As discussed in Chapter 3, the only limit on where the krb524 daemon can run is that the daemon must have access to the service keys for the Kerberos 4-based services for which it translates tickets.
The MIT Kerberos 5 distribution includes a separate krb524 daemon, krb524d. There are two different modes of operation that krb524d supports: master and keytab. The master mode is meant to be run on a KDC in the Kerberos realm, and reads the necessary service keys directly from the Kerberos database. If it is not possible to run the krb524d directly on the KDC, then the second mode of operation can be used: keytab. Keytab mode requires that a Kerberos keytab be installed on the machine running krb524d that includes the service keys for all of the Kerberos 4 services in the realm.
The command-line arguments to krb524d are summarized below:
# krb524d
Usage: krb524d [-k[eytab]] [-m[aster] [-r realm]] [-nofork]
Either the -k or the -m options are required. The -m option enables the master mode, as described above, where krb524d reads the necessary service keys directly from the Kerberos database on the local disk. The -k option requires an argument, namely, the keytab where the keys are stored for the Kerberos 4 services located in the Kerberos 5 realm.
As an example, let's create a service principal for a popular Kerberos 4-based service, the AFS network filesystem. We first create a service principal for AFS, ensuring that the only encryption type associated with the new principal is single DES. With MIT Kerberos, the kadmin commands to create this principal would be similar to the following:
> kadmin
Authenticating as principal jgarman/admin@UNIX.SAMPLE.COM with password.
Enter password:
kadmin: addprinc -randkey -e des-cbc-crc:v4 afs/unix.sample.com@UNIX.SAMPLE.COM
WARNING: no policy specified for afs/unix.sample.com@UNIX.SAMPLE.COM;
defaulting to no policy
Principal "afs/unix.sample.com@UNIX.SAMPLE.COM" created.
After the principal has been created, the keytab can be extracted to a file, which can be placed on the machine running the krb524d daemon.
kadmin: ktadd -k /tmp/afs.keytab -e des-cbc-crc:v4 afs/unix.sample.com@UNIX.SAMPLE.COM
Entry for principal afs/unix.sample.com@UNIX.SAMPLE.COM with kvno 3, encryption type
DES cbc mode with CRC-32 added to keytab WRFILE:/tmp/afs.keytab.
Heimdal Kerberos also includes the Kerberos 5-to-4 ticket translator daemon, but it is integrated with the rest of the KDC and does not require running a separate daemon.
[ Team LiB ]
[ Team LiB ]
8.3 Windows Issues
While the Windows implementation of Kerberos is compatible with the specifications in RFC 1510, the Microsoft implementation of Kerberos varies significantly enough from the MIT and Heimdal
implementations to warrant its own explanation. In order to provide the additional functionality required for the Windows Active Directory, as well as backwards compatibility with older Windows NT workstations, the Windows Kerberos environment differs in several important areas from its Unix counterpart.
8.3.1 Encryption Algorithm Support
The primary encryption type used in Windows is based on the RC4 stream cipher, with an MD5-HMAC algorithm used for the checksum field. This encryption type is referred to as
RC4-HMAC, and has a variable key length to support both weaker, "export" quality key lengths, as well as stronger 128-bit key lengths.
The reasoning behind this decision by Microsoft is two-fold: first, for compatibility with older Windows NT domains; and second, for political reasons. During the initial design of Windows 2000, neither DES nor triple DES were approved for export from the United States. Microsoft wanted to encourage deployment of Windows 2000; therefore, the RC4-HMAC cipher was chosen as the default Kerberos encryption type since it is the same cipher used to generate the older NT4 password hashes. This way, when an older NT4 domain is migrated to an Active Directory domain, the users' passwords continue to work without manual intervention.
Microsoft did add DES support to Windows 2000 before its release, and users created in a Windows Active Directory have both RC4 and DES encryption keys associated with their account. However, there are two situations when a DES key is not available for an account in the Active Directory. The first situation is the one discussed above, in which an NT4 domain is converted into a Windows Active Directory domain. Since the hashing algorithm only works one way, there is no way for Windows to convert the existing users' RC4 encryption keys into DES keys. The second special-case situation is when a new Windows 2000 domain is created. As part of the domain creation procedure, an
Administrator account is created as the new Domain Administrator. This account only has an RC4 key when it is initially created.
In order to add DES keys to users' accounts in both of the above situations, simply change the user's password. When a user's password is changed, the KDC will generate both RC4 and DES encryption keys for that user.
Note that even without the "Use DES encryption types for this account" checkbox checked for a user, the DES keys do exist in the Active Directory database (subject to the limitations of the previous two scenarios), but are not used by the KDC when responding to ticket requests unless the checkbox is activated.
A better solution to this is for other Kerberos implementations to adopt the RC4-HMAC encryption type into their code as well. Heimdal has recently added this support to its distribution, and MIT has incorporated full RC4-HMAC support for its Kerberos 5 1.3 release. With RC4 encryption-type support, interoperability between Unix and Windows Kerberos realms can occur without downgrading the encryption keys used to single DES.
Also note that Windows does not support salts other than the standard Kerberos 5 salt. If you have a Unix KDC that has encryption keys with other salts (such as Kerberos 4 salt or AFS salt) for
interoperability with older clients, then you may have issues when attempting to interoperate with Windows. Careful reordering of the encryption types in the configuration file of the Unix KDC can help alleviate this problem, but it is recommended to use only Kerberos 5 salt and encryption types when interoperating with Windows.
8.3.2 Cached Login Credentials
Many Windows machines are mobile, and do not have a fixed network connection. For example, laptops can spend most of their time disconnected from a network; yet, end users expect the ability to log into their own computers, even when no network connection is present. Traditionally, systems that require successful Kerberos authentication for local access, as Active Directory does, require a stable network connection to operate, since communication with the KDC is required to authorize logon.
Microsoft provides for disconnected login to domain accounts through a cached credentials feature.
When a user logs into a Windows 2000, XP, or 2003 host, the Local Security Authority (LSA) derives a password verifier and saves this verifier into the local machine's registry. Later, if the user is
disconnected from the network or the domain controller is otherwise unavailable, the local system will authorize access if the username and password match the saved credentials stored on the local disk.
The cached credentials are stored in the local machine's registry inside of the
HKEY_LOCAL_MACHINE\Security\Cache key, which contains sub-keys NL$1 to NL$10. The last 10 users' login username and password verifier are stored as the values of each of these keys.
Notice that I have been referring to a password verifier, and not password or password hash. The password verifier is a hash of the password hash, so the password verifier cannot be used to derive either the original password or a password hash. The verifier therefore contains just enough data that it is able for the local login process to take in a password, run a hashing algorithm over it twice, and compare to the verifier.
For security reasons, Windows restricts access to this registry key to the local SYSTEM account. To view these keys as Administrator, launch the regedt32 application, navigate to HKEY_LOCAL_MACHINE\Security, and select Security Permissions. Set the checkbox for read permission for the Administrators group.
Unfortunately, certain situations cause Windows to provide no indication to the end user when the system authenticates the user through a cached credential verifier. When a user is verified against a password verifier located in the cache, the login process cannot acquire any initial tickets for the user.
Unfortunately, certain situations cause Windows to provide no indication to the end user when the system authenticates the user through a cached credential verifier. When a user is verified against a password verifier located in the cache, the login process cannot acquire any initial tickets for the user.