This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
AS Exchange
AS Exchange

Version management

Difference between version and

At line 1 added 56 lines
!!! 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-
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop