Kerberos Policy Settings

Kerberos is the authentication protocol used in a Windows domain environment to authenticate logons and grant accounts access to domain resources. An account can be a user or a computer because computers must also authenticate to the domain. Kerberos provides mutual authentication between a client and server or between two servers. Mutual authentication means the identity of both parties is verified. Kerberos is also the basis for authorization to network resources in a Windows domain.

Kerberos uses shared secret key encryption to ensure privacy, and passwords are never sent
across the network. Kerberos authentication and authorization uses the following components:
• Key Distribution Center—Every domain controller is a Key Distribution Center (KDC), which uses the Active Directory database to store keys for encrypting and decrypting data in the authentication process. The keys are based on an account’s encrypted password.
• Ticket-granting tickets—When an account successfully authenticates with a domain controller (a KDC), it’s issued a ticket-granting ticket (TGT). A TGT grants the account access to the domain controller and is used to request a service ticket without having to authenticate again.
• Service tickets—A service ticket is requested by an account when it wants to access a network resource, such as a shared folder. It contains the account’s access information, such as group memberships. A service ticket is sometimes called a “session ticket.”
• Timestamps—A timestamp is a record of the time a message is sent. Timestamps are used in Kerberos to determine a message’s validity and prevent replay attacks. When a computer receives a Kerberos message, the timestamp must be within 5 minutes of the current time on the receiving computer. The value of 5 minutes is the default and can be configured in Kerberos policy settings.

steps that take place when a user attempts to log on to a domain:

1. A user enters his or her username and password at a logon prompt.
2. A message is created containing the username and domain name. Part of the message is encrypted by using the shared secret key, which is based on the user’s password. The encrypted message includes a timestamp.
3. A domain controller (a KDC) receives the message and retrieves the password from the Active Directory database for the username in the message. It then decrypts the message’s encrypted part by using the user’s password. If the message is decrypted successfully, the user’s identity is verified. The timestamp is also decrypted. The time on it must be within the value specified in the Kerberos Policy setting “Maximum tolerance for computer clock synchronization” (5 minutes by default) for the server’s current time. If the user’s identity is verified and the timestamp is valid, the user is authenticated.
4. The domain controller sends the user a ticket-granting ticket (TGT), which includes a time- stamp that authorizes the user to access the domain controller and request service tickets. The timestamp is again checked for validity. The user account caches the TGT information for future communication with the domain controller. A TGT is valid until it expires or the user logs off. By default, it’s valid for 10 hours.

Example of Service ticket

For example, a user has just logged on to the domain and wants to access a shared folder on a file server. For this example, the KDC is DC1, and the file server is FS1. All messages include a timestamp, which is validated.
1. The user attempts to open a shared folder on FS1. The client computer sends a service ticket request to DC1 that includes the original TGT issued when the user authenticated and the name of the requested resource.
2. DC1 validates the request and sends a service ticket to the client, which contains the user’s access information, including group memberships.

3. The client sends the service ticket to FS1, which validates the ticket and then checks the
user’s permissions, based on the access information in the ticket.
4. If the user has permissions to the resource, the user is granted access, and the service ticket is cached on the client computer. Future requests to access FS1 are sent directly to FS1, using the cached service ticket. A service ticket is valid until it expires or the user logs off. By default, it’s valid for 10 hours.

Kerberos policy settings:

• Enforce user logon restrictions—If this setting is enabled (the default), the KDC validates every request for service tickets against the rights granted to the requesting account. This process takes extra time, and although it’s somewhat more secure, it might slow access to network resources, so it can be disabled if needed.

• Maximum lifetime for service ticket—This setting specifies in minutes how long a service ticket can be used before a new ticket must be requested to access the resource the ticket was granted for. The default is 600 minutes or 10 hours. The minimum allowed value is 10 minutes, and the maximum value is equal to the “Maximum lifetime for user ticket” setting.

• Maximum lifetime for user ticket—This setting is the maximum amount of time in hours a TGT can be used before it must be renewed or a new one must be requested. The default value is 10 hours.

• Maximum lifetime for user ticket renewal—This setting, specified in days, is the maximum period during which a TGT can be renewed. The default setting is 7 days. In this period, a TGT can be renewed without having to go through the full authentication process. After this period has expired (or the account logs off), a new TGT must be requested.

• Maximum tolerance for computer clock synchronization—This setting determines the maximum time difference allowed between a Kerberos message timestamp and the receiving computer’s current time. If the time difference falls outside this limit, the message is considered invalid. The default is 5 minutes. Timestamp messages are corrected for time zone, so it’s important to have the correct time zone set on all computers in the domain and have the domain controller clocks synchronized with a reliable source. By default, member computers are synchronized with the DC’s clock.