Windows Server 2003 Security Infrastructures: Core Security Features (HP Technologies)

Now that we have explained the basic Kerberos protocol, we can discuss some real-world Windows Kerberos logon examples. In this section we will look in detail at both local and network logon features in single and multiple domain environments and in a multiple forest scenario.

5.3.1 Logging on in a single domain environment

Typical examples of logon method in a single domain environment are:

• Alice is logging on from a machine that is a member of the domain where Alice’s user account has been defined (this is a local logon method).

• Alice accesses a resource located on a machine that is a member of Alice’s logon domain (this is a network logon method).

Local logon process

Figure 5.11 shows what happens during a local logon process in a single domain environment.

Figure 5.11: Local logon process in a single domain environment.

Everything starts when Alice presses <CTRL><ALT><DEL> and chooses to log on to the domain.

1. The client Kerberos package acting on behalf of Alice tries to locate a KDC service for the domain; it does so by querying the DNS service.^[10] The Kerberos package will retry up to three times to contact a KDC. At first it waits 10 seconds for a reply; on each retry it waits an additional 10 seconds. In most cases a KDC service for the domain is already known. The discovery of a domain controller is also a part of the secure channel setup that occurs before any local logging on.

2. Once the DC is found, Alice sends a Kerberos authentication request to the DC. This request authenticates Alice to the DC and contains a TGT request (KRB_AS_REQ).

3. The Authentication Service authenticates Alice, generates a TGT, and sends it back to the client (KRB_AS_REP).

4. The local machine where Alice logged on is—just like any other resource—a resource for which Alice needs a ticket. Alice sends a ticket request to the DC using her TGT (together with an authenticator) (KRB_TGS_REQ).

5. The TGS of the DC checks the TGT and the authenticator, generates a ticket for the local machine, and sends it back to Alice (KRB_TGS_REP).

6. On Alice’s machine, the ticket is presented to the Local Security Authority, which will create an access token for Alice. From then on, any process acting on behalf of Alice can access the local machine’s resources.

Network logon process

When Alice is already logged onto a domain and wants to access a resource located on a server within the same domain, a network logon process will take place. In this case, the logon sequence is as follows (see Figure 5.12):

1. Alice sends a server ticket request to the DC using her TGT (together with an authenticator) (KRB_TGS_REQ).

   Figure 5.12: Network logon process in a single domain environment.

2. The TGS of the DC checks the authenticator, generates a server ticket, and sends it back to Alice (KRB_TGS_REP).

3. Alice sends the ticket (together with an authenticator) to the application server (KRB_AP_REQ).

4. The application verifies the ticket with the authenticator and sends back his or her authenticator to Alice for server authentication (KRB_AP_REP).

Disabling Kerberos in migration scenarios

In certain migration scenarios it may be necessary to disable the Kerberos authentication protocol on your Windows Server 2003 domain controllers. Remember from Chapter 4 that for Windows 2000 Professional and later clients, the first authentication protocol of choice is always Kerberos—at least if the client is talking to a Windows 2000 or later DC.

Imagine the following migration scenario: You have migrated all your client platforms to Windows XP and you upgraded one of your Windows NT4.0 DCs to Windows Server 2003—all the remaining DCs are still on NT4.0. In this scenario the one and only Windows Server 2003 DC may become overloaded by Kerberos authentication traffic because all Windows XP clients try to authenticate against it. Also, if this DC becomes unavailable, the clients cannot be authenticated anymore. Once a client has been authenticated by a Kerberos KDC it will not fall back to NTLM and NT4 DCs. This is a typical scenario where you may want to temporarily disable the Kerberos authentication protocol on the Windows Server 2003 DC.

To disable Kerberos, Microsoft provides a registry hack (the hack is available from Windows 2000 Service Pack 2 onward). The hack is called NT4Emulator (REG_DWORD) and should be added to the HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/Netlogon/ Parameters registry key of the Windows 2000 SP2 or later DC and set to value 1.

The creation of this key on the Windows 2000 SP2 or later DC creates another problem because it will make it impossible to manage the AD using any of the MMC-based AD management tools. To get around this problem, you must make a registry change on the clients from which you want to use the AD management tools. Add the NeutralizeNT4Emulator registry value (REG_DWORD) in the HKEY_LOCAL_MACHINE/System/Current- ControlSet/Services/Netlogon/Parameters registry key and set it to value 1.

The role of SPNs

One of the great features of Kerberos is its support for mutual authentication. The enabling technologies for mutual authentication are the Kerberos protocol itself, User Principal Names (UPNs), and Service Principal Names (SPNs). The UPN and SPN concepts were introduced in Chapter 2. In the following we will look at how SPNs are used during the Kerberos authentication exchanges.

Let’s take the example of a network logon process: A user decides to access a file on another server during his or her logon session. In this example the following SPN-related events will occur during the authentication exchanges:

