[ Team LiB ]
[ Team LiB ]
7.9 More Kerberos-Enabled Packages
While Ive tried to present a sample of some of Kerberos-enabled packages, there are still many more applications that support Kerberos authentication. Many applications, like databases, file servers, and
print spool software include Kerberos authentication. With the background presented in this chapter, you will be able to enable and configure this support in those products as well.
[ Team LiB ]
[ Team LiB ]
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 principals key. A typical Ticket Granting Service principal
for a single realm looks like:
krbtgtWEDGIE.ORGWEDGIE.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:
krbtgtTWO.COMONE.COM krbtgtONE.COMTWO.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 realms 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 realms Ticket Granting Server, the
krbtgtTWO.COMONE.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.
Lets 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 others resources, and researchers dont 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 .
Kategori