Q: Why does Kerberos smart card login require public key certificates, private keys, and a Certification Authority (CA)?

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