A: Windows 2000, Windows XP, and later Microsoft OSs include extensions to the Kerberos authentication protocol to support public key–based authentication. These extensions are known as PKINIT—which stands for "Public Key cryptography for INITial authentication." PKINIT enables smart card login to a Windows 2000 or later domain. In a PKINIT-based Kerberos authentication sequence, all occurrences of a user's master key (which is a cryptographic key that Windows derives from the user password) are replaced by the user's public key credentials.
Table 1 illustrates this substitution.
PKINIT introduces a new Windows authentication trust model. When using PKINIT, the domain controller (DC) isn't the first entity that authenticates users—as is the case for classic Kerberos or NTLM authentication. In PKINIT, users have already authenticated to the CA when they request their smart card login certificate. In the PKINIT trust model, both the users and the DC must trust the same CA. In other words, in the PKINIT model, the CA is the most important security authority.
The CA you use for Windows smart card login should preferably be a Windows enterprise CA. A Windows enterprise CA will automatically publish the smart card login certificates it issues for domain users to Active Directory (AD). But Microsoft also supports third-party CAs for the generation of smart card login certificates; for more information about the Windows smart card login certificate and CA requirements, see the Microsoft article
"Guidelines for enabling smart card logon with third-party certification authorities."
Figure 1 shows how the Kerberos smart card login process works.
Figure 1: How the Windows Kerberos smart card login process works
- Step 1: Alice starts the login process by introducing her smart card into her smart card reader and authenticating to the card by using her PIN. The smart card contains Alice's public key credentials: her private key and certificate.
- Step 2: A ticket-granting ticket (TGT) request is sent to the DC. This request contains the following data: Alice's principal name and a timestamp—both signed using Alice's private key—and a copy of Alice's certificate.
- Step 3: To validate the request and the digital signature, the Key Distribution Center (KDC) first validates Alice's certificate. The DC then queries AD for a mapping between Alice's certificate and a Windows user account. If the DC finds a mapping, it generates a new session key and issues a TGT for the corresponding user account.
- Step 4: The DC sends the TGT to Alice, together with a secured copy of the session key. Alice's copy of the session key is encrypted using her public key.
- Step 5: To retrieve her copy of the session key from the packets received from the DC in step 4, Alice uses her private key.
