Tickets, tokens and the Active Directory authentication process

• Dean Wells, Contributor
• Published: 07 Sep 2006

Dean Wells

This is the fifth of six articles by contributor Dean Wells that dissect the Active Directory architecture. Dean is Director of Technology Solutions at MSEtechnology, a consulting organization that provides services such as solution analysis, solution design and implementation and technology seminars as well as customized training.

The Active Directory authentication process

In Dissecting the AD architecture: SID filtering and trust relationships, we discussed the fact that when a user is successfully authenticated within a domain he is provided with a construct known as an "access token." The means by which the user's identity is expressed on the wire, and the specific mechanisms used to deliver the access token, are collectively known as the "authentication protocol."

In order to adequately

More on the Active Directory architecture: Part 1: Infrastructure Master Part 2: Cross-references and phantoms Part 3: Foreign security principals Part 4: SID filitering and trust relationships Part 5: Tickets, tokens and the authentication process Part 6: SID filtering, usage scenarios and configuration

A user's access token (often simply referred to as the "token") is delivered within a Kerberos "ticket." Specifically, the token is contained within an attribute of the ticket known as the Privileged Attribute Certificate (PAC). A complete Windows interactive logon requires that the user possess two tickets: a Ticket Granting Ticket (TGT) and a session ticket. The TGT is sent to the user immediately following a successful authentication transaction and is later used to identify the user and authorize him to request further tickets, typically session tickets. A session ticket is required to access resources, e.g., to gain access to a computer within the domain whether logging on locally or mapping a network drive.

A TGT contains only those SIDs whose permissioning scope is beyond the user's own domain, namely user SIDs, Universal group SIDs and Global group SIDs. A session ticket contains the SIDs in the TGT and additionally the SIDs of any groups in which the TGT's SIDs are listed as a member.

Note: The access token resulting from a successful logon is only complete when it contains:

the SIDs of any local groups in which the session ticket SIDs were listed as members

the SIDs within the session ticket

A TGT contains only those SIDs whose permissioning scope is beyond the user's own domain, namely user SIDs, Universal group SIDs and Global group SIDs. Dean Wells Director of Technology SolutionsMSEtechnology

It therefore follows that in certain typical scenarios, a single Domain Controller is incapable of providing both the TGT and session ticket to an authenticating user. For example, when a user logs on to a computer in the domain "msetechnology.net" using an account in "uk.msetechnology.net" (a trusted domain within the same forest), the TGT is passed across an intra-forest trust boundary in order to request the relevant session ticket. This process also remains basically unchanged when the two domains reside in different forests (a cross-forest trust), but it often motivates the use of more stringent controls such as SID filtering and/or the authentication firewall. This is, of course, dependent upon the scenario, but additional restrictions are often deemed necessary in cases where the trusted domain lives outside the jurisdiction of the trusting domain's administrative staff.

Once an interactive logon is complete, the now logged-on user possesses both a TGT and a session ticket. Both tickets contain elements that are freely readable and elements that are encrypted and/or signed. The confidential elements within each ticket are encrypted with a key specific to the resource for which the ticket was issued. These keys are maintained within Active Directory. The key used for the TGT is maintained on the krbtgt user object while the session ticket's key is maintained on the computer's computer object.

In the next article, we'll delve into some of the scenarios suitable for using SID filtering, its configuration and specific behaviors.

Dean Wells has been in the information technology industry since 1987 providing consulting and training services on the leading platforms. Originally from the U.K., he is now the Director of Technology Solutions and a co-founder of MSEtechnology, a consulting/training organization. Dean is a Microsoft Directory Services and Security MVP and delivers internal-only classes to Microsoft Product Support Services on Windows Infrastructure technologies.