It is up to the KDC to provide the means necessary for a user to be authenticated to a resource. But that doesn't mean that the user is authorized to use the resource. Surely, this communication process must include some information for authorization. It does. It works this way. When Kerberos is used for authentication, a list of SIDs identifying a security principal and the principal's group membership is transported to the local computer as part of the session ticket. The authorization data is gathered in two separate steps. The first step takes place when the KDC in a Windows 2000 domain prepares a TGT. The second step is accomplished when the KDC prepares a session ticket for a server in the domain.
So, when a user requests a TGT, the KDC in the user's account domain requests information from the domain's Active Directory. The user's account record includes an attribute for the user's SID as well as an attribute with SIDs for any domain security groups to which the user belongs. This is the list of SIDs that are returned to the KDC, and this list is placed in the TGT's authorization data field. In a multiple-domain environment, the KDC also queries the Global Catalog for any universal groups that include the user or one of the user's domain security groups. If any are found, their SIDs are added to the list in the TGT's authorization data field.
Now, when the user requests a session ticket for a server, the KDC in the server's domain copies the contents of the TGT's authorization data field to the session ticket's authorization data field. If the server's domain is different from the user's account domain, the KDC queries Active Directory in order to find out whether any security groups in the local domain include the user or one of the user's security groups. If any are found, their SIDs are added to the list in the session ticket's authorization data field.
Was this article helpful?