When initially logging on to a Realm, clients must negotiate access by providing a log-in name and password in order to be verified by the AS component of a KDC within their Realm.

The KDC has access to Active Directory user account information. Once successfully authenticated, the user is granted a Ticket to Get Tickets (TGT) that is valid for the Realm.

The TGT has a default lifetime of 10 hours and may be renewed throughout the user's log-on session without requiring the user to re-enter his password. The TGT is cached on the local machine in volatile memory space and used to request sessions with services throughout the network. The following is a discussion of the TGT retrieval process.

Example Request#

The client send a request to the AS which identifies the client to the KDC in plain text consisting of:
  • Client-Principal - (e.g. pippo@EXAMPLE.COM)
  • Principal Service - "krbtgt/REALM@REALM"
  • IP List - Which maybe one or more IP addresses or null
  • Lifetime - is the maximum validity time (requested) for the ticket to be issued.

If Preauthentication is enabled, a time stamp will be encrypted using the user's password hash as an encryption key.

If the KDC reads a valid time when using the user's password hash (stored in the Active Directory) to decrypt the time stamp, the KDC knows that request isn't a replay of a previous request.

The preauthentication feature may be disabled for specific users in order to support some applications that don't support the security feature. Access the user account from the Active Directory users and the computers will snap-in and select the account tab. From the account options: slide window, check mark the "Do not require Kerberos" preauthentication option

AS Response#

When the request arrives, the AS checks whether
  • PrincipalClient exist in the KDC database
  • PrincipalService exist in the KDC database
    • if either does not exist an error message is sent to the client

Otherwise the AS processes the response as follows:

  • Randomly Creates a Session Key shared between the client and the TGS (we call this SKTGS)
  • creates the TGT putting inside:
    • the requesting Client-Principal
    • the Service-Principal (it is generally krbtgt/REALM@REALM, but read the note* for the previous paragraph)
    • the IP address list (these first three pieces of information are copied as they arrive by the AS_REQ packet),
    • date and time (of the KDC) in timestamp format
    • lifetime (see note*)
    • Session Key (SKTGS)

So the TGT looks like:

TGT = 
     Principal Client 

The AS generates and sends the AS_REP containing:

  • The TGT encrypted using the Secret Key for the TGS (SKTGS)
  • the service principal
  • timestamp
  • lifetime
  • Session Key all encrypted using the Secret Key for the service (let's call it KTGS)

The AS_REP looks like:


It may seem that this message contains redundant information (PrincipalService, timestamp, lifetime and session key). But this is not the case:

  • since the information present in the TGT is encrypted using the Secret Key for the server (KTGS), the TGT cannot be read by the client and needs to be repeated.

At this point, when the client receives the reply message, it will ask the user to enter the password.

The salt is concatenated with the password and then the string2key function is applied: with the resulting key an attempt is made to decrypt the part of the message encrypted by the AS using the Secret Key of the user stored in the database. If the user is really who he/she says, and has thus entered the correct password, the decrypting operation will be successful and thus the Session Key (SKTGS) can be extracted and with the TGT (which remains encrypted) stored in the user's credential cache.

Note lifetime#

The actual lifetime, i.e. which is put in the ticket is the lowest of the following values: the lifetime requested by the client, the one contained in the user's principal and that in the service principal. Actually in terms of implementation another limit can be set from the configuration of the KDC and applied to any ticket.

Note IP_list #

IP_list may also be null. In this case the corresponding ticket can be used by any machine. This resolves the problem of those clients under NAT, since their request would arrive at the service with a source address different from that of the requesting user, but the same as the router making the NAT. Instead, in the case of machines with more than one network card, IP_list should contain the IP addresses of all the cards: in fact it would be difficult to predict beforehand with which connection the server which provides the service would be contacted.

Only when these two values are obtained can the Client-Principal attempt to access a Relying Party using the TGS-REQ-REP

More Information#

There might be more information for this subject on one of the following:

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-4) was last changed on 23-Apr-2017 19:40 by jim