The following excerpt, courtesy of Elsevier Digital Press, is from Chapter 5 of the book "Windows Server 2003 security infrastructures" written by Jan De Clercq. Click for the complete book excerpt series or purchase the book.
Logging on to Windows using Kerberos:
Multiple domain environment
Typical examples of scenarios where a multiple domain logon process occurs are the following:
- Alice is logging on from a machine member of a different domain than the one where Alice's account has been defined (this is a local logon process).
- Alice is accessing a resource located on a machine that is a member of a different domain than the one where Alice initially logged on (this is a network logon process).
In the following examples, we will frequently use the concepts "referral ticket" and "inter-realm key." These concepts will be explained in more detail in the section on "multiple domain logon: under the hood."
Local logon process
Figure 5.13 shows a typical multidomain environment, consisting of a parent domain hp.com and two child domains, North America (NA) and Europe. In the local logon example, Alice's account is defined in the Europe domain. Alice logs on from a workstation whose account is defined in the NA domain.
The local logon process can be broken down into the four following steps:
- Step 1: AS exchange (KRB_AS_REQ and KRB_AS_REP):
- To log on Alice, a TGT request is sent to a KDC in Europe.hp.com.
- The AS Request is sent to a KDC in Europe.hp.com. The selected KDC will sent back the AS Reply. Only a KDC of Alice's account domain can authenticate Alice (Windows credentials are never replicated between the domain controllers of different domains).
- Steps 2, 3, and 4: TGS exchanges (KRB_TGS_REQ and KRB_TGS_REP):
- To request a ticket for Alice to work on the NA workstation, a TGS request is sent to the KDC of Europe.hp.com.
- The KDC of Europe.hp.com cannot issue a ticket that allows Alice to work on a workstation in NA. Only a KDC of NA can return such a ticket. (This is because only a KDC of NA knows the workstation's master key.) Therefore, the TGS reply contains a referral ticket to the domain closest to NA.hp.com (from a DNS point of view) and with which NA.hp.com has a real (nontransitive) Kerberos trust. In this example, this is hp.com.
Figure 5.13 Local logon in a multiple domain environment.
- On receiving the referral ticket, Alice locates a KDC of the intermediary domain hp.com and sends a TGS request including the referral ticket to that KDC.
- The KDC in hp.com decrypts the referral ticket using an interdomain key shared between Europe.hp.com and hp.com. The KDC detects that the referral ticket contains a ticket request for a ticket for a workstation in NA. The KDC checks on the domain closest to NA.hp.com from hp.com's point of view and sends Alice a referral ticket to this domain.
- Alice asks a KDC of NA.hp.com for a ticket for the local workstation. Finally, the KDC of NA.hp.com will send Alice a TGS reply with a valid ticket for the workstation.
The amount of interdomain authentication traffic occurring in this scenario should not be overestimated for several reasons:
- The size of Kerberos tickets is relatively small.
- Tickets have a lifetime and are cached.
- The referral traffic does not occur for every resource access.
An interesting side note is to look at what happens if at some point in this exchange, the administrator of the Europe domain decides to disable Alice's account. The answer to this question is pretty straightforward: The KDC of Europe will continue to issue tickets as long as the original TGT is valid. The disabled account will only be detected when Alice tries to get a new TGT.
Network logon process
Let's look at what happens with a local logon process in a multidomain environment. Again, we are using the example of a parent domain and two child domains. In the following network logon example, Alice is logged on to the NA domain (Alice and computer account are defined in the NA domain). Alice wants to access a resource hosted on a server in the Europe domain.
The network logon process can be split into the following four steps (as illustrated in Figure 5.14):
- Steps 1, 2, and 3: TGS exchanges:
- Before Alice can contact the KDC in realm Europe.hp.com, she must have a valid ticket to talk to the KDC of that domain. Because there is no direct trust between Europe.hp.com and NA.hp.com, Alice must request the ticket via an intermediary domain.
- Alice first tries to request a ticket for the KDC of the domain closest to the Europe.hp.com domain; this is hp.com. Because there is a direct trust between NA.hp.com and hp.com, Alice can request this ticket to her own KDC. The KDC will return a referral ticket that is encrypted with the interdomain key shared between NA.hp.com and hp.com.
- Armed with this referral ticket, Alice can send a TGS request to the KDC of the hp.com domain, requesting a ticket for the KDC of the Europe.hp.com domain. Because there is a direct trust between hp.com and Europe.hp.com, the KDC of hp.com can answer this request. The returned referral ticket will be encrypted with the interdomain key shared between hp.com and Europe.hp.com.
Figure 5.14 Network logon in a multiple domain environment.
- With this referral ticket, Alice finally can send a TGS request to a KDC of the Europe.hp.com domain to request a ticket for the target file server.
- Step 4: Application Server Exchange:
- With the ticket she received from the target server's KDC, Alice can send an authentication request (consisting of the ticket and an authenticator) to the target server.
- During the last step, the target server will also authenticate back to Alice.
The effect of shortcut trusts on multiple domain logon traffic
A typical scenario where you would create a shortcut trust is a Windows Server 2003 domain tree where a massive amount of authentication traffic occurs between two domains that are logically linked together using a transitive trust (such as the example shown in Figure 5.15). The shortcut trust example illustrated in Figure 5.15 shows how the number of referrals is reduced and how the trust path used during authentication is shortened. Note that the KDC in the user domain can detect the existence of shortcut trust when querying the AD. It has enough intelligence to refer Alice directly to the KDC in the resource domain.
In the example illustrated in Figure 5.14, Alice would go through the following steps to access the resource located in the Europe domain when a shortcut trust is defined between the Europe and the NA domains:
- Step 1: Alice uses her TGT to obtain a ticket from the KDC in the NA domain for the resource server in the Europe domain. The KDC in the NA domain is not the authoritative KDC for the resource server's Europe domain, so the KDC in the NA domain refers Alice to the domain closest to the target domain with which the NA domain has a Kerberos trust relationship. This domain is Europe.
Figure 5.15 Effect of a shortcut trust on multiple domain logon traffic.
- Step 2: The KDC in the Europe domain is the authority for the resource server's Europe domain, so The KDC in the Europe domain can generate a ticket for Alice.
- Step 3: Alice uses the ticket from the KDC in the Europe domain to access the resource server.
Figure 5.16 Transitive trusts in mixed-mode domains.
Multiple domain logon process: Under the hood
In this section we will explain some of the concepts behind the multiple domain logon process: referral tickets and the KDC's Authentication Service (AS) and Ticket Granting Service (TGS). To fully understand the multiple domain logon process, we will also introduce a special Kerberos principal -- the krbtgt principal.
We will not come back to the concepts of trusteddomain account object (TDO) and interdomain secret. To enable interdomain authentication, every domain that is trusted by another domain is registered in the domain's AD domain naming context as a security principal. These principals are also known as TDOs. The TDO's master key is often referred to as an interdomain secret. TDOs were also explained in Chapter 3.
Interdomain authentication traffic (the referral tickets mentioned before) are secured using the master key and the session key of the TDO principals. Like for any other account, the domain trust account's master key is derived from the account's password. The creation of the TDOs and their master keys can happen automatically during the dcpromo process or manually when an administrator explicitly defines a trust relationship.
To explain the use of the krbtgt account, we must first explain why the Kerberos KDC is made up of two subservices: the Authentication Service (AS) and the Ticket Granting Service (TGS). The services offered by a Kerberos KDC can be split into two service categories; each subservice has a set of different tasks:
- The Authentication Service authenticates accounts defined in the domain where the AS is running and issues TGTs for these accounts.
- The Ticket Granting Service issues service tickets for resources defined in the domain where the TGS is running.
The AS and TGS share a secret that is derived from the password of the krbtgt principal, which is the security principal used by the KDC. Its master key will be used to encrypt the TGTs that are issued by the KDC. The krbtgt account is created automatically when a Windows 2000 or Windows Server 2003 domain is created. It cannot be deleted and renamed. Like for any other account, its password is changed regularly. In the Windows 2000 and Windows Server 2003 Users and Computers snap-in, this account is always shown as disabled.
Now that we have explained the TDO, interdomain secret, and krbtgt concepts, let's look once more at how the multiple domain logon process works. A basic rule in Kerberos is that to access a resource a user needs a ticket. How can Alice get a ticket for a resource contained in a domain different from Alice's definition domain? Let's once more take the example of Alice defined and logged on in domain na.hp.com, who decides to access a resource in europe.hp.com (as illustrated in Figure 5.17).
Figure 5.17 Multiple domain logon process revisited.
In this scenario, the KDC of na.hp.com would issue a referral ticket to Alice to access hp.com. What exactly is a referral ticket? A referral ticket is a TGT that Alice can use in domain hp.com to get a ticket for the resource in that domain. The KDC of na.hp.com can issue such a TGT because hp.com is a security principal [it has a TDO, Trusted Domain Object, account (see Chapter 3)] in his or her domain. How can the KDC of hp.com trust a TGT that was issued not by itself, but by the KDC of na.hp.com? The KDC of hp.com will decrypt the TGT with the interdomain secret of its TDO account in na.hp.com to retrieve the session key—it will then use this session key to validate the associated Kerberos authenticator. If the authenticator is valid, the KDC will consider the TGT trustworthy. The same things will happen when hp.com issues a referral ticket for Alice to authenticate to a domain controller in europe.hp.com.
The referral process we just explained relies heavily on the AD and more particularly on the global catalog (GC). First, it uses the GC to find out, given the SPN, in which domain the resource is located, and thus which domain controller can issue a ticket to access the resource. Then it uses the AD to find out the domain closest to the target domain to which Alice should be referred.
Figure 5.18 explains the process outlined in the previous sections a bit more in detail and using UNIX Kerberos terminology: It illustrates an inter-realm (interdomain) Kerberos authentication exchange between the North and the South realms. In the example of Figure 5.18, Alice wants to access a resource service in the North realm. In the UNIX Kerberos terminology, they call the Windows TDO accounts from the previous example Remote Ticket Granting Service (RTGS) accounts: Figure 5.18 shows that there is an RTGS account for North in the South realm and vice versa.
Figure 5.18 Multiple domain logon process: under the hood.
Click for the next excerpt in this series: Logging on to Windows using Kerberos: Multiple forest logon process.
This was first published in October 2004