Kerberos in Windows 2000

The Kerberos implementation in Windows 2000 is called Microsoft Kerberos because Microsoft added its own extensions. This is not to say that Microsoft Kerberos is not Kerberos v5 compatible—it is—Microsoft has just modified it in the Windows 2000 implementation. Kerberos in Windows 2000 is fully Kerberos v5-compatible and can exist and interoperate with any other Kerberos v5 realm.

The implementation of Kerberos in Windows 2000 makes use of the same processes and entities as detailed previously in the general discussion of Kerberos and provides the same two services:

• AS  The AS of the KDC is responsible for authenticating users and issuing them their TGT.

• TGS  The TGS is responsible for issuing individual session tickets that allow for network resource access by the user based on the user's TGT.

The KDC and Account Database

The KDC is located on every Windows 2000 domain controller and runs as a domain service, as shown in Figure 8.8. The KDC uses the Active Directory database as its account database. Additionally, some information about users is retrieved from the Global Catalog server. Both the KDC and Active Directory services are started automatically at server startup by the domain controller's Local Security Authority (LSA). Furthermore, both of these services run in the process space of the LSA, preventing them from being stopped while the domain controller is in operation. Just as any domain controller in the domain can perform its designated function in Windows 2000, any Windows 2000 KDC in the domain can perform its designated function.

Figure 8.8: The Kerberos KDC Service

Every Kerberos KDC has its own principal name. The name used in Windows 2000 is krbtgt, which follows the guideline given in RFC 1510. When a Windows 2000 domain is created, a user account named krbtgt is created for the KDC principal, as shown in Figure 8.9. This account is a built-in account, so it cannot be deleted, renamed, or enabled for normal user use. Even though it appears that the account is disabled, in reality it is being used by the KDC. An administrator who attempts to enable the account receives the dialog box shown in Figure 8.10.

Figure 8.9: The krbtgt Account

Figure 8.10: Attempting to Enable the krbtgt Account

Notes from the Underground…
Safe Kerberos

One of the more common actions an attacker who has compromised a system will carry out is to stop and start services of their choosing. Additionally, an attacker may install a rootkit into a system that modifies system files to mask their activities. Kerberos in Windows 2000 is not susceptible to this sort of attack due to the fact that it runs in the protected process space of the LSA. Kerberos cannot be stopped on a KDC without shutting down the entire server. This keeps the Kerberos service on the KDC safe from being compromised.

Also, all sensitive Kerberos information that a client has, such as session tickets, session keys, and their TGT are kept in a non-paged section of volatile memory (RAM). This ensures that under no circumstances will any piece of Kerberos information related to that logon session ever be placed on a permanent storage medium, such as the hard disk of the client's computer. When the client logs off at the conclusion of their session, this section of volatile memory is flushed, taking with it all Kerberos-related information.

Windows 2000 automatically generates the password for the account, which the system changes automatically on a regular basis. The key used by the krbtgt account is based on its password, just like a normal user's long-term key. The long-term key of krbtgt is used to encrypt and decrypt the TGTs it gives out. The krbtgt account is used by all KDC's in a domain.

For example, a Windows 2000 domain could have five domain controllers, each of which has its own functioning KDC, but each KDC uses the krbtgt account. This allows each KDC to encrypt and decrypt TGTs using the same long-term key. A client knows which KDC to communicate with because the client computer queries the Domain Name System (DNS) for a domain controller—typically the one that is closest to it in regards to network topology. After the client locates a domain controller, it can begin the process of becoming authenticated and get a TGT.

Exam Warning 

Make sure you understand how Microsoft implements the KDC in Windows 2000 and the specific domain user account created to act as the security principal for the KDC in Windows 2000.

Kerberos Policy

Policy for Kerberos in Windows 2000 is set at the domain level. Kerberos policy is stored within Active Directory, and only members of the Domain Admins group are allowed to change the policy. Figure 8.11 shows the options available in the Kerberos policy for the domain.

Figure 8.11: The Kerberos Policy Options

The settings included in the Kerberos policy are:

• Enforce User Logon Restrictions  When enabled, this is used to validate every request for session tickets by making sure that the client has the correct user rights for logging onto the destination server. This is enabled by default. This setting can be disabled to speed up access to the network service or resource, but this will result in a less secure setting.

• Maximum Lifetime for Service Ticket  The service ticket is the Microsoft name for a session ticket. This setting is used to configure how long a service ticket is valid for once it is issued. This is typically set for the same length as the user ticket lifetime, but does not have to be. The maximum setting for the lifetime of the service ticket cannot be more than the time specified in the maximum user ticket lifetime or less than 10 minutes. It can also be set to not expire by configuring a setting of 0 (zero) minutes. The default setting is 600 minutes (10 hours) and all settings are made in minutes.

