!!! Overview [1]
When initially logging onto a [Kerberos Realm] (or [AD DOMAIN]), [clients] must negotiate access by providing a log-in name and [password] in order to be verified by the [Kerberos Authentication Service] ([AS]) within the same [Kerberos Realm]. 

The [Key Distribution Center] has access to the [Kerberos Database] ([Microsoft Active Directory]) user account information and the [Kerberos Authentication Service] will check if you are in the [Kerberos Database]. This check is only to see if the [entity] exist (ie __no [credentials] are checked__) the user is granted a __Ticket to Get Tickets__ ([Ticket Granting Ticket]) that is valid for the [Kerberos Realm]. 

The [Ticket Granting Ticket] 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 [Ticket Granting Ticket] ma be put in [cache] on the [local device] or in [Random Access Memory] space and used to request [Kerberos] [sessions] with [Resources] throughout the network.

!! [Example] ([AS_REQ]) Request
The [client] send a request to the [AS] which identifies the client to the [KDC] in [plaintext] consisting of:
* [Client-Principal] -  (e.g. pippo@[example.com])
* [Principal Service|TGS] - "krbtgt/REALM@REALM"
* [IPA] List - Which maybe one or more [IP Address] or [null]
* [Lifetime] - is the maximum validity time (requested) for the [Ticket Granting Ticket] to be issued.

If [Kerberos Pre-Authentication] is enabled, a timestamp 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 [Microsoft Active Directory]) for [decryption] of the [timestamp], the [KDC] knows that [request] isn't a [replay attack] of a previous request. 

The [Kerberos Pre-Authentication] feature may be __disabled__ for specific users in order to support some [applications] that don't support the security feature. 

!! [Example] [Kerberos Authentication Service] ([AS_REP]) [Response]
When the [request] arrives, the [Kerberos Authentication Service] checks whether 
* [Client-Principal] exist in the [Kerberos Database]
* [Service-Principal] exist in the [Kerberos Database]
** if either does not exist an error [Result Code] is sent to the [client]

Otherwise the [AS] processes the [AS_REP] as follows:
* Randomly Creates a [TGS Session Key] shared between the [client] and the [Ticket Granting Service]
* creates the [Ticket Granting Ticket] putting inside:
** the requesting [Client-Principal]
** the [Service-Principal] (it is generally krbtgt/REALM@REALM)
** 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]  
** [TGS Session Key]

It may seem that this [message] contains redundant information ([Service-Principal], [timestamp], [lifetime] and  [TGS Session Key]). However since the information present in the [Ticket Granting Ticket] is [encrypted] using the [TGS Session 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 [AS_REP] 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 and used for [decryption] of the part of the [message] [encrypted] by the [AS] using the [Secret-key] of the user stored in the [Kerberos Database]. If the user is really who he/she says, and has thus entered the correct [password], the [decryption] operation will be successful and thus the [TGS Session Key] 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. And in some [Kerberos] implementations ([Microsoft Windows]) the [lifetime] can be set from the configuration of the [KDC] and applied to any ticket.

! Note [IP Address] list 
[IP Address] 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 Address] list should contain the [IP Address] 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.

!! After the [{$pagename}] 
Only when the [TGS Session Key] and the [Ticket Granting Ticket] are obtained can the [Client-Principal] attempt to access a [Relying Party] using the [TGS Exchange]

!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }] 
----
* [#1] - [Kerberos Explained|https://msdn.microsoft.com/en-us/library/bb742516.aspx|target='_blank'] - based on information obtained 2007-04-21-