Configuring Kerberos Policies

Updated : October 28, 2002

In a Windows 2000 Domain, Kerberos authentication is used by both client and a server in trying to determine each other's legitimacy. Kerberos works with private key cryptography. That is, both the Kerberos-enabled client and server share a secret key. Kerberos authentication works as follows (assuming the client initiates contact with the server):

1. The client generates an authenticator that contains unique information about the client (for example, client name, client realm, the time on the client, a checksum of the data in the authenticator message, and so forth). Each authenticator is unique, because of the time information it contains.

2. The client encrypts the authenticator with its copy of the secret key.

3. The client sends the encrypted authenticator to the server.

4. The server decrypts the authenticator with its copy of the secret key.

5. The server creates its own unique authenticator, which also contains a portion of the client's authenticator. That way, the server proves to the client that it received the client's authenticator, and it was able to decrypt the message, indicating that it is the proper server that had access to the secret key.

Note that since all authenticators must be unique, they are valid one time only. Therefore, Kerberos protects the system from replay attacks. A replay attack (with normal user identification (ID)/password authentication) is when an outsider can collect authentication data off of the network and replay it to the server. Since a user ID/password combination is good for many uses, the server cannot determine if the second authentication attempt is the valid user trying to open another session, or if it is an impostor trying to break into the system. Since the user ID/password information in the replay is correct, the system will grant access to the impostor.

The secret keys used in Kerberos authentication, called session keys, are also one-time use, just as authenticators are. Kerberos has a trusted authority, called the Key Distribution Center (KDC) that issues keys. Each client and each server is issued a long-term key by the KDC. It is so called because the key is valid for a long time. However, this key is only used when a client or server needs to communicate with the KDC. For client-server authentication, both the client and the server have to obtain a session key from the KDC. Session keys are only good for one logon session. When the session is terminated (for whatever reason) the session key that was used is no longer valid. If the same client wants to authenticate again to the same server, they both need to ask the KDC for new session keys.

The Kerberos policy is set at the domain level and is stored in the Active Directory. This means two things: One is that a user must be a member of the Domain Administrators group to change the Kerberos policy. The other is that changes made on one domain controller will be replicated to the other domain controllers along with the normal Active Directory replication.

Ticket duration, renewal, and enforcement can be controlled by adjusting the Kerberos Policy settings. These policies are discussed in the subsections that follow.

Warning: Only administrators with an intimate understanding of Kerberos security should change these policies. If these policies are changed to inefficient settings, serious network problems may result. In most cases the default Kerberos policy settings work just fine. Also Note that in order to maintain compliance with the Evaluated Configuration the default settings for Enforce user logon restrictions and Maximum tolerance for computer clock synchronization must not be changed from the default, as defined in the Windows 2000 Security Configuration Guide.

• Enforce User Logon Restrictions: Enforce user logon restrictions ensures that any restrictions placed on a user account are enforced. It validates every request by checking the user rights policy to see if the user has permission to log on locally or to access the computer from the network. It also checks to make sure the account is valid. For example, if the user's logon hours are restricted, this policy is what enforces the restriction. The downside is that it may slow network access to services. By default, the policy is enabled and should only be disabled in rare circumstances.

  

• Maximum Lifetime For Service Ticket: Maximum lifetime for service ticket and Maximum lifetime for user ticket set the maximum duration for which a service or user ticket is valid. By default, service tickets have a maximum duration of 600 minutes and user tickets have a maximum duration of 10 hours. The duration of these tickets can be changed (although it is not recommended). For service tickets, the valid range is from 0 to 99,999 minutes. For user tickets, the valid range is from 0 to 99,999 hours. A value of zero effectively turns off expiration. Any other value sets a specific ticket lifetime.

  

  

• Maximum Lifetime For User Ticket Renewal: A ticket that expires can be renewed, provided the renewal takes place within the time set for Maximum lifetime for user ticket renewal. By default, the maximum renewal period is 7 days. The renewal period can be changed to any value from 0 to 99,999 days (although it is not recommended). A value of zero effectively turns off the maximum renewal period and any other value sets a specific renewal period.

  

• Maximum Tolerance For Computer Clock Synchronization: The Maximum tolerance for computer clock synchronization is one of the few Kerberos policies that may need to be changed. By default, computers in the domain must be synchronized within five minutes of each other. If the client clock and the server clock are not synchronized closely enough, a client ticket is not issued. The default value is 5 minutes, and settings are in minutes. If there are remote users that log on to the domain without synchronizing their clock to the network timeserver, it may be necessary to adjust this value. However, changing this value to provide a wider margin can leave the system open to replay attacks. Therefore the default must be maintained for the Evaluated Configuration.