• Maximum Lifetime for User Ticket  The user ticker is the Microsoft name for the TGT. This setting is used to configure how long the user ticket is valid for. Typically this is set to the expected amount of time that a user is logged in during a work day, but can be set to a shorter time for increased security or longer if desired. The default setting is 10 hours and can be set to never expire by configuring a value of 0 (zero) hours.

• Maximum Lifetime for User Ticket Removal  This setting controls how long a continuously renewed TGT is valid for before being removed from service. This is configured in days, with the default being seven days.

• Maximum Tolerance for Computer Clock Synchronization  This setting determines the maximum difference in time allowed between a sender and a recipient in order to prevent the replay of authenticators. This setting is configured in minutes and is set for five minutes by default. If a network's time synchronization is really good, this number may be trimmed down even lower. Conversely, poor time synchronization may require an increase in this setting. This, however, can lead to security vulnerabilities in the Kerberos implementation.

Exam Warning 

Pay careful attention to the wording of exam questions when dealing with Kerberos policy options. Do not mistake service tickets (session tickets) for user tickets (TGTs).

It is easy to change an attribute by double-clicking the attribute and changing the setting, as shown in Figure 8.12.

Figure 8.12: Changing the Maximum Lifetime for a User Ticket Renewal

Delegation of Authentication

As discussed earlier, Kerberos supports two methods of delegation: proxy tickets and forwardable tickets. Several conditions must be met in Windows 2000 to allow delegation by way of forwardable tickets to occur:

• The client's Active Directory account must be enabled for delegation

• The service's Active Directory account must be enabled for delegation

• The client computer must be running Windows 2000 in a Windows 2000 Active Directory domain

• The computer that the service runs on must be running Windows 2000 in a Windows 2000 Active Directory domain

To enable the client's user account for delegation, complete the steps outlined in Exercise 8.01.

Exercise 8.01: Configuring a Client for Kerberos Delegation

1. Click Start | Programs | Administrative Tools | Active Directory Users and Computers.

2. Locate the user account you want to enable delegation for and right-click on it.

3. Select Properties from the context menu and switch to the Account tab.

4. In the "Account options" area, scroll down until you see the "Account is sensitive and cannot be delegated" option. Ensure that this option is deselected, as shown in Figure 8.13.

   
   Figure 8.13: Configuring a User for Delegation

5. Click OK to accept any changes.

The process to configure the service for delegation is accomplished one of two ways, depending on the context in which that service is running—either under the host computer's local system account or under its own specific domain user account. Exercise 8.02 presents the process to configure delegation for a service that runs in the context of the host computer's local system account. Exercise 8.3 presents the process to configure delegation for a service that runs in the context of its own specific domain user account.

Exercise 8.02: Configuring a Local Host Service for Kerberos Delegation

1. Click Start | Programs | Administrative Tools | Active Directory Users and Computers.

2. Locate the computer account you want to enable delegation for and right-click it.

3. Select Properties from the context menu and switch to the General tab.

4. Place a check mark in the Trust computer for delegation check box, as shown in Figure 8.14.

   
   Figure 8.14: Configuring a Computer for Delegation

5. Click OK to accept any changes.

Exercise 8.03 details the process to configure a service's domain user account for delegation.

Exercise 8.03: Configuring a Domain Account Service for Kerberos Delegation

1. Click Start | Programs | Administrative Tools | Active Directory Users and Computers.

2. Locate the service's domain account you want to enable delegation for and right-click it.

3. Select Properties from the context menu and switch to the Account tab.

4. In the "Account options" area, scroll down until you see the "Account is trusted for delegation" option. Ensure that this option is selected (refer to Figure 8.13).

5. Click OK to accept any changes.

Exam Warning 

Do not confuse the different actions that must be taken to ensure delegation can take place on the network. By default, clients are already enabled for delegation due to the fact the "Account is sensitive and cannot be delegated" option is unchecked by default. Services running in the context of the local system account must have the computer trusted for delegation; services running in the context of their own domain user account need to have that domain user account trusted for delegation.

Preauthentication

Preauthentication is a Windows 2000 add-on to Kerberos that makes offline password guessing attacks very difficult. By default, the Windows 2000 KDC requires preauthentication of all client's accounts; however, this can be disabled if interoperability with another vendor's implementation of Kerberos is required. Exercise 8.04 details the process to disable preauthentication for a user's account.

Exercise 8.04: Configuring Kerberos Preauthentication

1. Click Start | Programs | Administrative Tools | Active Directory Users and Computers.

2. Locate the user account you want to enable delegation for and right-click it.

3. Select Properties from the context menu and switch to the Account tab.

