Jorge's Quest For Knowledge!

All You Need To Know About Identity And Security On-Premises And In The Cloud. It's Just Like An Addiction, The More You Have, The More You Want To Have!

(2011-02-13) Accessing A Resource With The Kerberos Authentication Protocol

Posted by Jorge on 2011-02-13


Like the mythical guard (the three headed dog), the Kerberos protocol has three heads, or in other words three parties are involved and each with its own purpose and interest: a (requesting) client, a (targeted) server, and a trusted third party to mediate between the first two. The trusted intermediary in this protocol is the Key Distribution Center (KDC), which runs on every Windows DC (RWDC and RODC) by default. The KDC is a service running on a physically secure server (HINT: amongst other reasons, this is also why a DC MUST be physically secured!). It maintains a database with account information for all security principals (users and computers) in its realm. A realm is also the Kerberos equivalent of an AD domain in Windows. Along with other information about each security principal, the KDC stores a cryptographic key known only to the principal and the KDC.

During the interactive logon the domain name, the user name and the password are collected as the credentials to generate authentication data (Kerberos tickets) which is then used for subsequent network logons. The Kerberos client on the user’s computer will convert the password into an encryption key by passing it through a one-way hash function. This encryption key will be the user’s master key (i.e. the password in a different format). Using the master key for the long term would be a bad idea as it is derived from the password. That’s why the client instead uses a temporary key received from a Key Distribution Center (KDC) which will only be valid for the current logon session. So when a user logs on to a client, the client requests a special ticket for the KDC itself, which is called the "Ticket Granting Ticket (TGT)".

An example of a TGT ticket is shown below in the picture.

image

The TGT is encrypted with the KDC’s master key (this master key is derived from the domain-wide KRBTGT user account in case of a RWDC or the RODC specific KRBTGT user account in case of an RODC). This TGT is what will be used by the client during its current logon session for subsequent resource access requests through the use of service tickets. From this point the password of the logged on user will not be used anymore (!). The lifetime of this TGT can be configured through the GPO setting "Maximum lifetime for user ticket", and by default this lifetime equals to 10 hours. At the same time this same TGT can be renewed a number of times within a period which is configured in the GPO setting "Maximum lifetime for user ticket renewal". By the default this period equals 7 days.

The "Maximum lifetime for user ticket" GPO setting determines the amount of time the TGT is valid until it will expire at some point in time. The best practice value for this setting should reflect the average amount of time a user uses his/her computer during a normal working day. So, by default this is configured with 10 hours. At the end of the ticket lifetime, the user’s computer requests to renew the existing TGT. A shorter value for this setting provides greater security, but it increases network traffic. A longer value for this setting provides less security, but it also decreases network traffic.

The "Maximum lifetime for user ticket renewal" GPO setting determines the period in which a user’s TGT can be renewed. So, by default this is configured with 7 days. A shorter period eases the requirement for users to reauthenticate. An attacker with a renewable TGT ticket can renew it for as long as this setting allows it. Shorter renewal periods, makes the work of an attacker more difficult and it also increases the authentication load on DCs.

When a client wants to create a secure connection with a server, the client begins by sending a request to the KDC, not to the server that it wants to reach. The KDC creates and sends to the client a unique session key for the client and the server to authenticate each other. The KDC has access to both the client’s master key and the server’s master key. The KDC encrypts the server’s copy of the session key using the server’s master key, and the client’s copy using the client’s master key.

Unlike the NTLM authentication protocol, when a client wants to access a resource, it does not access the resource right way. First it requests from the KDC a special ticket called a service ticket that can be used to access a specific resource on a server. The client authenticates itself to the KDC using the previously received TGT. Based upon that TGT the KDC generates a service ticket and hands it out to the client. The client then hands out the service ticket to the resource to authenticate itself. Because the resource also trusts the KDC, it will also trust the information in the service ticket. This service ticket is what will be used by the client during its current logon session to access the resource. The lifetime of this service ticket can be configured through the GPO setting " Maximum lifetime for service ticket", and by default this lifetime equals to 600 minutes (=10 hours).

The "Maximum lifetime for service ticket" GPO setting determines the amount of time the service is valid until it will expire at some point in time. This setting usually is configured with the same value as the "Maximum lifetime for user ticket" GPO setting. It might be shorter if there is a need for secure authentication to services in addition to what is required for user authentication. It might be longer if users require uninterrupted access to services for long periods of time. For example, you might need to extend the service ticket lifetime if services are used for a longer period than the duration of the user ticket lifetime. If no special requirements exist for the service ticket lifetime, do not extend the lifetime of the ticket and use the default value. The maximum service ticket lifetime must be greater than 10 minutes and less than or equal to the maximum lifetime for user ticket setting. By default, this value is set to 600 minutes (10 hours) in the Default Domain Group Policy object (GPO). Ongoing operations are not interrupted if the session ticket, used to authenticate the connection, expires before the operation is complete.

If a client presents an expired service ticket when it connects to a resource, the server returns an error message. The client must request a new service ticket from the KDC to access that resource. Authentication of the client again occurs with the TGT. Once a connection to a resource is authenticated, it no longer matters whether the service ticket remains valid. Service tickets are used only to authenticate new connections with servers. Ongoing operations are not interrupted if the service ticket that is used to authenticate the connection expires during the connection. So, with Kerberos the path is: "Client" –> "DC" –> "Client" –> "Resource/Server" –> "Client"

An example of a service ticket is shown below in the picture.

image

The following steps present an outline of Kerberos authentication, which is detailed in 4 phases.

