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 and SAP Enhance Partnership with Teams Integration

    Microsoft and SAP this week described continuing partnership efforts on Microsoft Azure, while also planning a Microsoft Teams integration with SAP's enterprise resource planning product and other solutions.

  • Blue Squares Graphic

    Microsoft Previews Azure IoT Edge for Linux on Windows

    Microsoft announced a preview of Azure IoT Edge for Linux on Windows, which lets organizations tap Linux virtual machine processes that also work with Windows- and Azure-based processes and services.

  • How To Automate Tasks in Azure SQL Database

    Knowing how to automate tasks in the cloud will make you a more productive DBA. Here are the key concepts to understand about cloud scripting and a rundown of the best tools for automating code in Azure.

  • Microsoft Open License To End Next Year for Government and Education Groups

    Microsoft's "Open License program" will end on Jan. 1, 2022, and not just for commercial customers, but also for government, education and nonprofit organizations.

comments powered by Disqus