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

5.5.1 Kerberos GPO settings

The Windows Server 2003 Account Policies [Part of the Group Policy Object (GPO) computer configuration] include a special subfolder for Kerberos-related policy settings (illustrated in Figure 5.34). It contains the following GPO entries:

Figure 5.34: Kerberos-related GPO settings.

• Enforce user logon restrictions: This setting enforces the KDC to check the validity of a user account every time a ticket request is submitted. If a user does not have the right to log on locally or if his or her account has been disabled, he or she will not get a ticket. By default, the setting is on.

• “Maximum lifetime for service ticket”: In Microsoft terminology, a service ticket is a plain Kerberos ticket. Its default lifetime is 10 hours.

• “Maximum lifetime for user ticket”: In Microsoft terminology, a user ticket is a Kerberos TGT. Its default lifetime is 10 hours.

• “Maximum lifetime for user ticket renewal”: By default, the same ticket [service or user ticket (TGT)] can be renewed up until 7 days after its issuance. After 7 days, a brand-new ticket has to be issued.

• Maximum tolerance for computer clock synchronization: This is the maximum time skew that can be tolerated between a ticket’s time- stamp and the current time at the KDC. Kerberos is using a time- stamp to protect against replay attacks. Setting this setting too high creates a bigger risk for replay attacks. The default setting is 5 minutes.

These Kerberos policies can only be set on a per-domain basis (the same is true for account lockout policies and password policies). You cannot define, for example, different Kerberos account policy settings per individual organizational unit (OU).

Another Kerberos-related GPO entry is located in Local policies\user rights assignment: “enable computer and user accounts to be trusted for delegation” sets the “trusted for delegation” property of user and computer objects in a domain, site, or organizational unit. Kerberos delegation was explained earlier in this chapter.

5.5.2 Kerberos-related account properties

Every Windows 2000 user account has a set of Kerberos-related properties. Most of them are related to Kerberos delegation, and one is related to the use of preauthentication.

Every user account has the property “Account is sensitive and cannot be delegated.” Every machine account has a special delegation tab in its properties that can be used to define machine-related Kerberos delegation settings. This is a brand-new tab in the machine properties that was not available in Windows 2000. The details behind the machine-related delegation settings were explained in Section 5.4.1. One more point worthy of mentioning is that domain controllers are by default trusted for delegation. If a user account has the “account is sensitive and cannot be delegated” property set, the administrator instructs the KDC not to issue any forwardable tickets to that particular user account.

The “Use DES encryption types for this account” account property changes the default Kerberos encryption type from RC4 to DES (as explained in Section 5.4.3).

Every user account also has a “Do not require Kerberos preauthentication” property. This setting must be enabled when the account is used in a Kerberos implementation or application that supports preauthentication. This is usually the case in UNIX Kerberos implementations. Windows Kerberos preauthentication was discussed earlier in this chapter.

5.5.3 Kerberos transport protocols and ports

RFC 1510 defines that a Kerberos client should connect to a KDC (port88) using the connectionless UDP protocol. Microsoft Kerberos by default uses UDP. Microsoft Kerberos can also use TCP to take advantage of TCP’s bigger Maximum Transmission Unit (MTU) capacity. Microsoft uses TCP if the ticket size is bigger than 2 kB. Any ticket fitting in a packet of 2 kB is sent using UDP, which has a 1,500-octet MTU limit. The Windows 2000 Kerberos ticket can easily grow beyond this limit if it is carrying a large PAC field—this can, for example, occur when a user is a member of a large number of groups.

The default 2-kB limit can be changed using the following registry hack. Setting this value to 1 will force Kerberos to use TCP all the time.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa \Kerberos\Parameters Value Name: MaxPacketSize Data Type: REG_DWORD Value: 1—2000 (in bytes)

Kerberos uses port 88 on the KDC side and a variable port on the client side. If your Kerberos clients communicate only with KerberosV5 KDCs (the Kerberos version used in Windows 2000 and Windows Server 2003), it is enough to keep port 88 open on your firewall. If they communicate with KerberosV4 KDCs, you must also open port 750. Table 5.10 gives an overview of all Kerberos-related ports.

5.5.4 Kerberos time sensitivity

Time is a critical service in Windows 2000 and Windows Server 2003. Timestamps are needed for directory replication conflict resolution, but also for Kerberos authentication. Kerberos uses timestamps to protect against replay attacks. Computer clocks that are out of sync between clients and servers can cause authentication to fail or extra authentication traffic to be added during the Kerberos authentication exchange.

To illustrate the importance of time for Kerberos authentication, let’s look at what really happens during a KRB_AP_REQ and KRB_AP_REP Kerberos exchange:

1. A client uses the session key it received from the KDC to encrypt its authenticator. The authenticator is sent out to a resource server together with the ticket.

2. The resource server compares the timestamp in the authenticator with its local time. If the time difference is within the allowed time skew, it goes to step (4). By default, the maximum allowed time skew is 5 minutes—this setting can be configured through domain-level GPOs.

3. If step (2) failed, the resource server sends its local current time to the client. The client then sends a new authenticator using the new timestamp it received from the resource server.

4. The resource server compares the timestamp it received from the client with the entries in its “replay cache” (this is a list of recently received timestamps). If it finds a match, the client’s authentication request will fail. If no match is found, client authentication has succeeded, and the resource server will add the timestamp to its replay cache.

The service responsible for time synchronization between Windows 2000, Windows XP, and Windows Server 2003 computers is the Windows Time Synchronization Service (W32time.exe). The Windows time service is compliant with the Simple Network Time Protocol (SNTP) as defined in RFC 1769 (available from http://www.ietf.org/rfcs/rfc1769.txt). SNTP makes sure that the computer clocks are within 20 seconds of each other. A protocol that can provide more accurate time synchronization than SNTP is the Network Time Protocol (NTP). NTP is defined in RFC 1305 (available from http://www.ietf.org/rfcs/rfc1305.txt). Because the Windows 2000 AD replication and Kerberos do not require the level of time accuracy offered by NTP, the Windows developers decided to implement the SNTP protocol as the time protocol for Windows 2000 and later OSs.

Basic SNTP operation

All Windows 2000, XP, and Windows Server 2003 machines have the W32Time service installed by default. In the service list the service is referred to as the Windows Time service—in Windows Server 2003 and XP it is started automatically. The time service will automatically perform time synchronization at machine startup and at regular intervals (initially every 8 hours).

At machine startup, the client contacts an authenticating domain controller and exchanges packets to determine the latency of communication between the two computers. W32time will determine what time the local machine time should be converged to—this time is referred to as the target time. If the target time is ahead of local time, local time is immediately set to the target time. If the target time is behind local time, the local clock is slowed over the next 20 minutes to align the two times, unless local time is more than 2 minutes out of synchronization, in which case the time is immediately set.

At regular intervals, the client machine will perform periodic time checks. To do this the client connects to the “inbound time partner” (the Windows authenticating domain controller) once each “period.” The initial period is 8 hours. If the local time is off from the target time by more than 2 seconds, the interval check period is divided in half. This process is repeated at the next interval check until either:

• The local time and target time remain within 2 seconds of each other.

• The interval frequency is reduced to the minimum setting of 45 minutes.

If accuracy is maintained within 2 seconds, the interval check period is doubled, up to a maximum period of 8 hours.

The default time convergence hierarchy constructed in a Windows 2000 and Windows Server 2003 forest follows the following rules:

• All client desktops and member servers nominate as their inbound time partner the authenticating domain controller. If this domain controller becomes unavailable, the client reissues its request for a domain controller.

• All domain controllers in a domain nominate the primary domain controller (PDC) emulator Flexible Single Master Operation (FSMO) to be the inbound time partner.

• All PDC emulator FSMOs in the enterprise follow the hierarchy of domains in their selection of an inbound time partner.

• The PDC emulator FSMO at the root of the forest is authoritative and can be manually set to synchronize with an outside time source.

Many organizations also rely on an external time source for time synchronization. This usually means that the PDC emulator of their root domain synchronizes with an external time server. In organizations that have a Windows forest that is geographically spread out, an external time source for a DC in every geography may be preferred over one time source for the root domain only.

The external time source can be a time server on the Internet such as the server of the Swiss Federal Institute of Technology in Zurich. It can also be a time server appliance hosted in the enterprise—one of the companies selling time server appliances is Symmetricom (previously known as Datum— more info at http://www.datum.com).

A sample SNTP hierarchy is shown in Figure 5.35. This default SNTP hierarchy can be modified by using the utilities that will be explained in the next section.

Figure 5.35: Sample SNTP hierarchy.

Configuring the windows time service

Microsoft provides two tools to configure and diagnose the Windows Time service:

• Net time—which is used to configure the time service and the synchronization hierarchy. The following net time command will change the time server on the local machine to mytimeserver.hp.com:

  Net time /setsntp:mytimeserver.hp.com

• w32tm—which is used to diagnose and configure the time service. For example, to monitor and analyze the time synchronization in the hp.com domain, I would type:

  w32tm /monitor /domain:hp.com

Both tools allow you to configure the time hierarchy to use the Windows defaults (as explained earlier in this section) or to use special designated time servers.

In Windows Server 2003, Microsoft added a new section in the GPO settings to configure the Windows Time Service. You can find it under Computer Configuration\Administrative Templates\System\Windows Time Service. The time service’s configuration data are kept in the following registry key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\w32Time.

For many more Windows time service configuration details, read the Microsoft white paper available from http://www.microsoft.com/windows2000/docs/wintimeserv.doc.