Phase 1: User Logon To A Client

  1. A user enters the domain name, the user name and its password on the client computer;
  2. The Kerberos client on the user’s computer will convert the password into an encryption key by passing it through a one-way hash function. This encryption key will be the user’s master key.

Phase 2: Client Authentication

  1. The client sends a clear text message containing the user name to the KDC (a.k.a. Authentication Server, AS) (Note: Neither the master key nor the password is ever sent to the KDC).
  2. The KDC checks to see if the user is in its AD database and if it is, the KDC generates the secret key by hashing the password of the user found in the AD database;
  3. The KDC checks to see if the client computer is in its AD database. If it is, the KDC sends back the following two messages to the client:
    1. Message A: Client/Ticket Granting Service (TGS) Session Key encrypted using the secret key of the client/user;
    2. Message B: Ticket Granting Ticket (TGT) (which includes the client ID, client network address, ticket validity period, and the client/TGS session key) encrypted using the secret key of the KDC/TGS.
  4. Once the client receives messages A and B, it attempts to decrypt message A with the secret key generated from the password entered by the user at logon. If the password entered by the user does not match the password in the AD database, the client’s secret key will be different and thus unable to decrypt message A. With a valid password and secret key the client decrypts message A to obtain the Client/TGS Session Key. This session key is used for further communications with the KDC/TGS. (Note: The client cannot decrypt Message B, as it is encrypted using TGS’s secret key.) At this point, the client has enough information to authenticate itself to the KDC/TGS and request service tickets as needed. The password will no longer be used.

Phase 3: Client Service Authorization

  1. When requesting services, the client sends the following two messages to the KDC/TGS;
    1. Message C: Composed of the TGT from message B and the ID of the requested service;
    2. Message D: Authenticator (which is composed of the client ID and the timestamp), encrypted using the Client/TGS Session Key;
  2. Upon receiving messages C and D, the KDC/TGS retrieves message B out of message C. It decrypts message B using the KDC/TGS secret key. This gives it the "client/TGS session key". Using this key, the KDC/TGS decrypts message D (Authenticator) and sends the following two messages to the client:
    1. Message E: Client-to-server ticket (which includes the client ID, client network address, validity period and Client/Server Session Key) encrypted using the service’s secret key;
    2. Message F: Client/server session key encrypted with the Client/TGS Session Key.

Phase 4: Client Service Request

  1. Upon receiving messages E and F from the KDC/TGS, the client has enough information to authenticate itself to the resource on the server. The client connects to the resource on the server and sends the following two messages:
    1. Message E from the previous step (the client-to-server ticket, encrypted using service’s secret key);
    2. Message G: a new Authenticator, which includes the client ID, timestamp and is encrypted using client/server session key.
  2. The resource on the server decrypts the ticket using its own secret key to retrieve the Client/Server Session Key. Using the sessions key, the resource on the server decrypts the Authenticator and sends the following message to the client to confirm its true identity and willingness to serve the client:
    1. Message H: the timestamp found in client’s Authenticator plus 1, encrypted using the Client/Server Session Key.
  3. The client decrypts the confirmation using the Client/Server Session Key and checks whether the timestamp is correctly updated. If so, then the client can trust the server and can start issuing service requests to the server.
  4. The server provides the requested services to the client.

Now look at step 1.2, step 2.2 and step 2.4. If the password has expired after the user logged on interactively, but before the user accessed the resource, the DC will hand out a service ticket for the specific resource because the client is authenticating itself using the TGT. Access to resources is allowed using the Kerberos protocol (in other words: requesting service tickets) as long as the TGT is valid and as long as it can be renewed. The TGT remains valid after being renewed within the configured period until a completely new TGT must generated using the master key of the user, which depends on the password of the user. So, if during a logon session, the user’s password expires before the user logs off, the TGT remains valid and can be renewed over and over again as long as the TGT renewal period has not ended. With that TGT, or a renewed TGT, service tickets can be requested to access resources that support the kerberos authentication protocol. Be aware though, because your password has expired you might be reminded by the OS over and over again to provide your password again as shown in the picture below.

image

However, if during the same logon session the password expires and at a later stage the renewal period ends, the user will start to experience issues when accessing resources. This occurs because service tickets cannot be requested anymore as the TGT is not valid anymore and it cannot be renewed anymore. The renewal period has ended and a brand new TGT needs to be issued, but that will not occur because the password has expired.

An example of issues with Outlook/Exchange in the latter case is shown below in the two pictures. Without logging off, you get the possibility to change the password.

image

image

An example of issues with drive mappings and/or UNC paths in the latter case is shown below in the two pictures.

image

image

The version of accessing a resource with the NTLM authentication protocol, can be found here.

So, the moral of the story is: "change the password as soon as you are warned it is going to expire"!

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

8 Responses to “(2011-02-13) Accessing A Resource With The Kerberos Authentication Protocol”

  1. […] The version of accessing a resource with the Kerberos authentication protocol, can be found here. […]

  2. […] The version of accessing a resource with the Kerberos authentication protocol, can be found here. […]

  3. […] https://jorgequestforknowledge.wordpress.com/2011/02/13/accessing-a-resource-with-the-kerberos-authen… […]

  4. […] REMARK: Detailed information about Kerberos authN can be found HERE. […]

  5. […] (2011-02-13) Accessing A Resource With The Kerberos Authentication Protocol […]

  6. […] (2011-02-13) Accessing A Resource With The Kerberos Authentication Protocol […]

  7. […] The version of accessing a resource with the Kerberos authentication protocol, can be found here. […]

  8. […] The version of accessing a resource with the Kerberos authentication protocol, can be found here. […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: