In-Depth
Smart Card Logon Integration with Kerberos
Learn the basic behind-the-scenes steps for Smart Card logon under Kerberos.
- By Roberta Bragg
- 10/01/2000
When smart cards are used for authentication in Win2K,
a copy of the certificate and the private key can be stored
on the smart card. When the user inserts the card in the
reader, he or she will be prompted to enter the pin. What
happens next? How does this operation provide the credentials
necessary for a logon system based on Kerberos?
Kerberos doesn’t use public key cryptography; instead,
it uses a session or symmetric key. In order for a smart
card interface to work, some work has to occur before
Kerberos can do its job. Win2K implements a proposed extension
to the Kerberos standard and integrates smart card logon
with Kerberos. Here’s what happens:
- If a reader is attached to the user’s machine, the
user is prompted to put in a card.
- Then the user is prompted to enter a pin.
- The logon request is passed to the Local Security
Authority (LSA).
- LSA communicates with the Kerberos authentication
package on the client.
- Kerberos sends a request to the Kerberos Distribution
Center (KDC) on the domain controller for authentication.
The request includes a copy of the x.509 certificate
(from the smart card) in the pre-authentication data
field of the request and is signed by the private key.
- The KDC builds a certification path from the certificate
to a root CA in the system root store.
- In Win2K, there must be an enterprise Certification
Authority (CA, published in Active Directory). This
prevents a rogue CA certified in another CA hierarchy
from issuing a certificate in the domain.
- The KDC uses the public key from the certificate
to verify the signature.
- KDC verifies the timestamp is within skew time, the
time period during which a request can be processed.
This helps to detect a replay attack.
- KDC looks in the AD for account information.
- If all tests are passed, the KDC returns a Ticket
Granting Ticket (TGT). The KDC provides a copy of its
certificate as well and signs the returned information
with its private key.
- The client verifies the KDC by building a certificate
path from the certificate to the trusted root CA and
uses the KDC public key to verify the reply signature.
- If all is OK, the normal Kerberos path is followed
from here (the TGT is used to get a service ticket and
hence to the user’s desktop).
About the Author
Roberta Bragg, MCSE: Security, CISSP, Security+, and Microsoft MVP is a Redmond contributing editor and the owner of Have Computer Will Travel Inc., an independent firm specializing in information security and operating systems. She's series editor for Osborne/McGraw-Hill's Hardening series, books that instruct you on how to secure your networks before you are hacked, and author of the first book in the series, Hardening Windows Systems.