4. In the "Account options" area, scroll down until you see the "Do not require Kerberos preauthentication" option (see Figure 8.13). Ensure that this option is deselected.

5. Click OK to accept any changes.

Credentials Cache

The client uses an area of volatile memory (RAM) called the credentials cache to store its TGTs, STs, and session keys. This area of memory is protected by the LSA and is never placed in the page file or any other location on the hard disk. When the client logs off the network the cache is flushed from volatile memory, thus preventing an attacker from capturing any information that could be used to defeat the security Kerberos provides. When the user logs off the system, everything in the area of memory used for the credentials cache is flushed.

DNS Name Resolution

Microsoft Kerberos depends on the DNS to find an available KDC to send the initial authentication request. All Windows 2000 domain controllers are KDCs, and the KDC is registered as _kerberos._udp.nameofDNSdomain in the DNS service location record (also called the SRV record). Clients can query for this SRV record to locate the Information Protocol (IP) address for computers running the KDC service. A client that cannot find the SRV record can query for a host record (an "A" record) using the domain name.

If a Windows 2000 computer is a member of a different Kerberos realm (a UNIX realm and not a Windows 2000 domain), it cannot look for the SRV record. In this case, the name of the KDC server is stored in the Windows 2000 computer's registry. When the computer needs to locate the KDC, the Microsoft Kerberos Security Support Provider (SSP) locates the domain name for the KDC server from the registry and then uses DNS to find the IP address for the system. The following registry key can be edited to add the Kerberos domain name to the computer (see Figure 8.15):

Figure 8.15: Manually Configuring a Kerberos Domain Name

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\Kerberos\Domains

Test Day Tip 

SRVs map a service to the hostname of a computer that offers that service. Host records (A records) map a hostname to an IP address. Windows 2000 DNS servers and Windows NT 4.0 DNS servers running Service Pack 4 or higher support SRVs. If using a BIND DNS server, it must be at least version 4.9.6 to support SRVs.

Authorization Data

The purpose of Kerberos is to verify that security principals are who they say they are, not to control access to resources. As such, Microsoft Kerberos tickets contain additional items that are not in other Kerberos implementations' tickets. Windows 2000 uses security identifiers (SIDs), just as in previous versions of Windows NT. SIDs are used to represent user accounts and groups. The SID for a user, along with any SIDs for the groups to which the user belongs, is included in tickets the client uses and is known as the Privilege Attribute Certificate (PAC). The PAC is not the same thing as a public key certificate. The user's name, also known as User Principal Name (UPN), is added to the ticket as UPN:name@domain. For example, UPN:[e-mail] is placed in a ticket to identify the user Stace.

KDC and Authorization Data

The Authorization Data field in a Microsoft Kerberos ticket contains a list of SIDs for the user, including group SIDs. The KDC retrieves this information from Active Directory and places it in the TGT given to the client. When the client requests a session ticket (or a service ticket, in Microsoft parlance), the KDC copies the data from the Authorization Data field of the TGT into the session ticket. The KDC signs the authorization data before the data is stored in the session ticket so that the LSA can detect whether the data has been modified. The LSA checks each session ticket to ensure that the signature is valid.

Services and Authorization Data

An access token is created after the credentials in a session ticket have been verified by the network server the service resides on. The PAC is extracted from the session ticket and used to construct an impersonation token that is used to access the service on the server. The impersonation token is presented to the service, and as long as the information in the PAC matches the data contained in the Access Control List (ACL) for the service, access is granted.

In Microsoft Kerberos, a session ticket is also required for access to services on local systems. The same process takes place for access to local resources; the LSA builds a local access token from the PAC contained in the session ticket.

UDP and TCP Ports

When a client sends Kerberos messages to the KDC, it defaults to using User Datagram Protocol (UDP) port 88, as long as certain criteria are met. On an Ethernet network, the maximum transmission unit (MTU) that can be carried is 1500 bytes. If the Kerberos message is smaller than 1472 bytes, Microsoft Kerberos uses UDP as the transport mechanism. If the message is between 1473 bytes and 2000 bytes, IP fragments the frame over UDP on port 88. If the Kerberos message is over 2000 bytes, it is sent by the Transmission Control Protocol (TCP) on port 88. RFC 1510 states that UDP port 88 should be used for all Kerberos messages, but since Microsoft Kerberos messages could very well be more than 2000 bytes because user and group SIDs are included, Microsoft also uses TCP port 88. A draft revision to RFC 1510 has been submitted to the Internet Engineering Task Force (IETF) proposing the use of TCP port 88, but this revision has not been included in the formal RFC yet. This modification will not have an affect on the interoperability with other Kerberos realms, as these extra pieces of information only pertain to the Windows 2000 Kerberos implementation.