Ravindra Kulkarni
Active Directory enables a single sign-on, which makes the complex processes of authentication and authorization transparent to the user. A single sign-on is made up of authentication, which verifies the credentials of the connection attempt, and authorization, which verifies that the connection attempt is allowed. With a single sign-on, users do not have to manage multiple sets of credentials and can access the resources for which they are authorized without thinking about the processes that occur behind the scenes. However, as a systems engineer, we must understand how these processes work in order to troubleshoot the Active Directory structure.
The single sign-on process occurs as follows:
- The user enters credentials at a workstation to perform an interactive logon.
- The credentials are encrypted by the client and sent to a domain controller for the client’s domain.
- The encrypted credentials that are sent from the client are matched against the encrypted credentials on the domain controller. A Kerberos service, the Key Distribution Center (KDC), resides on each domain controller and stores the encrypted user credentials. If the credentials sent by the client match the credentials stored by the KDC, the process continues.
- The domain controller creates a list of the domain-based groups to which the user belongs.
- The domain controller queries the global catalog to identify the universal groups to which the user belongs. If the domain controller has Universal group membership caching enabled, the global catalog is not queried and the Universal group memberships are obtained from the cache on the domain controller.
- The KDC issues the client a ticket-granting ticket (TGT). The TGT contains the encrypted security identifiers (SIDs) for the groups of which the user is a member.
- The client requests access to a resource that resides on a specific server.
- The client uses the TGT to gain access to the ticket-granting service (TGS), on the domain controller.
- The TGS issues a service ticket, which is also called a session ticket, for the server where the resource resides to the client. The session ticket contains the SIDs for the user’s group memberships.
- The client presents the session ticket to the server where the resource resides. The Local Security Authority (LSA) on the server uses the information in the session ticket to create an access token.
- The LSA compares the SIDs in the access token with the groups that are assigned permissions in the resources discretionary access control list (DACL). If they match, the user is granted access to the resource.
IgNiTeD SoUL 