This topic for the IT professional and smart card developers describes how certificates are managed and used for smart card sign-in.
When a smart card is inserted, the following steps are performed.
Unless otherwise mentioned, all operations are performed silently (CRYPT_SILENT is passed to CryptAcquireContext).
Any certificate that meets these requirements is displayed to the user with the certificate's UPN (or e-mail address or subject, depending on the presence of the certificate extensions)
Most issues during authentication occur because of session behavior changes. When changes occur, the Local Security Authority (LSA) doesn't reacquire the session context; it relies instead on the Cryptographic Service Provider to handle the session change.
Client certificates that don't contain a UPN in the subjectAltName (SAN) field of the certificate can be enabled for sign-in, which supports a wider variety of certificates and supports multiple sign-in 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 that are available on the smart card with a signature-only key are listed on the sign-in screen. This allows users to select their sign-in experience. If the policy is disabled or not configured, smart card signature-key-based certificates aren't listed on the sign-in screen.
The following diagram illustrates how smart card sign-in works in the supported versions of Windows.
Following are the steps that are performed during a smart card sign-in:
Smartcard cache entries are created for certificates with a subject name or with a subject key identifier. If the certificate has a subject name, it is stored with an index that is based on the subject name and certificate issuer. If another certificate with the same subject name and certificate issuer is used, it will replace the existing cached entry. A change in this behavior, allows for the condition when the certificate does not have a subject name, the cache is created with an index that is based on the subject key identifier and certificate issuer. If another certificate has the same the subject key identifier and certificate issuer, the cache entry is replaced. When certificates have neither a subject name nor subject key identifier, a cached entry is not created.
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, a call is made to the smart card subsystem by using the specified CSP to extract the certificate corresponding to the user's public key. (Programmatic calls for the certificate include CryptAcquireContext, CryptSetProvParam with the PIN, CryptgetUserKey, and CryptGetKeyParam.) After the temporary key is obtained, the Kerberos SSP decrypts the session key.
A SID is created for each user or group at the time a user account or a group account is created within the local security accounts database or within AD DS. The SID never changes, even if the user or group account is renamed.
For more information about the Kerberos protocol, see Microsoft Kerberos.
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 setting allows the KDC to not require the SC-LOGON EKU. SC-LOGON EKU isn't required for account mappings that are based on the public key.
Active Directory Certificate Services provides three kinds of certificate templates:
Depending on the configuration of the domain controller, one of these types of certificates is sent as a part of the AS_REP packet.
Certificate requirements are listed by versions of the Windows operating system. Certificate mapping describes how information from the certificate is mapped to the user account.
Component | Requirements |
---|---|
CRL distribution point location | Not required |
Key usage | Digital signature |
Basic constraints | Not required |
extended key usage (EKU) | The smart card sign-in object identifier isn't required. |
Certificate mapping is based on the UPN that is contained in the subjectAltName (SAN) field of the certificate. Client certificates that don't contain information in the SAN field are also supported.
SSL/TLS can map certificates that don't have SAN, and the mapping is done by using the AltSecID attributes on client accounts. The X509 AltSecID, which is used by SSL/TLS client authentication is of the form "X509: This account mapping is supported by the KDC in addition to six other mapping methods. The following figure demonstrates a flow of user account mapping logic that is used by the KDC. The certificate object is parsed to look for content to perform user account mapping. Mapping based on generic attributes isn't possible because there's no generic API to retrieve attributes from a certificate. Currently, the first method that locates an account successfully stops the search. But a configuration error occurs if two methods map the same certificate to different user accounts when the client doesn't supply the client name through the mapping hints. The following figure illustrates the process of mapping user accounts for sign-in in the directory by viewing various entries in the certificate. NT_AUTH policy is best described in the CERT_CHAIN_POLICY_NT_AUTH parameter section of the CertVerifyCertificateChainPolicy function. For more information, see CertVerifyCertificateChainPolicy. A single user certificate can be mapped to multiple accounts. For example, a user might be able to sign in to a user account and also to sign in as a domain administrator. The mapping is done by using the constructed AltSecID based on attributes from client accounts. For information about how this mapping is evaluated, see Client certificate requirements and mappings. Because each account has a different user name, we recommend that you enable the Allow user name hint Group Policy setting (X509HintsNeeded registry key) to provide the optional fields that allow users to enter their user names and domain information to sign in. Based on the information that is available in the certificate, the sign-in conditions are: A group of users might sign in to a single account (for example, an administrator account). For that account, user certificates are mapped so that they're enabled for sign-in. Several distinct certificates can be mapped to a single account. For this to work properly, the certificate can't have UPNs. For example, if Certificate1 has CN=CNName1, Certificate2 has CN=User1, and Certificate3 has CN=User2, the AltSecID of these certificates can be mapped to a single account by using the Active Directory Users and Computers name mapping. For account mapping to work across forests, particularly in cases where there isn't 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 . For the hint field to appear during smart card sign-in, the Allow user name hint Group Policy setting (X509HintsNeeded registry key) must be enabled on the client. Online Certificate Status Protocol (OCSP), which is defined in RFC 2560, enables applications to obtain timely information about the revocation status of a certificate. Because OCSP responses are small and well bound, constrained clients might want to use OCSP to check the validity of the certificates for Kerberos on the KDC, to avoid transmission of large CRLs, and to save bandwidth on constrained networks. For information about CRL registry keys, see Smart Card Group Policy and Registry Settings. The KDCs in Windows attempt to get OCSP responses and use them when available. This behavior can't be disabled. CryptoAPI for OCSP caches OCSP responses and the status of the responses. The KDC supports only OCSP responses for the signer certificate. Windows client computers attempt to request the OCSP responses and use them in the reply when they're available. This behavior can't be disabled. For sign-in to work in a smart card-based domain, the smart card certificate must meet the following conditions: To allow smart card sign-in to a domain in these versions, do the following: 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 sign-in. If the client computer isn't joined to the domain or if it's 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= , for domain name resolution. To deploy root certificates on a smart card for the currently joined domain, you can use the following command: For more information about this option for the command-line tool, see -SCRoots.Certificate revocation list distribution points
UPN in Subject Alternative Name field
Subject and Issuer fields
High-level flow of certificate processing for sign-in
Certificate processing logic
Smart card sign-in for a single user with one certificate into multiple accounts
Smart card sign-in for multiple users into a single account
Smart card sign-in across forests
OCSP support for PKINIT
Smart card root certificate requirements for use with domain sign-in
certutil.exe -scroots update