Certificate Enumeration

Updated: June 15, 2011

Applies To: Windows 7, Windows Server 2008 R2

When a smart card is inserted, the following steps are performed:

1. The smart card resource manager database searches for the smart card's cryptographic service provider (CSP).

2. A qualified container name is constructed by using the smart card reader name and is passed to the CSP. The format is \\.\<Reader name>\

3. CryptAcquireContext is called to retrieve a context to the default container. If a failure occurs, the smart card will be unusable for smart card logon.

4. The name of the container is retrieved by requesting the PP_CONTAINER parameter by using CryptGetProvParam.

5. Using the context acquired in Step 3, the CSP is queried for the PP_USER_CERTSTORE parameter, which was added in Windows Vista. (For more information, see Smart Card Subsystem Architecture.) If the operation is successful, a certificate store is returned, and the program flow skips to Step 8.

6. If the operation in Step 5 fails, the default container context from Step 3 is queried for the AT_KEYEXCHANGE key.

7. The certificate is then queried from the key context by using KP_CERTIFICATE. The certificate is added to an in-memory certificate store.

8. For each certificate in the certificate store from either Step 5 or Step 7, the following checks are performed:

   1. The certificate must be valid based on the computer system clock (not expired or valid in the future).

   2. The certificate must not be in the AT_SIGNATURE part of a container.

   3. The certificate must have a valid user principal name (UPN).

   4. The certificate must have the digital signature key usage.

   5. The certificate must have the smart card logon EKU.

      These requirements are the same requirements as in Windows Server 2003, but they are performed before the user enters the PIN. You can override many of them by using Group Policy settings.

      Any certificate that meets these requirements is displayed to the user along with the certificate's UPN (or e-mail address or subject, depending on the presence of the certificate extensions).

9. A certificate is then chosen, and the PIN is entered.

10. LogonUI.exe packages the information and sends it to Lsass.exe to process the logon attempt.

11. If successful, LogonUI.exe is closed. This causes the context acquired in Step 3 to be released.

Smart card logon flow in Windows Vista and Windows 7

Most problems during authentication occur because of session behavior. Also, the Local Security Authority (LSA) does not reacquire the context; it relies instead on the CSP to handle the session change.

In Windows Vista and Windows 7, client certificates that do not contain a UPN in the subjectAltName (SAN) field of the certificate can be enabled for logon, which supports a wider variety of certificates and supports multiple logon certificates on the same card.

Support for multiple certificates on the same card is enabled by default. New certificate types must be enabled through Group Policy.

If you enable the Allow signature keys valid for Logon credential provider policy, any certificates available on the smart card with a signature-only key are listed on the logon screen. This allows users to select their logon experience. If the policy is disabled or not configured, smart card signature key-based certificates are not listed on the logon screen.

The following diagram illustrates how smart card logon works in Windows Vista and Windows 7.

The following are the smart card logon steps:

1. WinLogon requests the logon UI credential information.

2. Asynchronously, smart card resource manager starts. The smart card credential provider:

   1. Gets credential information, a list of known credentials, or, if no credentials exist, the smart card reader information that Windows detected.

   2. Gets a list of smart card readers (using WinSCard API) and the list of smart cards inserted in each of them.

   3. Enumerates each card to verify that a logon certificate (signing) controlled by Group Policy is present. If the certificate is present, the smart card credential provider copies it into a temporary, secure cache on the computer or terminal.

4.  Notifies the logon UI that it has new credentials.  
      

3. The logon UI requests the new credentials from the smart card credential provider. As a response, the smart card credential provider provides to the logon UI each logon certificate, and corresponding logon tiles are displayed. The user selects a smart card-based logon certificate tile, and Windows displays a PIN dialog box.

4. The user enters the PIN, and then clicks the arrow or presses ENTER. The smart card credential provider encrypts the PIN.

5. The credential provider that resides in the LogonUI process (system) collects the PIN. As part of packaging credentials in the smart card credential provider, the data is packaged in a KERB_CERTIFICATE_LOGON structure. The main contents of the KERB_CERTIFICATE_LOGON structure are the smart card PIN, cspdata (such as reader name and container name), user name and domain name. User name is required if the logon domain is not in the same forest because it enables a certificate to be mapped to multiple user accounts.

6. The credential provider now wraps the data (such as encrypted PIN, container name, reader name, and card key specification) and sends it back to LogonUI.

7. Winlogon presents the data from LogonUI to LSA with LSALogonUser.

