Kerberos V5 Authentication in Windows 2000

Microsoft Windows 2000 Server introduced native support for the Kerberos V5 authentication protocol as the default security mechanism for domain environments. This article explains how Windows 2000 Server implements Kerberos V5, focusing on the role of Active Directory, the Key Distribution Center (KDC), the ticket-granting process, and Microsoft's proprietary extensions for user authorization.

The Key Distribution Center and Active Directory

Windows 2000 Server integrates Kerberos V5 directly with Active Directory by embedding the Key Distribution Center (KDC) into each Domain Controller (DC). The KDC runs as an integral part of the Local Security Authority Subsystem Service (LSASS) and relies on Active Directory as the centralized account database.

Instead of maintaining a separate Kerberos database, the DC stores cryptographic keys, user accounts, and service principal names (SPNs) as attributes directly within Active Directory objects. The KDC consists of two primary functional components:

  • Authentication Service (AS): Validates user credentials during the initial logon and issues a Ticket-Granting Ticket (TGT).
  • Ticket-Granting Service (TGS): Issues session tickets for specific network services when presented with a valid TGT.

The Ticket Exchange Process

The mechanism relies on symmetric key cryptography and a mutual trust model involving three standard phases:

  1. Initial Authentication (AS Exchange): When a user logs on, the Kerberos client on the workstation sends an authentication request (KRB_AS_REQ) containing a timestamp encrypted with the user's password-derived key (pre-authentication). The KDC verifies this against Active Directory. Upon successful verification, the KDC responds (KRB_AS_REP) with an encrypted TGT and a unique logon session key.
  2. Requesting a Service Ticket (TGS Exchange): When the user requires access to a domain resource (such as a file share), the client sends a ticket request (KRB_TGS_REQ) to the KDC. This request includes the user's TGT, an authenticator encrypted with the logon session key, and the target resource's SPN. The KDC decrypts the TGT, validates the request, and issues a Service Ticket (KRB_TGS_REP) encrypted with the target service account's secret key.
  3. Service Access (Client/Server Exchange): The client presents the Service Ticket directly to the target server (KRB_AP_REQ). The server decrypts the ticket using its own secret key to verify the client's identity without contacting the domain controller, enabling mutual authentication and session establishment.

The Privilege Attribute Certificate (PAC)

Standard Kerberos V5 (RFC 1510) provides identity authentication but does not specify user authorization. Microsoft addressed this in Windows 2000 Server by appending a Privilege Attribute Certificate (PAC) into the AuthorizationData field of the Kerberos ticket.

When generating the TGT and subsequent service tickets, the KDC queries Active Directory to collect the user's Security Identifier (SID), domain global group memberships, and universal group memberships. These SIDs are packaged into the PAC and digitally signed by the KDC. When the target server receives the service ticket, it unpacks the PAC to build an access token directly, allowing the server to enforce local Windows NTFS and share permissions without generating additional authentication traffic back to the domain controller.

Security Support Provider Interface (SSPI)

Windows 2000 Server exposes Kerberos functionality to applications through the Security Support Provider Interface (SSPI) via Kerberos.dll. This architecture allows applications to negotiate authentication transparently, falling back to the legacy NTLM protocol when communicating with down-level clients (such as Windows NT 4.0 or Windows 9x) or systems residing outside the Active Directory Kerberos realm.