In-Depth

Smart Card Logon Integration with Kerberos

Learn the basic behind-the-scenes steps for Smart Card logon under Kerberos.

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:

  1. If a reader is attached to the user’s machine, the user is prompted to put in a card.
  2. Then the user is prompted to enter a pin.
  3. The logon request is passed to the Local Security Authority (LSA).
  4. LSA communicates with the Kerberos authentication package on the client.
  5. 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.
  6. The KDC builds a certification path from the certificate to a root CA in the system root store.
  7. 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.
  8. The KDC uses the public key from the certificate to verify the signature.
  9. 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.
  10. KDC looks in the AD for account information.
  11. 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.
  12. 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.
  13. 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.

Featured

  • Microsoft Adds Modular Datacenter to Azure Space Efforts

    Microsoft this week introduced the Microsoft Azure Modular Datacenter as part of its overall Azure Space effort.

  • Microsoft and Partners Continue To Block Trickbot To Protect Elections

    Microsoft on Tuesday provided an update about its efforts, along with partners, to take down the Trickbot criminal network, which uses servers and devices to spread ransomware.

  • Microsoft Releases Windows 10 and Windows Server Versions 20H2

    Microsoft on Tuesday announced the "semiannual channel" release of Windows 10 version 20H2, otherwise known as the "October 2020 Update," and it also released Windows Server version 20H2.

  • How To Debug a PowerShell Script

    Here are three pointers for finding and fixing any bugs in your PowerShell script, no matter how long it is.

comments powered by Disqus