How Windows 2000 Processes Kerberos UPN Logons

This article examines how Microsoft Windows 2000 handles user authentication using User Principal Names (UPNs) through the Kerberos v5 protocol. It covers the resolution of UPN suffixes, the interaction between the client, the Key Distribution Center (KDC), and the Global Catalog, and the step-by-step process of issuing Kerberos Ticket-Granting Tickets (TGTs) for logon requests.

Understanding the User Principal Name (UPN)

In Windows 2000 Active Directory, a User Principal Name (UPN) provides an email-style logon format, such as user@domain.com. A UPN consists of two parts separated by an @ symbol: the user account name and the UPN suffix. The suffix can be the DNS name of the domain where the user account resides or an alternative suffix defined at the forest level in Active Directory Domains and Trusts.

Step 1: Logon Initiation and UPN Submission

When a user types a UPN into the Windows 2000 Graphical Identification and Authentication (GINA) interface:

  1. The client system parses the string into the username prefix and the domain/realm suffix.
  2. The Kerberos security support provider (SSP) on the workstation prepares an Authentication Service Request (KRB_AS_REQ).
  3. The client queries DNS using SRV records (_kerberos._tcp.<suffix>) to locate a Key Distribution Center (KDC) serving the specified realm.

Step 2: Global Catalog Lookup

If the UPN suffix corresponds directly to the user's actual domain name, the target domain controller (acting as the KDC) processes the request directly. However, if an alternate UPN suffix is used, the targeted domain controller might not host the account.

Windows 2000 resolves this through the Global Catalog (GC):

  1. The KDC receives the KRB_AS_REQ containing the UPN.
  2. If the KDC cannot locate the account in its local Active Directory partition, it initiates a search against the Global Catalog (port 3268).
  3. Because the userPrincipalName attribute is indexed in the Global Catalog schema, the GC quickly finds the user object across the entire Active Directory forest.
  4. The GC returns the user's real domain and Security Identifier (SID) to the KDC.

Step 3: Kerberos Referral or Local Authentication

Depending on the domain where the user account resides, the authentication proceeds in one of two ways:

  • Direct Authentication: If the KDC receiving the request hosts the domain containing the account, it verifies the user's pre-authentication data (an encrypted timestamp) using a hash of the user’s password stored in the directory.
  • Kerberos Referrals: If the account resides in a different domain within the forest, the initial KDC issues a referral ticket (a cross-realm TGT) pointing to a KDC in the user’s home domain. The client follows this referral chain until it communicates directly with the KDC of the account domain.

Step 4: TGT Generation and Privilege Attribute Certificate (PAC)

Once the home domain KDC validates the user's credentials:

  1. The KDC queries Active Directory to construct the user's authorization data, known as the Privilege Attribute Certificate (PAC). The PAC contains the user's SID, group SIDs, and user rights.
  2. The KDC generates a Ticket-Granting Ticket (TGT) containing the PAC, encrypted with the KDC's master key (krbtgt account).
  3. The KDC sends the Authentication Service Reply (KRB_AS_REP) back to the client workstation, containing the TGT and an encrypted session key.

Step 5: Session Initialization

The workstation decrypts the response using the local hash of the user's password. The client caches the TGT and uses it to request service tickets for local workstation resources. The local Local Security Authority (LSA) processes the PAC to build the user's access token, successfully completing the Windows 2000 logon process.