8. LSA calls the Kerberos authentication package (Kerberos SSP) to create a Kerberos authentication service request (KRB_AS_REQ) containing a pre-authenticator (as specified in RFC 4556: Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) (https://go.microsoft.com/fwlink/?LinkId=93352)).

   If the authentication is performed by using a certificate that has a key usage of digital signature, the pre-authentication data consists of the user's public certificate and the certificate digitally signed with the corresponding private key.

   If the authentication is performed by using a certificate that has a key usage of key encipherment, the pre-authentication data consists of the user's public certificate and the certificate encrypted with the corresponding private key.

9. To sign the request digitally (as per RFC 4556), a call is made to the corresponding CSP for a private key operation. Because the private key in this case is stored in a smart card, the smart card subsystem is called, and the necessary operation is completed. The result is sent back to the Kerberos SSP.

10. The Kerberos SSP sends an authentication request for a ticket-granting ticket (TGT) (as per RFC 4556) to the Key Distribution Center (KDC) service that runs on a domain controller.

11. The KDC finds the user's account object in Active Directory Domain Services (AD DS), as detailed in Client certificate mappings, and uses the user's certificate to verify the signature.

12. The KDC validates the user's certificate (time, path, and revocation status) to ensure that the certificate is from a trusted source. The KDC uses CryptoAPI to build a certification path from the user's certificate to a root certification authority (CA) certificate that resides in the root store on the domain controller. The KDC then uses CryptoAPI to verify the digital signature on the signed authenticator that was included in the pre-authentication data fields. The domain controller verifies the signature and uses the public key from the user's certificate to prove that the request originated from the owner of the private key that corresponds to the public key. The KDC also verifies that the issuer is trusted and appears in the NTAUTH certificate store.

13. The KDC service retrieves user account information from AD DS. The KDC constructs a TGT based on the user account information that it retrieves from AD DS. The TGT includes the user's security identifier (SID), the SIDs for universal and global domain groups to which the user belongs, and (in a multidomain environment) the SIDs for any universal groups of which the user is a member. The TGT's authorization data fields include the list of SIDs.

14. The domain controller returns the TGT to the client as part of the KRB_AS_REP response.

• Privilege attribute certificate (PAC)
  
  
• User's SID
  
  
• SIDs of any groups of which the user is a member
  
  
• A request for ticket-granting service (TGS)
  
  
• Pre-authentication data
  
  

The response is as per RFC 4556. TGT is encrypted with the master key of the KDC, and the session key is encrypted with a temporary key. This temporary key is derived based on RFC 4556. Using CryptoAPI, the temporary key is decrypted. As part of the decryption process, if the private key is on a smart card, the call is made back to the smart card subsystem by using the specified CSP to extract the certificate corresponding to the user's public key. (Programmatic calls include CryptAcquireContext, CryptSetProvParam with the PIN, CryptgetUserKey, and CryptGetKeyParam for the certificate.) After the temporary key is obtained, the Kerberos SSP decrypts the session key.  
  

15. The client validates the reply from the KDC (time, path, and revocation status). It first verifies the KDC's signature by the construction of a certification path from the KDC's certificate to a trusted root CA, and then it uses the KDC's public key to verify the reply signature.

16. Now that a TGT has been obtained, the client obtains a service ticket to the local computer that is used to log on to the computer.

17. On success, LSA stores the tickets and returns success to LSALogonUser. On this success message, user profile, Group Policy, and other actions are performed.

18. After the user profile is loaded, CertPropSvc detects this event, reads the certificates from the card (including the root certificates), and then populates them into the user's certificate store (MYSTORE).

19. CSP to smart card resource manager communication happens on the LRPC Channel.

20. On successful authentication, certificates are propagated to the user's store (MYSTORE) asynchronously by the Certificate Propagation Service (CertPropSvc).

21. When the card is removed, certificates in the temporary secure cache store are removed. The Certificates are no longer available for logon, but they remain in the user's certificate store (MYSTORE).

For more information about Kerberos, see How the Kerberos Version 5 Authentication Protocol Works (https://go.microsoft.com/fwlink/?LinkID=27175).

By default, the KDC verifies that the client's certificate contains the smart card client authentication EKU szOID_KP_SMARTCARD_LOGON. However, if enabled, the Allow certificates with no extended key usage certificate attribute Group Policy allows the KDC to not require the SC-LOGON EKU. SC-LOGON EKU is not required for account mappings that are based on the public key.

KDC certificate

Active Directory Certificate Services provides three kinds of certificate templates:

• Domain controller

• Domain controller authentication

• Kerberos authentication (new in Windows Server 2008 and included in Windows Server 2008 R2)

Depending on the configuration of the domain controller, one of these types of certificate is sent as a part of the AS_REP packet. For more information about certificate templates, see Active Directory Certificate Server Enhancements in Windows Server 2008 (https://go.microsoft.com/fwlink/?LinkId=83212).

Client certificate mappings

Certificate mapping is based on the UPN that is contained in the subjectAltName (SAN) field of the certificate. Client certificates that do not contain the subjectAltName extension in the certificate are also supported.

SSL/TLS can map certificates that do not have SAN, and the mapping is done by using the AltSecID attributes on client accounts. The X509 AltSecID used by SSL/TLS client authentication is of the form "X509: <I>"<Issuer Name>"<S>"<Subject Name>. The <Issuer Name> and <Subject Name> are taken from the client certificate, with '\r' and '\n' replaced with ','.

This account mapping is to be supported by the KDC. The KDC also supports six other mapping methods. The following figure demonstrates a flow of user account mapping logic used by KDC.

The certificate object is parsed to look for certain content to perform user account mapping.

• When a user name is also provided with the certificate, the user name is used to locate the account object. This operation is the fastest, because string matching occurs.

• When only the certificate object is provided, a series of operations are performed to locate the user name to map the user name to an account object.

• When no domain information is available for authentication, the local domain is used by default. If any other domain is to be used for lookup, then a domain name hint should be provided to perform the mapping and binding.

Mapping based on generic attributes is not possible, because there is no generic API to retrieve attributes from a certificate. Currently, the first method that locates an account successfully stops the search. But if two mapping methods map the same certificate to different user accounts when the client does not supply the client name via the mapping hints, then a configuration error occurs.

For more information about mapping certificates to user accounts, see Deploying a Public Key Infrastructure(https://go.microsoft.com/fwlink/?LinkId=93737).

The following figure illustrates the process of mapping user accounts for logon in the directory by viewing various entries in the certificate.

NT_AUTH policy is best described under CERT_CHAIN_POLICY_NT_AUTH in CertVerifyCertificateChainPolicy (https://go.microsoft.com/fwlink/?LinkId=93738).

Smart card logon of a single user with one certificate into multiple accounts

A single user certificate can be mapped to multiple accounts. For example, a user might be able to log on to a user account and also to log on as a domain administrator. The mapping is done using the constructed AltSecID based on attributes from client accounts. For information about how this mapping is evaluated, see Client certificate mappings.

Based on the information available in the certificate, the conditions for logon are:

1. If no UPN is present in the certificate:

   1. Logon can occur in the local forest or in another forest if a single user with one certificate needs to log on to different accounts.

   2. A hint must be supplied if mapping is not unique (for example, if multiple users are mapped to the same certificate).

2. If a UPN is present in the certificate:

   1. The certificate cannot be mapped to multiple users in the same forest.

   2. The certificate can be mapped to multiple users in different forests. For a user to log on to other forests, an X509 hint must be supplied to the user.

Smart card logon of multiple users into a single account

A group of users might log on to a single account (for example, an administrator account). For that account, user certificates are mapped so that they are enabled for logon.

Several distinct certificates can also be mapped to a single account. For this to work properly, the certificate cannot have UPNs.

For example, if Certificate1 has CN=CNName1, Certificate2 has CN=User1, and Certificate3 has CN=User2, then the AltSecID of these certificates can be mapped to a single account by using the Active Directory Users and Computers name mapping.

Smart card logon across forests

For account mapping to work across forests, particularly in cases where there is not enough information available on the certificate, the user might enter a hint in the form of a user name such as domain\user or a fully qualified UPN such as user@contoso.com.

OCSP support for PKINIT

Online Certificate Status Protocol (OCSP), defined in RFC 2560, enables applications to obtain timely information about the revocation status of a certificate. Because OCSP responses are small and well bounded, constrained clients might want to use OCSP to check the validity of the certificates for Kerberos KDC and to avoid transmission of large CRLs and save bandwidth on constrained networks. For information about CRL registry keys, see Smart Card Group Policy and Registry Settings.

Windows KDCs attempt to get OCSP responses and use them when available. This behavior cannot be disabled. CryptoAPI for OCSP caches OCSP responses and the status of the responses. KDC supports only OCSP responses for signer certificate.

Windows client computers attempt to request the OCSP responses and use them in the reply, when they are available. This behavior cannot be disabled.

Smart card root certificate requirements for use with domain logon

For smart card-based domain logon to work, there are some specific conditions that the smart card certificate must meet.

• The KDC root certificate on the card must have an HTTP CRL distribution point listed in its certificate.

• The smart card logon certificate must have the HTTP CRL distribution point listed in its certificate.

• The CRL distribution point must have a valid CRL published and a delta CRL, if applicable, even if the CRL distribution point is empty.

• The smart card certificate must contain one of the following:

  • A subject field that contains the DNS domain name in the distinguished name. If it does not, resolution to an appropriate domain fails, and Remote Desktop and domain logon with smart card fail.
  • A UPN where the domain part of the UPN must resolve to the actual domain. For example, if the domain name is Engineering.Corp.Contoso, the UPN is username@engineering.corp.contoso.com. If any part of the domain name is omitted, such as username@engineering.contoso.com, the Kerberos client will not be able to find the appropriate domain.

While HTTP CRL distribution points are on by default in Windows Server 2008, Windows Server 2008 R2 does not include HTTP CRL distribution points. To allow smart card domain logon in Windows Server 2008 R2, do the following:

1. Enable HTTP CRL distribution points on the CA.

2. Restart the CA.

3. Reissue the KDC certificate.

4. Issue or reissue the smart card logon certificate.

5. Propagate the updated root certificate to the smart card that you want to use for domain logon.

The workaround is to enable the Allow user name hint Group Policy setting (X509HintsNeeded registry key), which allows the user to supply a hint in the credentials user interface for domain logon.

If the client computer is not joined to the domain or if it is joined to a different domain, the client computer can resolve the server domain only by looking at the distinguished name on the certificate, not the UPN. For this scenario to work, the certificate requires a full subject, including DC=<DomainControllerName>, for domain name resolution.

To deploy root certificates on a smart card for the currently joined domain, you can use the following command:

certutil –scroots update