• The Kerberos software on the client side constructs a Kerberos “KRB_TGS_REQ” message, containing the user’s TGT and the SPN of the service that is responsible for the file the user wants to access. This message is sent to the user’s domain controller. A Kerberos client can always construct a service’s SPN—how this works was explained in Chapter 2.

• The KDC queries the AD^[11] to find an account that has a matching SPN (this process is also known as “resolving” the SPN). The service’s SPN must be unique in the AD. If more than one account is found with a corresponding SPN, the authentication will fail.

• Given the service account corresponding to the SPN and the associated master key, the KDC can construct a service ticket and send it back to the client. (This is the ”KRB_TGS_REP” message.)

• In the next step the client sends a “KRB_AP_REQ” message to the file server (including the service ticket and a Kerberos authenticator).

• Finally, the service will authenticate back to the client (this is the “KRB_AP_REP” message). This is where the real mutual authentication happens.

5.3.2 Logging on in a 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.

Figure 5.13: Local logon in a multiple domain environment.

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.^[12] 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.

  • 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 interdo- main 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):

Figure 5.14: Network logon in a multiple domain environment.

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

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

Figure 5.15: Effect of a shortcut trust on multiple domain logon traffic.

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.

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

Transitive Trusts in Domains Containing Windows 2000, Windows Server 2003, and NT 4.0 DCs Be careful when relying on transitive trust in domains containing both Windows 2000 or Windows Server 2003 and NT 4 DCs. Because NT4 domain controllers do not support Kerberos, transitive trust will only work if a user is authenticated by a Windows 2000 or later DC.

Consider the network logon example illustrated in Figure 5.16. A user defined in NA logged on from a Windows 2000 workstation in NA is accessing a resource in the “Belgium” domain (be.emea.compaq.com). There is a transitive trust between the NA and Europe and between the NA and Be domains. In this scenario, authentication will fail if the DC authenticating the user in the Be domain is an NT4 DC. Because of the NT4 DC, authentication will fall back to NTLM. NTLM does not understand transitive trust and requires a “real” trust.

Figure 5.16: Transitive trusts in mixed-mode domains.

What does this mean? When the NT4 domain controller receives the authentication request from the user in NA, it cannot create a trust path back to the Be domain because NT4 and NTLM can only deal with “single hop” trusts. NTLM would work in this scenario if an “explicit” trust relationship was defined between the NA and Be 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 interdo- main 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.

5.3.3 Multiple forest logon process

In Windows Server 2003, Microsoft has added additional information in the TDO account objects to enable interforest authentication traffic. Let’s look at an example that shows how Windows Server 2003 uses the extra information stored in the TDO to route Kerberos authentication requests during a cross-forest resource access.

In the example (illustrated in Figure 5.19), a user that is logged on to the emea.compaq.com domain (the user and machine accounts are defined in emea.compaq.com) wants to access a resource located on a server in the us.hp.com domain. Both forests are at functionality level 2, and a bidirectional forest trust relationship has been set up between them. From a Kerberos point of view, the user is already logged on to the emea.compaq.com domain and has a valid TGT. The remote resource is identified using an SPN of the following format: <servicename>/us.hp.com.

Figure 5.19: Forest trust authentication flow.

In this example the authentication requests will be routed as follows:

1. The user’s machine contacts the local DC to request a Kerberos service ticket for the resource in the us.hp.com domain. The DC in emea.compaq.com cannot find an entry for the remote service in its local domain database and asks a GC server in the emea.compaq.com for help. The GC suspects (based on the DNS suffix) that the service is located in the hp.com forest, and it sends this routing hint to the DC and tells the DC to refer the user to a DC in the compaq.com root domain.

2. The user’s machine contacts a DC in the root domain of the compaq.com forest. This DC refers the user to a DC in the root domain of the hp.com forest.

3. The user’s machine contacts a DC in the root domain of the hp.com forest. The DC of the hp.com forest double-checks with the local GC whether the service is in his or her forest. After validation it refers the user to a DC in the us.hp.com domain.

4. The user’s machine contacts a DC in the us.hp.com domain. This DC can issue a service ticket to the user for the resource in the us.hp.com domain.

5. The user uses the service ticket to authenticate to the resource server in the us.hp.com domain.

^[10]Windows 2000 and Windows Server 2003 publish two Kerberos-specific SRV records to DNS: _kerberos and _kpasswd. The list of all published SRV records can be found on a domain controller in the “%windir%\system32\config\netlogon.dns” file. The SRV DNS records are created automatically during the domain controller setup (as part of the dcpromo process).

^[11]In the first place it will query the local domain Naming Context of the user’s authentication DC; after that, it will query the global catalog.

^[12]This is because only a KDC of NA knows the workstation’s master key.