Tickets, tokens and the Active Directory authentication process

Expert Dean Wells describes the process of security identifier (SID) filtering and breaks down several components of the authentication protocol in his continued analysis of the Active Directory architecture.

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
describe the process of security identifier (SID) filtering, it is necessary to reference a number of key processes and components within the authentication protocol. To eliminate the possibility of confusion or ambiguity, Kerberos vernacular will be used throughout since it is the preferred Windows authentication mechanism.

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
    TGTs are only able to be issued by the Key Distribution Center (KDC) service running on a Domain Controller within the same domain as the authenticating user. Similarly, only a Domain Controller within the domain in which the resource exists can issue session tickets.

    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.

    This Content Component encountered an error

    Pro+

    Features

    Enjoy the benefits of Pro+ membership, learn more and join.

    0 comments

    Oldest 

    Forgot Password?

    No problem! Submit your e-mail address below. We'll send you an email containing your password.

    Your password has been sent to:

    -ADS BY GOOGLE

    SearchServerVirtualization

    SearchCloudComputing

    SearchExchange

    SearchSQLServer

    SearchWinIT

    SearchEnterpriseDesktop

    SearchVirtualDesktop

    Close