Windows Vista Smart Card Infrastructure

Windows Vista® Smart Card Infrastructure provides details about the Microsoft® Windows® smart card infrastructure and how smart card-related components work in Windows. This document also contains information about troubleshooting and debugging tools, and tools that information technology (IT) developers and administrators can use to deploy smart card-based strong authentication in the enterprise.

Audience

This document provides low-level details of how the Windows smart card infrastructure works. You must have basic knowledge of public key infrastructure (PKI) and smart card concepts to make full use of the recommendations in this document. This document is intended for:

• Developers and enterprise IT professionals who are planning or implementing a smart card deployment. This includes IT directors and IT personnel.
• Smart card vendors who write smart card mini-drivers or credential providers. This document details the inner workings of the Windows smart card architecture and provides information about how IT departments will plan for smart card deployments.

Windows Smart Card Infrastructure

Smart card support was initially included in Windows 2000. Windows Server 2003 and Windows XP also support smart cards.

Because smart cards were integrated into Windows 2000, users can log on and sign and encrypt e-mail digitally. However, there are some limitations in the implementation.

Before Windows Vista:

• A smart card could support only one certificate for logon.
• Only one container on the smart card could be marked default. Additional certificates could be stored on the smart card for other purposes, such as S/MIME.
• Changing the PIN and unblocking a smart card were not natively supported or integrated. As a result, a user had to log on first with a standard user name and password to perform these tasks.

Windows Vista enhancements

Winlogon has been re-architected in Windows Vista. In previous versions of Windows, a custom GINA dynamic link library (DLL) was used to support customizable user identification and authentication. On Windows Vista, the GINA functionality has been distributed among three components:

• Winlogon
• Logon user interface (UI)
• Credential providers

MSGINA.DLL has been removed, and custom GINAs will not be loaded on systems running Windows Vista and later versions. Both the password credential provider and the smart card credential provider are provided by default, and the ability to support custom authentication mechanisms will require the creation of a custom credential provider. After Winlogon launches the logon UI, it loads registered credential providers. The smart card credential provider uses interfaces that are exposed through the credential provider framework to gather the required credentials, package them, and return them to the logon UI. Then the logon UI passes the credentials to Winlogon to be used for Kerberos authentication.

In Vista, Winlogon supports multiple logon certificates and containers on the same smart card. The number of certificates that can be stored and containers that can be created depends on how much space is available on the smart card.

Each smart card must have a cryptographic service provider (CSP). A CSP uses the Cryptography Application Programming Interface (CAPI) interfaces on the top and the WinSCard APIs at the bottom. (For detailed information, see Smart card subsystem architecture.)

In the past, writing a smart card CSP was not a trivial task. However, a new CSP called the Base CSP now helps facilitate writing a smart card CSP. The Base CSP allows smart card vendors to write card-specific modules called smart card mini-drivers. Microsoft provides the Base CSP as part of the platform. A downloadable package of it exists for Windows XP SP2, Windows 2000 SP4, and Windows Server 2003 SP1. A smart card mini-driver is an interface that Microsoft supports for smart card vendors to write implementations to their smart card. This is analogous to writing a printer driver for a printer.

WinSCard API has been extended to provide caching (storing of non-sensitive data on a per-user-basis) at the smart card resource manager level. The smart card resource manager was formerly called the smart card service.

To support additional cryptographic algorithms and to provide extensible architecture, Cryptography API: Next Generation (CNG) was designed. Architecturally, this is parallel to CAPI. As with CSP, a key storage provider (KSP) is beneath the CNG. In Windows Vista, smart card KSP implementation is provided by default. The same smart card mini-driver interface that is available for Base CSP is also applicable for smart card KSP. Smart card mini-driver support for RSA and elliptic curve cryptography (ECC) is available with smart card KSP.

Architecture

The smart card registry database is located in HKLM\Software\Microsoft\Cryptography\Calais\SmartCard. This database contains smart card and smart card reader information. The smart card infrastructure in Windows includes two primary components:

• Windows interactive logon architecture
• Smart card subsystem architecture

Windows interactive logon architecture

Before Windows Vista, the Windows interactive logon architecture included the components shown in Table 1.

Table 1   Pre-Windows Vista interactive logon components

Component	Description
Winlogon	Provides interactive logon infrastructure.
Graphical Identification and Authentication (GINA) component	Provides interactive UI rendering.
Local Security Authority (LSA)	Processes logon credentials.
Authentication packages	Includes NTLM and Kerberos. Communicates with server authentication packages to authenticate users.

Windows Vista credential provider architecture

Table 2 shows the components in the Windows Vista interactive logon architecture.

Table 2   Windows Vista interactive logon components

Component	Description
Winlogon	Provides interactive logon infrastructure.
Logon UI	Provides interactive UI rendering.
Credential providers (password and smart card)	Describes credential information and serializing credentials.
LSA	Processes logon credentials.
Authentication packages	Includes NTLM and Kerberos. Communicates with server authentication packages to authenticate users.

Figure 1   Windows credential provider architecture

Windows Vista interactive logons begin when the user presses CTRL+ALT+DEL. The CTRL+ALT+DEL key combination is called a secure attention sequence (SAS). Winlogon registers this sequence during the boot process, in order to keep other programs and processes from using it. The logon UI then generates the tile from information received from the registered credential providers. The following figure shows the Windows Vista logon dialog.

Figure 2  Windows Vista logon user interface

A user who logs on to a computer using either a local account or a domain account must enter a user name and password. These credentials are used to verify the user’s identity. However, in the case of smart card logons, a user’s credentials are contained on the smart card’s security chip. An external device called a smart card reader reads the security chip. During a smart card logon, a user enters a personal identification number (PIN) instead of a user name, domain, and password.

Credential providers are in-process COM objects that are used to collect credentials in Windows Vista and run in local system context. In summary, the logon UI provides interactive UI rendering, Winlogon provides interactive logon infrastructure, and credential providers help gather and process credentials.

In Windows Vista, Winlogon instructs the logon UI to display tiles after it receives a SAS event. Logon UI queries each credential provider for the number of credentials it wants to enumerate. Credential providers have the option of specifying one of these tiles as the default. After all providers have enumerated their tiles, the logon UI displays them to the user. The user interacts with a tile to supply his or her credentials. The logon UI submits these credentials for authentication.

Combined with supporting hardware, credential providers can extend the Microsoft Windows operating system to enable users to log on through biometric (fingerprint, retinal, or voice recognition), password, PIN, smart card certificate, or any custom authentication package a third-party developer wants to create. Enterprises and IT professionals may develop and deploy custom authentication mechanisms for all domain users and may explicitly require users to use this custom logon mechanism.

Credential providers are not enforcement mechanisms. They are used to gather and serialize credentials. The LSA and authentication packages enforce security.

Credential providers may be designed to support single sign-on (SSO), authenticating users to a secure network access point (by using RADIUS and other technologies) as well as computer logon. Credential providers are also designed to support application-specific credential gathering, and may be used for authentication to network resources, joining computers to a domain, or to provide administrator consent for User Account Control (UAC).

Multiple credential providers may co-exist on a computer.

Credential providers are registered on a Windows Vista computer and are responsible for:

• Describing the credential information required for authentication.
• Handling communication and logic with external authentication authorities.
• Packaging credentials for interactive and network logon.

The Credential Provider API does not design UI. It does describe what needs to be rendered. Only password credential provider is available in safe mode. In-box smart card credential provider is available in safe mode with networking.

For more information on credential providers and their uses, please refer to the Credential Provider Technical Reference (https://go.microsoft.com/fwlink/?LinkId=93340).

Figure 3 illustrates Windows Vista logon screen flow with PIN unblock and PIN change.

Figure 3   PIN unblock and PIN change user experience

Smart card subsystem architecture

Vendors and partners are very important for the success of smart card-based scenarios. Vendors provide smart cards and smart card readers, and in many cases the smart card and reader vendors are different. Reader drivers are written to the PC/SC standard version 1.0. Each smart card must have a CSP that uses the CAPI interfaces on the top and the WinSCard APIs at the bottom. The GINA module also has smart card logon capability to provide the relevant user interface for capturing the credentials and subsequent marshalling to be sent to the LSALogonUser for authentication.

Base CSP and smart card mini-driver architecture for Windows 2000, Windows XP, and Windows 2003

Requirements: The Base CSP must be installed. The Base CSP is a free, optional download available at the Microsoft Web site (https://go.microsoft.com/fwlink/?LinkId=93341).

Figure 4 illustrates how CAPI, CSPs, the Base CSP, and smart card mini-drivers are architecturally layered.

Figure 4   Base CSP and smart card mini-driver architecture

Smart card selection heuristics

Container specification levels

In response to a CryptAcquireContext call, the Base CSP will try to match the container that the caller specifies to a specific card and reader. The caller can provide a container name with varying levels of specificity, shown in the following list, sorted from more-specific to less-specific requests.

Similarly for the smart card KSP, NCryptOpenKey takes the same format as shown in Table 3. Before open key, a call NCryptOpenStorageProvider(MS_SMART_CARD_KEY_STORAGE_PROVIDER) is made.

Table 3   Container specification levels

Type	Name	Format
I	Reader Name and Container Name	\\.\<Reader Name>\<Container Name>
II	Reader Name and Container Name (NULL)	\\.\<Reader Name>\
III	Container Name Only	<Container Name>
IV	Default Container (NULL) Only	NULL

For the first two cases, in which a reader name is provided, the Base CSP usually will search for the specified reader and perform the requested operation on the card inserted in that reader. For the second two cases, in which a smart card reader name is not provided, the Base CSP will search for a card and reader suitable for the current request, beginning with cards already known to the Base CSP and continuing to all smart cards and readers available with the smart card subsystem.

For each of the above cases, the Base CSP will first search for a matching card in its list of cached card data. This cache includes a list of smart cards and associated smart card state information that the CSP has encountered in the current session (where the session will typically be the lifetime of the current process). In general, if a matching smart card is found in the cache, the card handle associated with the cache item should be refreshed. This determines whether the card is still in the reader, because the smart card might have been removed since the cache item was created.

If a matching smart card is found cached, but the cached smart card handle is no longer valid, the SCardUIDlg API is used to refresh the card handle. Additional information, such as the serial number of the matching smart card, is provided to SCardUIDlg to help filter candidate smart cards quickly.

Container operations

Three main container operations can be requested using CryptAcquireContext. These are:

1. Create new container (CRYPT_NEWKEYSET)
2. Open existing container
3. Delete container (CRYPT_DELETEKEYSET)

The heuristics that are used to associate a user context with a particular card and reader are based mainly on the container operation requested and the level of container specification used.

Table 4 shows the restrictions for the container creation operation.

Table 4   Container creation operation restrictions

Specification	Restriction
No Silent context	Key container creation must always be able to show UI, such as the PIN prompt.
No overwriting existing containers	If the specified container already exists on the chosen smart card, either chose another card or cancel the operation.

Context flags

Table 5 shows the context flags for the container creation operation restrictions.

Table 5   Restriction flags

Flag	Description
CRYPT_SILENT	No UI may be displayed during this operation.
CRYPT_MACHINE_KEYSET	No cached data should be used during this operation.
CRYPT_VERIFYCONTEXT	Only public data may be accessed on the smart card.

In addition to container operations and container specification, you must consider other user options, such as the above CryptAcquireContext flags, during card selection.

Creating a new container in silent context

Applications can call the Base CSP with CRYPT_DEFAULT_CONTAINER_OPTIONAL, set the PIN in silent context, and then create a new container in silent context:

1. Call CryptAcquireContext passing the smart card reader name in as type II, specifying the CRYPT_DEFAULT_CONTAINER_OPTIONAL flag.
2. Call CryptSetProvParam by specifying PP_KEYEXCHANGE_PIN or PP_SIGNATURE_PIN and a null-terminated ASCII PIN.
3. Release the context acquired in Step 1.
4. Call CryptAcquireContext with CRYPT_NEWKEYSET specifying the type I format.
5. Call CryptGenKey to create the key.

Smart card selection behavior

In some of the following scenarios, the user can be prompted to insert a smart card. If the user context is silent, this operation fails and no UI is displayed. Otherwise, in response to the UI, the user may either insert a smart card or click Cancel. If the user cancels the operation, the operation fails.

Figure 5   Smart card selection behavior

In general, card selection behavior will be handled by the SCardUIDlgSelectCard API. The Base CSP will interact with this API by calling it directly. The Base CSP will also send callback functions, whose purpose will be to filter and match candidate smart cards. Callers of CryptAcquireContext provide card matching information. Internally, the Base CSP uses a combination of smart card serial numbers, reader names, and container names to find specific smart cards.

Each call to SCardUI* may result in additional information read from a candidate smart card. The Base CSP smart card selection callbacks cache this information.

The SCardUI* API is used to refresh smart card handles, because a target smart card may be removed or re-inserted after a card handle has been cached. The matching serial number is discovered by FindCachedCard(), which is passed to FindCard() along with a status indicating that the search was successful but that the card handle needs to be re-acquired. (Or that the corresponding smart card state structure could be returned, instead of just the serial number. This would prevent the callback from having to search the list of cards again.) FindCard will provide the serial number to the appropriate card-matching callback using SCardUI*.

Making a reader match

For container specification levels I and II, the smart card selection process is less complex because only the smart card in the named reader can be considered a match.

1. Find the requested reader. If it cannot be found, the process fails. (This requires a cache search by reader name.)
2. If no smart card is in the reader, the user is prompted to insert a smart card (only in non-silent mode; if the call is made in silent mode, it will fail).
3. For level II only, the name of the default container on the chosen smart card is determined.
4. For container operations B (open existing) and C (delete), find the specified container. If the specified container cannot be found on this smart card, the user is prompted to insert a smart card.
5. For container operation A (create new), if the specified container already exists on this smart card, the process fails.

Making a smart card match

For container specification levels III and IV, a broader method is used to match an appropriate card with a user context, because multiple cached smart cards might meet the criteria provided.

Open existing default container - no reader specified

1. For each smart card already known by the Base CSP, look for a valid default container. An operation is attempted on the cached SCARDHANDLE to verify its freshness. If the smart card handle is not valid, the Base CSP continues to search for a new smart card.
2. If a matching card is not found in the Base CSP cache, call into the smart card subsystem. SCardUIDlgSelectCard() is used with an appropriate callback filter to find a matching card with a valid default container.

Open existing GUID-named container, no reader specified

1. For each smart card that the Base CSP already knows, look for the requested container. Attempt an operation on the cached SCARDHANDLE to verify its freshness. If the card handle is not valid, the smart card’s serial number is passed to the SCardUI* API to continue searching for this specific smart card (rather than only a general match for the container name).
2. If a matching card is not found in the Base CSP cache, a call is made into the smart card subsystem. SCardUIDlgSelectCard() is used with an appropriate callback filter to find a matching card with the requested container. Or, if a smart card serial number resulted from the search in Step 1, the callback filter attempts to match the serial number, not the container name.

Create new container, no reader specified

If the PIN is not cached, no CRYPT_SILENT is allowed on container creation because the user must be prompted for a PIN, at a minimum.

For other operations, the caller may be able to acquire a “verify” context against the default container (CRYPT_DEFAULT_CONTAINER_OPTIONAL) and then make a CryptSetProvParam call to cache the user PIN for subsequent operations.

1. For each smart card already known by the CSP, refresh the stored SCARDHANDLE and make the following checks:
   1. If the smart card has been removed, continue the search.
   2. If the smart card is still present but already has the named container, continue the search.
   3. If the smart card is available, but a call to CardQueryFreeSpace indicates that the card has insufficient storage for an additional key container, continue the search.
   4. Otherwise, use the first available smart card that meets the above criteria for the container creation.
2. If a matching smart card is not found in the CSP cache, call into the smart card subsystem. The callback used to filter enumerated smart cards should verify that a candidate smart card does not already have the named container, and that CardQueryFreeSpace indicates that the card has sufficient space for an additional container. If no suitable card is found, display UI prompting the user to insert a smart card.

Delete a container

1. If the specified container name is NULL, then the default container is deleted. Deleting the default container causes a new default container to be selected arbitrarily. For this reason, this operation is not recommended.
2. For each smart card already known by the CSP, refresh the stored SCARDHANDLE and make the following checks.
   1. If the smart card does not have the named container, continue the search.
   2. If the smart card has the named container, but the card handle is no longer valid, store the serial number of the matching smart card and pass it to SCardUI*.
3. If a matching card is not found in the CSP cache, call into the smart card subsystem. The callback used to filter enumerated cards should verify that a candidate card has the named container. If a serial number was provided as a result of the above cache search, the callback should filter enumerated cards on serial number rather than container matches. If the context is non-silent, and no suitable smart card is found, display UI that prompts the user to insert a smart card.

Caching with Base CSP and smart card KSP (Windows Vista only)

Data caching

Each CSP implements the current smart card data cache separately. The Base CSP, for example, implements a robust caching mechanism that allows a single process to minimize card I/O operations.

The existing in-process cache works as follows.

1. The application requests a CAPI operation. For example, a user certificate is to be read from the card.
2. The CSP first checks its cache for the item.
3. If the item is not found in the cache, or if the item is cached but is not up to date, the item is then read from the smart card.
4. After any item has been read from the smart card, it is added to the cache. Any existing out-of-date (stale) copy of that item is replaced.

The primary problem in the existing solution is that each smartcard-aware process on the system must duplicate the above behavior and keep its own copy of the same data. The current model is insufficient. A process must be able to use card data previously read by other processes.

The global data cache is hosted in the smart card resource manager. Windows Vista includes two new public Windows smart card API calls, SCardWriteCache and SCardReadCache. These API calls make global data caching functionality available to applications. These API calls are supported only on Windows Vista client computers.

1. Every smart card that conforms to the new smart card mini-driver specification has a 16-byte card identifier. This value will be used to identify cached data pertaining to a given smart card uniquely. For the sake of simplicity, the standard Windows GUID type will be used.
2. These APIs allow an application to add data to, and to read data from, the global cache.

You must implement two new APIs, RedirectedSCardWriteCache and RedirectedSCardReadCache, with the corresponding IOCTLs and handlers to help redirect the terminal server.

PIN caching

The PIN cache helps limit the user having to reenter a PIN each time the smart card is de-authenticated. After a smart card is authenticated, it will not differentiate among host-side applications; any application can access private data on the smart card. To mitigate this, the smart card is put under an exclusive state when an application authenticates to the smart card. However, this means that other applications cannot talk to the smart card and will be blocked. Therefore, such exclusive connections are minimized. The problem is that a protocol like Kerberos requires multiple signing operations, and therefore will either require exclusive access to the smart card over an extended period, or require multiple authentication operations. This is where the PIN cache comes into play and allows minimal exclusive use of the smart card without forcing the user to enter his or her PIN multiple times.

Here is an example that illustrates exactly how this works. In this scenario, there are two applications: Outlook and Internet Explorer. Both applications use smart cards for different purposes.

1. The user starts Outlook and tries to send a signed e-mail. The private key is on the smart card.
2. Outlook prompts the user for the smart card PIN. The user enters the correct PIN.
3. E-mail data is sent to the smart card for the signature operation. The Outlook client formats the response and sends the e-mail.
4. The user opens Internet Explorer and tries to access a protected site that requires TLS client authentication.
5. Internet Explorer prompts the user for the smart card PIN. The user enters the correct PIN.
6. The TLS-related private key operation occurs on the smart card, and the user is authenticated and logged in.
7. The user returns to Outlook to send another signed e-mail. This time, the user is not prompted for a PIN, because the PIN is cached from the previous operation. Similarly, if the user uses Internet Explorer again to do another operation, Internet Explorer will not prompt the user for a PIN.

The Base CSP internally maintains a per-process cache of the PIN to enable caching. The PIN is stored encrypted in memory. The functions that are used to secure the PIN are RtlEncryptMemory, RtlDecryptMemory, and RtlSecureZeroMemory, which will zero out buffers that have contained the PIN.

Base CSP and KSP-based architecture in Windows Vista

Figure 6   Cryptography architecture in Windows Vista

Base CSP and smart card KSP properties in Windows Vista

The following properties are supported in Windows Vista.

Table 6   Base CSP and smart card KSP properties

Property	Description
PP_USER_CERTSTORE	Used to return an HCERTSTORE that contains all user certificates on the smart card. Read only (used only by CryptGetProvParam). Caller responsible for closing cert store. Certificate encoded using PKCS_7_ASN_ENCODING or X509_ASN_ENCODING CSP should set KEY_PROV_INFO on certificates Certificate store should be assumed to be an in-memory store. Certificates should have a valid CRYPT_KEY_PROV_INFO as a property
PP_ROOT_CERTSTORE	Read/Write (both CryptGetProvParam and CryptSetProvParam) Used to write a collection of root certificates to the smart card or return an HCERTSTORE containing root certificates from the smart card Used primarily for domain join with smart card Caller responsible for closing cert store
PP_SMARTCARD_READER	Read only (only CryptGetProvParam) Returns the smart card reader name as an ANSI string that is used to construct a fully qualified container name (reader + container)
PP_SMARTCARD_GUID	Return card GUID (also known as serial number), which should be unique for each smart card Used by the certificate propagation service to track the source of a root certificate
PP_UI_PROMPT	Used to set the search string for SCardUIDlgSelectCard card insertion dialog Persistent for the entire process once set Write only (used only by CryptSetProvParam)

Implications of CSPs in Windows Vista

CSP will continue to be supported in Windows Vista. It is not recommended, however, especially if you want to communicate with smart cards. Using the existing Base CSP and smart card KSP with the smart card mini-driver model for smart cards provides significant benefits in terms of performance and PIN and data caching. The same mini-driver can be configured to work under both CAPI and CNG layers, benefiting from enhanced cryptographic support, elliptic curve cryptography, and AES.

If a smart card is registered by both a CSP and a smart card mini-driver, then whichever of them was installed more recently will be used for communication to the smart card.

When to write a smart card mini-driver, CSP, or KSP

CSP and KSP are meant to be written only if specific functionality is not available in the current smart card mini-driver architecture. For example, the smart card mini-driver architecture supports hardware security modules (HSMs), so a CSP or KSP is not required.

For more information about how to write a smart card mini-driver, CSP, or KSP, see Enterprise Smart Card Deployment in the Microsoft Windows Smart Card Framework (https://go.microsoft.com/fwlink/?LinkId=93348).

Windows Vista Group Policy Settings

The following table illustrates the Group Policy settings that can be used on a per-computer basis. There are no settings on a per-user basis. Some of these settings can be applied only to a Windows Vista level functional domain, for example Domain Hints. All of the keys are located under \Policies\Microsoft\Windows\SmartCardCredentialProvider and \Policies\Microsoft\Windows\CertProp

From the Group Policy Editor (gpedit.exe), you can edit and apply Group Policy to computers on the domain. Smart card-related policies exist under

Computer Configuration\Administrative Templates\Windows Components\Smart Card

Figure 7   Smart card-related settings in Group Policy

After the Domain Administrator applies them, on the user’s local computer they will reside in HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\SmartCardCredentialProvider

Table 7  Group Policy settings

Key	Description
AllowSignatureOnlyKeys	Allows signature keys valid for logon. This setting also applies whenever the credential UI is called. Using this setting allows signature key-based certificates to be enumerated and available for logon. 1 (Enabled): Any certificates available on the smart card with a signature-only key will be listed on the logon screen. 0 (Disabled): Any available smart card signature key-based certificates will not be listed on the logon screen. Not configured: Any available smart card signature key-based certificates will not be listed on the logon screen.
AllowCertificatesWithNoEKU	Allows certificates without an EKU set to be used for logon. In previous versions of Windows, the EKU extension was required to have the smart card logon object identifier present. This setting controls that restriction. 1 (Enabled): Only the smart card-based certificates that contain the smart card logon object identifier or no EKU extension will be listed on the logon screen. 0 (Disabled): Only those smart card-based certificates that contain the smart card logon object identifier will be listed on the logon screen. Not configured: Only those smart card based certificates that contain the smart card logon object identifier will be listed on the logon screen.
AllowTimeInvalidCertificates	Allows certificates to be displayed for logon that are either expired or not yet valid. In previous versions of Windows, certificates were required to contain a valid time and not to be expired. The certificate must still be accepted by the domain controller in order to be used. This setting controls only whether the certificate is displayed on the client computer. 1 (Enabled): Certificates will be listed on the logon screen regardless of whether they have invalid times or their time validity has expired. 0 (Disabled): Certificates that are expired or not yet valid will not be listed on the logon screen. Not configured: Certificates that are expired or not yet valid will not be listed on the logon screen.
AllowIntegratedUnblock	Allows you to determine whether the integrated unblock feature will be available in the logon UI. In order to use the integrated unblock feature, your smart card must support this feature. Ask your hardware manufacturer whether your smart card supports this feature. 1 (Enabled): Integrated unblock feature will be available. 0 (Disabled): Integrated unblock feature will not be available. Not configured: Integrated unblock feature will not be available.
ReverseSubject	Allows you to reverse the subject name from how it is stored in the certificate when displaying it during logon. By default, the user principal name (UPN) is displayed in addition to the common name, to help users distinguish one certificate from another. For example, if the certificate subject is CN=User1, OU=Users, DN=contoso, DN=com, and if it had an UPN of user1@contoso.com, then "User1" will be displayed along with "user1@contoso.com." If the UPN is not present, then the entire subject name will be displayed. This setting controls the appearance of that subject name and might need to be adjusted per organization. 1 (Enabled): Subject name will be reversed. 0 (Disabled): Subject name will be displayed as it appears in the certificate. Not configured: Subject name will be reversed.
X509HintsNeeded	Allows you to determine whether an optional field will be displayed during logon and elevation that allows a user to enter his or her user name or user name and domain, thereby associating a certificate with that user. 1 (Enabled): An optional field will be displayed that allows a user to enter his or her user name or user name and domain. 0 (Disabled): The optional field is not displayed. Not configured: The optional field is not displayed.
IntegratedUnblockPromptString	Allows you to manage a specific string is displayed when a smart card is blocked. 1 (Enabled): Specified string will be displayed to the user when the smart card is blocked. Note You must also ensure that you enable the following setting in Group Policy: Allow Integrated Unblock screen to be displayed at the time of logon. 0 (Disabled): Default string will be displayed to the user when the smart card is blocked, if the integrated unblock feature is enabled. Not configured: Default string will be displayed to the user when the smart card is blocked, if the integrated unblock feature is enabled.
CertPropEnabledString	Allows you to manage the certificate propagation that occurs when a smart card is inserted. 1 (Enabled): Certificate propagation will occur when you insert your smart card. 0 (Disabled): Certificate propagation will not occur, and the certificates will not be made available to applications such as Outlook. Not configured: Certificate propagation will occur when you insert your smart card.
CertPropRootEnabledString	Allows you to manage the root certificate propagation that occurs when a smart card is inserted. 1 (Enabled): Root certificate propagation will occur when you insert your smart card. Note For this policy setting to work, the following policy setting must also be enabled: Turn on certificate propagation from smart card. 0 (Disabled): Root certificates will not be propagated from the smart card. Not configured: Root certificate propagation will occur when you insert your smart card.
RootsCleanupOption	Allows you to configure root certificate clean up. This option is located in HKLM\SOFTWARE\Policies\Microsoft\Windows NT\CurrentVersion\CertProp. Allows you to manage the cleanup behavior of root certificates. If you enable this policy setting, then root certificate cleanup will occur according to the option selected. If you disable or do not configure this setting, then root certificate cleanup will occur on logoff. Root certificate cleanup options include: No cleanup (Default) Cleanup certificates on smart card removal Cleanup certificates on user logoff Note This policy works in conjunction with HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates\Root\ProtectedRoots\Flags. If this is set (off by default), then root certificates will be disabled for propagation, even from smart card.
Require Smart Card (Machine Policy) – Policies for Interactive logon. See figure 9.	Enforces smart card required for logon on a per-computer basis. This key is located in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Policies\System\scforceoption. The following are the supported values: 0: No Action 1: Enable smart card Required for Logon
Smart Card Removal Policy – Policies for Interactive logon. See figure 10.	Note If the smart card removal policy service is not running, start the service using the command: net start ScPolicySvc and set start type to Auto (sc config scpolicysvc start= auto). This key is located in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\scremoveoption. If this is set (off, 0, by default), removal of the smart card will lock the workstation. The following are the supported values: 0: No Action 1: Lock Workstation – user session locked on smart card removal 2: Log Off – User logged off on smart card removal 3: Disconnect from remote Terminal Server Session – removal of the smart card disconnects the session without logging off the user. This allows the user to insert the smart card and resume the session later, or at another smart card reader-equipped terminal, without having to log on again.
FilterDuplicateCertificates	Allows you to configure whether all valid logon certificates are displayed. During the certificate renewal period, a user can have multiple valid logon certificates issued from the same certificate template. This can cause confusion as to which certificate to select for logon. The common case for this behavior is when a certificate is renewed and the old one has not yet expired. Two certificates are determined to be the same if they are issued from the same template with the same major version, and they are for the same user (determined by their UPN). If two or more of the "same" certificate are on a smart card and this policy is enabled, then the certificate that is used for logon on Windows 2000, Windows XP, and Windows 2003 Server will be shown. Otherwise, the certificate with the expiration time furthest in the future will be shown. Note This setting is applied after the following setting: Allow time invalid certificates. 1 (Enabled): Filtering will occur. 0 (Disabled): No filtering will occur. Not configured: Filtering will occur.
ForceReadingAllCertificates	Allows you to force reading of all certificates from the smart card, regardless of the supported feature that is set in the CSP. This policy is applicable whenever the smart card credential provider or the credential UI is called. 1 (Enabled): Windows will try to read all certificates on the smart card, regardless of the feature set in the CSP. 0 (Disabled): Windows will read only the default container of the smart card for logon, unless it supports retrieval of all certificates in a single call. Certificates stored elsewhere than in the default container will not be available for logon. Not configured: Windows will read only the default container of the smart card for logon, unless it supports retrieval of all certificates in a single call. Certificates stored elsewhere than in the default container will not be available for logon.

The following Group Policy setting is located in the registry under HKLM\SYSTEM\CCS\Services\Kdc\Parameters\.

Table 8

Key	Description
SCLogonEKUNotRequired	If you enable this setting, the KDC will not require the smartcard certificate that contains the smartcard authentication EKU. Type: DWORD Default value: 0

Base CSP local policy settings

The local settings for the Base CSP are located in the registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Defaults\Provider\Microsoft Base smart card Crypto Provider.

You can configure the same keys for both the Base CSP and the KSP. Table 9 shows these keys.

Table 9   Local policy settings for Base CSP and smart card KSP

Key	Description
DefaultPrivateKeyLenBits	Type: DWORD Default value: 00000400 Default key generation parameter: 1024 bit keys
RequireOnCardPrivateKeyGen	If this value is set, then a key generated on a host can be imported into the smart card. This is used for smart cards that do not support on-card key generation, or where key escrow is required. Type: DWORD Default value: 00000000. This sets the flag for requiring on-card private key generation (default).
TransactionTimeoutMilliseconds	Type: DWORD Default value: 000005dc1500. 1.5 seconds is the default timeout for holding transactions to the smart card.
AllowPrivateECDHEKeyImport	This value allows import of ECDHE private key for use in key archival scenarios. Type: DWORD Default value: 00000000.
AllowPrivateECDSAKeyImport	This value allows import of ECDSA private key for use in key archival scenarios. Type: DWORD Default value: 00000000

Group Policy guidelines for administrators deploying smart card only logon

Configuring a user account for smart card-only logon

To configure a user account to user smart card-only logon

1. Log on to a Windows Server computer as a domain administrator.

2. Click Start, click Run, type DSA.msc, and then click OK.

3. In the console tree, expand Active Directory Users and Computers, expand the domain that you want to configure, and then click Users.

4. In the details pane, right-click the user you want to enable smart card-only logon for, and then click Properties.

5. In the account properties dialog box, click the Account tab.

6. Under Account options, select the Smart card is required for interactive logon check box, and then click OK.

   Figure 8 shows this configuration.

Figure 8   No delegation and smart card required user account domain setting

Figure 9 shows how the setting in Figure 8 will configure the local policy setting.

Figure 9   Require smart card setting (enforced per computer)

Figure 10 shows how to enable the smart card removal policy.

Figure 10   Smart card removal setting

In smart card-only environments, a useful policy setting would be to disable CTRL+ALT+DEL. Figure 11 shows where you can configure this in Group Policy.

Figure 11   Do not require CTRL+ALT+DEL at logon screen setting

Figure 12 shows how to enable user accounts or computers for delegation. We strongly recommend that you carefully consider any changes you make to delegation for users and computers. Security risks could be very high in some scenarios. However, delegation might be useful when you run Windows Managed Instrumentation (WMI).

Figure 12   User and computer delegation setting

If smart card administrators use the computer, we highly recommend that you disable delegation on the computer. Figure 13 shows this setting in Group Policy.

Figure 13   Do not trust for delegation domain setting

Windows Vista Services

Three services in Windows Vista enable smart card management:

• Smart card resource manager service
• Certificate propagation service
• Smart card removal service

Smart card resource manager service

The smart card resource manager provides the basic infrastructure for all other smart card components. The smart card resource manager manages smart card readers and application interactions on the computer. It is fully PC/SC 1.0 compliant.

The smart card resource manager runs in the context of a local service and is implemented as a shared service of the svchost process. The smart card resource manager service has the following service description:

<serviceData name="SCardSvr"
displayName="@%SystemRoot%\System32\SCardSvr.dll,-1"
errorControl="normal" group="SmartCardGroup" 
imagePath="%SystemRoot%\system32\svchost.exe /k
LocalService" start="demand" tag="" 
type="win32ShareProcess" security=""
description="@%SystemRoot%\System32\SCardSvr.dll,-5
requiredPrivileges="SeCreateGlobalPrivilege,SeChangeNotifyPrivilege,SeImpersonatePrivilege" 
dependOnGroup="" dependOnService="PlugPlay" 
objectName="NT AUTHORITY\LocalService">
     <failureActions resetPeriod="900">
       <actions>
         <action type="restartService" delay="120000"/>
         <action type="restartService" delay="300000"/>
         <action type="none" delay="0"/>
       </actions>
     </failureActions>
     <registryKeys>
       <registryKey keyName="HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SCardSvr\Parameters">
        <registryValue name="ServiceDll" valueType="REG_EXPAND_SZ" value="%SystemRoot%\System32\SCardSvr.dll" buildFilter=""></registryValue>
        <registryValue name="ServiceMain" valueType="REG_SZ" value="CalaisMain" buildFilter=""></registryValue>
        <registryValue name="ServiceDllUnloadOnStop" valueType="REG_DWORD" value="1" buildFilter=""></registryValue>
       </registryKey>
       <securityDescriptor name="ServiceXKeySecurity"/>
     </registryKeys>
     <securityDescriptor name="ServiceXSecurity" buildFilter=""/>
  </serviceData>

By default, the service is configured for manual mode. Smart card reader driver authors must configure the service to start automatically and call a predefined entry point in winscard.dll that will start the service. Using this method ensures that the service is enabled when it is needed but is also disabled for the vast majority of users that do not use smart cards.

When the service is started, it performs several bookkeeping functions. The service first registers itself for service notifications. It also registers itself for Plug and Play (PnP) notifications for device removal and additions. It also initializes its data cache and a global event that signals that the service has started.

We strongly recommend that you send all communications with smart card readers on Windows through the smart card resource manager. It provides a rich interface to track, select, and communicate with all drivers that declare themselves members of the smart card reader device group. The smart card resource manager categorizes each smart card reader slot as a unique reader. Each slot is also managed separately, regardless of the device's physical characteristics. The smart card resource manager handles the following high-level actions:

• Device introduction
• Reader initialization
• Notifying clients of new readers
• Serializing access to readers
• Smart card access
• Tunneling of reader-specific commands

Certificate propagation service

The certificate propagation service applies when a logged-on user inserts a smart card in a reader that is attached to the computer. This action causes the certificate(s) to be read from the smart card. The certificates are then added to the user's personal store. The service action is controlled with Group Policy, as shown in Table 7.

Figure 14 shows the flow of the certificate propagation model. In the diagram, a logged-on user inserts a smart card. The first arrow indicates that the Service Controller notifies CertPropSvc when a user has logged on. On logon notification, CertPropSvc begins to monitor the smart cards that are visible from the user session. The arrow marked R represents the possibility of a remote session and the use of smart card redirection.

Figure 14   Certificate propagation service

1. A logged-on user inserts a smart card.
2. CertPropSvc is notified that a smart card has been inserted.
3. CertPropSvc reads all certificates from all inserted smart cards. The certificates are written to the user’s personal certificate store.

The following lists properties of the certificate propagation service:

• The service uses the property CERT_STORE_ADD_REPLACE_EXISTING_INHERIT_PROPERTIES to add certificates to a user's Personal store.
• If the certificate has the CERT_ENROLLMENT_PROP_ID property (as defined by wincrypt.h), it will not propagate empty requests to the user's Personal store, but it will filter them to be placed in the current user's request store.
• The service will not propagate any machine certificates to a user’s Personal store or vice versa.
• The service propagates certificates according to Group Policy options. These options are detailed in Table 7.
  • CertPropEnabledString: Specifies whether a user's certificate should be propagated.
  • CertPropRootEnabledString: Specifies whether root certificates should be propagated, including options for cleanup.

Root certificate propagation

Root certificate propagation is responsible for specific smart card deployment scenarios, where PKI trust has not yet been established:

• Joining the domain
• Accessing a network remotely

In both cases, the computer is not joined to a domain and, therefore, trust is not being managed by Group Policy. However, the objective is to authenticate to a remote server (the domain controller or the RADIUS server). Root certificate propagation provides the ability to use the smart card to include the missing trust chain.

On smart card insertion, the certificate propagation service will propagate any root certificates on the card to the trusted smart card root computer certificate stores. This process establishes a trust relationship with the enterprise. You may also use a subsequent cleanup action when the user’s smart card is removed from the reader, or when the user logs off. Table 7 shows how this is configurable with Group Policy.

For more information about root certificate requirements, see Smart Card Root Certificate Requirements for User with a Domain Join.

Smart card removal policy service

The smart card removal policy is applicable when a user has logged in with a smart card and subsequently removes that smart card from the reader. The action that is performed when the smart card is removed is controlled with Group Policy, as shown in Table 7.

Figure 15   Smart card removal policy service

1. In Windows Vista, Winlogon is no longer directly involved in monitoring for smart card removal events. The sequence of steps involved in removal policy begins with the smart card credential provider in the logon UI process. When a user successfully logs on with a smart card, the smart card credential provider captures the number of times that the smart card has been inserted or removed from the reader (the activity count), as well as the reader name. This information is then stored in the registry, along with the session identifier where the logon was initiated. The activity count is the upper 16 bits of the dwEventState field of the reader, as seen from SCardGetStatusChange.
2. The smart card resource manager notifies the smart card removal policy service that a logon has occurred.
3. ScPolicySvc retrieves the smart card statistics from the registry that the smart card credential provider had stored. These statistics are used to ensure that the smart card was not removed and might have been reinserted during the handoff between when the smart card credential provider when and ScPolicySvc began monitoring the smart card for removals. This call is redirected if the user is in a remote session. After the user removes the smart card, or if the smart card was removed during the handoff, ScPolicySvc is notified.
4. ScPolicySvc calls Terminal Server to take the appropriate action if the request is to log the user off or to disconnect the user’s session. (This might result in data loss.) If the setting is configured to lock the computer when the smart card is removed, then ScPolicySvc sends a message to Winlogon to lock the computer.

Windows Vista Scenarios

Certificate requirements for smart card logon

Certificate requirements for Windows XP and earlier

The smart card certificate has specific format requirements when it is used with Windows XP and earlier platforms.

Table 10   Pre-Windows Vista certificate requirements

Component	Requirement
CRL Distribution Point (CDP) location	The location must be populated, online, and available. For example: [1]CRL Distribution Point Distribution Point Name: Full Name: URL=http://server1.contoso.com/CertEnroll/caname.crl
Key usage	Digital signature
Basic constraints	[Subject Type=End Entity, Path Length Constraint=None] (Optional)
Enhanced Key Usage	Client Authentication (1.3.6.1.5.5.7.3.2) (The client authentication object identifier is required only if a certificate is used for SSL authentication.) Smart Card Logon (1.3.6.1.4.1.311.20.2.2)
Subject Alternative Name	Other Name: Principal Name= (UPN). For example: UPN = user1@contoso.com The UPN OtherName OID is "1.3.6.1.4.1.311.20.2.3". The UPN OtherName value must be ASN1-encoded UTF8 string
Subject	Distinguished name of user. This field is a mandatory extension, but the population of this field is optional.

There are two predefined types of private keys. These keys are Signature Only (AT_SIGNATURE) and Key Exchange (AT_KEYEXCHANGE). Smartcard logon certificates must have a Key Exchange (AT_KEYEXCHANGE) private key type in order for smartcard logon to function correctly.

Certificate requirements for Windows Vista

Table 11   Windows Vista certificate requirements

Component	Requirement
CRL	Not required
UPN	Not required
Key usage	Digital signature
Enhanced Key Usage	Smart card logon object identifier not required. See Table 7.
Subject Alternative Name	E-mail ID is not required for smart card logon. See Table 7.
Key exchange (AT_KEYEXCHANGE field)	Not required for smart card logon certificates.

You can enable any certificate to be visible for the smart card credential provider. If an EKU is present, then it must contain the smart card logon EKU. Certificates with no EKU can be used for logon.

How does smart card logon work in Windows?

Although Microsoft Windows 2000 and later versions included support for smart cards, the types of certificates that smart cards could contain were limited. The limitations were:

• Each certificate needed to have a User Principal Name (UPN) and needed to contain the smart card logon object identifier (also known as OID) in the EKU attribute field. If the EKU is present, then it must have smart card logon OID present. There is a group policy setting to make EKU optional.

• Each certificate had to be stored in the AT_KEYEXCHANGE portion of the default CAPI container.

  Note

  Non-Default CAPI containers are not supported.

• Certificates are required to have a digital signature key usage value. This requirement continues for Windows Vista.

To improve support for smart card deployments, changes to Windows were made to enable support for a range of certificates that do not have the previous limitations.

Smart card-based logon in Windows Vista

Smart card logon on Windows Vista has changed in several key aspects. The primary differences are highlighted below:

• Logon is no longer triggered on smart card insertion. Users are normally required to press CTRL+ALT+DEL to start the logon process.
• Valid certificates are enumerated and displayed from all smart cards and presented to the user. The smart card must be inserted before the user can enter the PIN.
• Keys are no longer restricted to being in the default container, and certificates in different smart cards can be chosen.
• The CSP is accessed (as discussed in Smart Card Logon Flow in Windows Vista) in lsass.exe. The CSP is never loaded into the Winlogon process.
• Multiple Terminal Services sessions are supported in a single process. Because Windows Vista is integrated with Terminal Services to provide Fast User Switching, you should not overlook this fact.
• ECC-based certificates are not supported for smart card logon in Windows. ECC-based PKINIT is still being standardized as a part of IETF (http://www.ietf.org/html.charters/krb-wg-charter.html).

Certificate enumeration

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

1. The smart card resource manager database queries for the smart card's CSP.
2. A qualified container name is constructed using the reader name obtained and is passed to the CSP. The format for that name is as follows: \\.\<Reader name>\
3. CryptAcquireContext is called to retrieve a context to the default container. A failure here would cause the smart card to be unusable for smart card logon.
4. The name of the container is retrieved by requesting the PP_CONTAINER parameter 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. (See Smart card subsystem architecture for more information.) 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, then the default container context from Step 3 is queried for the AT_KEYEXCHANGE key.
7. The certificate is then queried from the key context 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 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 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 torn down. This causes the context acquired in Step 3 to be released.

Smart card logon flow in Windows Vista

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

enables support of client certificates that do not contain a UPN in the subjectAltName (SAN) field of the certificate and supports a much wider variety of certificates, including multiple certificates.

However, these changes are not enabled by default, except for multiple certificates support. (Some certificates are excluded.) Administrators need to set the registry keys on clients (for example, with Group Policy) to enable the functionality.

clients by default would filter the client's certificates in the smart card by using the client authentication EKU. The credential provider also has a policy, AllowSignatureOnlyKeys (corresponding to the AT_SIGNATURE key value in CAPI), to determine if it needs to filter the client certificates based on a requirement that the logon certificate be able to do encryption by allowing the user to display and select signing-only certificates. These policy settings have a direct bearing on the filtering and resulting display of certificates on the logon UI.

Figure 16 illustrates how smart card logon works in Windows Vista.

Figure 16   Smart card logon flow

Flow sequence:

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 none, or that Windows detected a smart card reader.
   2. Gets a list of smart card readers (uses WinSCard API) and the list of smart cards inserted in each of them.
   3. Enumerates each card to check if 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 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 for which a corresponding logon tile is 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 clicks Go. 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 (defined in CredentialProviders.h). The main contents of the KERB_CERTIFICATE_LOGON structure are smart card PIN, cspdata (contains reader name, container name, etc), 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 Spec) and is sent back to LogonUI.

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

8. LSA calls 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 using a certificate with a key usage of digital signature, then the pre-authentication data consists of the user’s public certificate, and the certificate is digitally signed with the corresponding private key.
   If the authentication is with a certificate with a key usage of key encipherment, then the pre-authentication data consists of the user’s public certificate, and the certificate is 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 sub-system 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 (as per RFC 4556) to the Key Distribution Center (KDC) service that runs on a domain controller, to request a Ticket Granting Ticket (TGT).

11. The KDC finds the user’s account object in the active directory, 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 (CAPI2) to build a certification path from the user’s certificate to a Root CA certificate that resides in the root store on the domain controller. The KDC then uses CryptoAPI (CAPI2) to verify the digital signature on the authenticator that was included as signed data 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 Active Directory. The KDC constructs a TGT based on the user account information that it retrieves from Active Directory. 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 multi-domain 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.

    Note

    The KRB_AS_REP packet consists of:

    Privilege attribute certificate (PAC)

    User’s security identifier (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 CAPI2 APIs, the temporary key is decrypted. As part of the decryption process, if the private key for the same happens to be on a smart card, then the call is made back to the smart card subsystem using the specified Cryptographic Service Provider to extract the certificate corresponding to the user’s public key. (Programmatic calls include CryptAcquireContext, CryptSetProvParam with the PIN, CryptgetUserKey, 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 in order to log on to the computer.

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

18. Once the user profile is loaded, CertPropSvc picks up 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 LRPC Channel.

20. On successful authentication, certificates will be 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 will remain 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 smartcard client authentication EKU szOID_KP_SMARTCARD_LOGON. However, there is a policy that allows the KDC not to require the SC-LOGON EKU (SCLogonEKUNotRequired – See Table 7). 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)

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 on 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 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>. Here the <Issuer Name> and <Subject Name> are taken from the client certificate, with '\r' and '\n' replaced with ','.

Figure 17   CRL distribution points

Figure 18   UPN in Subject Alternative Name field

Figure 19   Subject and Issue fields

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

Figure 20   High-level flow of certificate processing for logon

The certificate object is parsed to look for certain contents to perform user account mapping. When a user name is also provided with the certificate, then 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, then a series of operations are performed to locate the user to map the user 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 wins, and the search stops. 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 it is a configuration error.

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

Figure 21 illustrates the process of mapping user accounts for logon in the directory by looking at various entries in the certificate. NT_AUTH policy is best described in CertVerifyCertificateChainPolicy (https://go.microsoft.com/fwlink/?LinkId=93738) under CERT_CHAIN_POLICY_NT_AUTH.

Figure 21   Certificate processing logic

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 his 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. See Client Certificate Mappings on how this mapping is evaluated.

The following lists the conditions for logon, based on the certificate contents:

1. If no UPN is present in the certificate:
   1. Logon can happen in the local forest or in another forest if a single user with one certificate needs to logon to different accounts.
   2. A hint must be supplied if mapping is not unique (more than one user 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. In order to logon user in 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

In order for account mapping to work across forests, especially in cases where not enough information is 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@DNSNameOfDomain.com).

OCSP support for PKINIT

Online Certificate Status Protocol (OCSP), defined in RFC 2560, enables applications to obtain timely information about a certificate's revocation status. 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, in order to avoid transmission of large certificate revocation lists (CRLs) and save bandwidth on constrained networks.

Microsoft’s KDC will always try to get the OCSP responses and use them when available. There is no policy that can be used to turn that off. CAPI2 APIs for OCSP caches OCSP responses and the status of the responses. KDC only supports OCSP response for signer certificate.

Windows clients will always try to request the OCSP responses and use them in the reply, when they are available. There is no policy that can be used to turn that off.

Certificate revocation support

Table 12 itemizes the keys and the corresponding values to turn off CRL checking (on the wire) at the KDC or client. Both settings are required.

Table 12   CRL checking registry keys

Key	Description
HKLM\SYSTEM\CCS\Services\Kdc\UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors	Type = DWORD Value = 1
HKLM\SYSTEM\CCS\Control\LSA\Kerberos\Parameters\UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors	Type = DWORD Value = 1

Smart card root certificate requirements for use with domain join

There are some specific conditions that the smart card certificate must meet in order for smart card-based domain join to work.

• Smart card certificate must contain a Subject field that contains the DNS domain name in the DN. If it does not, then resolution to appropriate domain will fail, and TS and domain join with smartcard will fail.

OR

• Smart card certificate must contain a UPN where the domain part of the UPN must resolve to the actual domain. For example, UPN "username@engineering.corp.contoso.com" would work, but "username@engineering.contoso.com" would not work, because the Kerberos client would not be able to find the appropriate domain.

The workaround is to supply a hint (enabled via GPO setting X509HintsNeeded as specified in Table 7) in the credentials user interface for domain join.

If the client computer is not joined to the domain (or if it is joined to a different domain), then the client will be able to resolve the server domain only by looking at the DN on the certificate (not the UPN). For this scenario to work, the certificate needs a full Subject (including “DC=…”) for domain name resolution.

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

certutil –scroots

Terminal Services and Smart Cards

In Vista, smart card redirection logic and WinSCard have been combined to support multiple redirected sessions into a single process.

Smart card support with Terminal Services is required to enable many scenarios. These include:

• Ability to RAS in a Fast User Switching (or remote by using terminal services) environment. A user is not able to establish a redirected smartcard-based RAS connection. That is, the connect attempt will not be successful in fast user switching or from a Terminal Services session.
• EFS will not be able to locate the user’s smart card reader from the LSA process in Fast User Switching or in a Terminal Services session. As a result, EFS will be unable to decrypt user files.

Terminal server redirection

In a Terminal Server scenario, a user is using a remote server for running services. But the smart card is local to the system the user is using. In a smart card logon scenario, the remote server’s smart card service (SCardSvr.exe or SVCHost.exe) will appropriately talk (or redirect) to the smart card reader connected to the remote system from which the user is trying to log on.

Figure 22   Terminal server redirection

Notes about the redirection model:

1. The scenario being described is a remote logon session on a Terminal Server computer. In the remote session (labeled as “Client Session”), the user runs net use /smart card.
2. The arrows represent the flow of the PIN that the user types from the command prompt process, cmd.exe, to the user’s smart card in a reader plugged into the Terminal Services client computer.
3. The authentication work is performed by the LSA in session 0.
4. The Crypto API work is performed in the LSA (lsass.exe). This is possible because rdpdr.sys will allow per-session, rather than per-process, context.
5. The WinScard and SCRedir components, which were tightly coupled yet separate modules before Vista, are now rolled into one module. The ScHelper library is a Crypto API wrapper that is specific to Kerberos.
6. Redirection decision is made on a per smart card context basis, based on the session of the thread doing the SCardEstablishContext call.
7. Changes to WinSCard.dll implementation have been made in Vista to allow for smart card redirection.

Terminal server single sign-on experience

As a part of Common Criteria (CC) compliance, the MSTSC client must be configurable to use Credentials Manager to acquire and save the user’s password or smart card PIN. CC requires that applications not have direct access to the user’s password or PIN.

CC requires specifically that the password/PIN never leave the LSA in the clear. Applied to a distributed scenario, it should allow the password/PIN to travel between one trusted LSA and another, as long as it is not in the clear during transit.

In the Windows Vista Terminal Services SSO solution, when using a smart card users will need to sign in for every new Terminal Services session (no SSO support). However, the user is not prompted for a PIN more than once in order to establish a Terminal Services session. For example, after the user double clicks on a Microsoft Word document icon that resides on a remote computer, the user will be prompted to enter a PIN. This PIN will be passed using a secure channel that the credential SSP has established. The PIN is routed back to the Terminal Services client over the secure channel and passed to Winlogon, and the user does not see any additional UI (no additional prompts for the PIN, unless the PIN is incorrect or there are smart card-related failures).

Terminal services and smart card logon

The purpose of this feature is to enable users to log on with a smart card by entering a PIN on the terminal services client side and passing it to the server in a manner similar to authentication based on user name and password.

Smart card logon with terminal services was first introduced in Windows XP. It is not available in any earlier releases. In Windows XP, the user could log on using only one certificate from the default container.

In addition to enabling the necessary group policies, policies specific to terminal services need to be enabled for smart card-based logon.

To enable smart card logon to a terminal services server, the KDC certificate must be present on the terminal services client local computer. If the computer is not in the same domain or workgroup, then the following command line tool can be used to deploy the certificate.

Format:

certutil –dspublish NTAuthCA "DSCDPContainer"

The DSCDPContainer CN is usually the CA computer name.

Example:

certutil –dspublish NTAuthCA <CertFile> “CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=engineering,DC=contoso,DC=com”

Terminal Services and smart card logon across domains

Scenario: RAS into enterprise

To enable this scenario, the root certificate for the domain must be provisioned on the smart card. To provision this on the smart card from a domain-joined computer, run the following at the command line:

certutil –scroots update

For terminal services across domains, KDC certificate of the terminal services server computer must also be present in the client computer's NTAUTH store. To add the store, run the following at the command line:

certutil –addstore –enterprise NTAUTH <CertFile>

Where <CertFile> is the root certificate of the KDC certificate issuer.

Cross domain terminal services logon will work only if the UPN in the certificate uses the following form: <Something>@<DomainDNSName>

UPN in the certificate must include a real domain which can resolve. Otherwise, Kerberos has no idea where to go. Enabling, GPO X509 domain hints is a way around this. For more information about this setting, see Table 7.

Terminal services and smart card logon Group Policy settings

Windows enforces the settings for smart card logon with terminal services after it enforces the credential SSP and local security policy (set with secpol.msc).

Table 13   Terminal services and smart card logon Group Policy settings

Policy	Setting
Smart card logon is the only supported logon method	HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\CredentialsDelegation Value name: AllowFreshCredentials Value type: Binary Value setting: 1
User also has a corresponding password-enabled account	HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\CredentialsDelegation Value name: AllowFreshCredentialsWhenNTLMOnly Value type: Binary Value setting: 1

If you are using terminal services with smart card logon, you cannot delegate default and saved credentials. The following corresponding Group Policy settings are ignored under HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\CredentialsDelegation:

• AllowDefCredentials
• AllowDefCredentialsWhenNTLMOnly
• AllowSavedCredentials
• AllowSavedCredentialsWhenNTLMOnly

Fast User Switching

This is for the active session only.

Debugging and Developer Information

Developers can use tools and services in Windows Vista, to help identify certificate problems.

CertUtil

Listing certificates available on the smart card

Command to list certificates that are available on the smart card: certutil –scinfo

Entering a PIN is not required for this operation. Hitting Escape at each PIN dialog will work, because the objective is to read the public certificates on the card.

Deleting certificates on the smart card

When you delete a certificate on the card, you are actually deleting a container that corresponds to that certificate. Each certificate is enclosed in a container. For example, to delete a container, you can use the following command:

Certutil –delkey –csp “Microsoft Base Smart Card Crypto Provider” “38f813f2-ec3b-4e96-ba19-38b830923be9”

To deploy a domain root certificate on a smart card, see Smart Card Root Certificate Requirements for User with a Domain Join.

To publish certificates to the NTAUTH store, see Terminal Services and Smart Card Logon.

Kerberos debugging and tracing

You can use the following resources to begin troubleshooting Kerberos:

• Troubleshooting Kerberos Errors (https://go.microsoft.com/fwlink/?LinkId=93730).
• Troubleshooting Kerberos Delegation (https://go.microsoft.com/fwlink/?LinkId=93731).
• The Trace Log tool in the Windows 2000 Resource Kit (https://go.microsoft.com/fwlink/?LinkId=93732) is a utility that you can use to debug Kerberos authentication failures.

To begin tracing, you can use tracelog.exe. Different components use different control GUIDs.

NTLM

To enable tracing for NTLM authentication, run the following at the command line:

tracelog.exe -kd -rt -start ntlm -guid #5BBB6C18-AA45-49b1-A15F-085F7ED0AA90 -f .\ntlm.etl -flags 0x15003 -ft 1

To stop tracing for NTLM authentication, run the following at the command line:

tracelog -stop ntlm

Kerberos

To enable tracing for Kerberos authentication, run the following at the command line:

tracelog.exe -kd -rt -start kerb -guid #6B510852-3583-4e2d-AFFE-A67F9F223438 -f .\kerb.etl -flags 0x43 -ft 1

To stop tracing for Kerberos authentication, run the following at the command line:

tracelog.exe -stop kerb

KDC

To enable tracing for the KDC, run the following at the command line:

tracelog.exe -kd -rt -start kdc -guid #1BBA8B19-7F31-43c0-9643-6E911F79A06B -f .\kdc.etl -flags 0x803 -ft 1

To stop tracing for the KDC, run the following at the command line:

tracelog.exe -stop kdc

Configure tracing with the registry

You can also configure tracing by editing registry values.

Table 14   Kerberos tracing registry settings

Method	Registry key setting
NTLM	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 Value name: NtLmInfoLevel Value type: DWORD Value data: c0015003
Kerberos	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters Value name: KerbDebugLevel Value type: DWORD Value data: c0000043 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos Value name: LogToFile Value type: DWORD Value data: 00000001 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters Value name: LogToFile Value type: DWORD Value data: 00000001
KDC	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc Value name: KdcDebugLevel Value type: DWORD Value data: c0000803

If you used tracelog.exe, look for the log file kerb.etl/kdc.etl/ntlm.etl in your current directory. Otherwise, if you used the registry files shown in Table 13, look for the generated trace log files at the following locations:

• NTLM: %systemroot%\tracing\msv1_0
• Kerberos: %systemroot%\tracing\kerberos 
• KDC: %systemroot%\tracing\kdcsvc 

To decode event trace files, you can use Tracefmt (tracefmt.exe). Tracefmt is a command-line tool that formats and displays trace messages from an event trace log file (.etl) or a real-time trace session. Tracefmt can display the messages in the Command Prompt window or save them in a text file. It is located in the \tools\tracing subdirectory of the Microsoft Windows Driver Kit (WDK). For more information about Tracefmt, see Tracefmt at MSDN (https://go.microsoft.com/fwlink/?LinkId=93734).

Smart card service

To check if the smart card service is running

1. Press CTRL+ALT+DEL, and then click Start Task Manager.

2. In the Windows Task Manager dialog box, click the Services tab.

3. Click the Name column to sort the list alphabetically, and then type s.

4. In the Name column, look for SCardSvr, and then look under the Status column to see if the service is running or stopped.

To restart the smart card service

1. Click the Start button, type cmd, right-click cmd.exe, and then click Run as administrator.

2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.

3. At the command prompt, type net stop SCardSvr

4. At the command prompt, type net start SCardSvr

You can use the following command at the command prompt to check whether the service is running:

sc queryex scardsvr

The following is example output from running this command:

SERVICE_NAME: scardsvr
    TYPE        : 20 WIN32_SHARE_PROCESS
    STATE       : 4 RUNNING
                (STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN)
    WIN32_EXIT_CODE  : 0 (0x0)
    SERVICE_EXIT_CODE : 0 (0x0)
    CHECKPOINT     : 0x0
    WAIT_HINT     : 0x0
    PID        : 1320
    FLAGS       :
C:\>

Smart card readers

To check whether the smart card reader is connected and working properly

1. Click the Start button, right-click Computer, and then click Properties.

2. Under Tasks, click Device Manager.

3. In Device Manager, expand Smart card readers, select the smart card reader about which you want information, and then click Properties.

   Note

   If the smart card reader is not listed in Device Manager, in the Action menu, click Scan for hardware changes.

CAPI2 Diagnostics

CAPI2 Diagnostics is a feature in Windows Vista and Windows Server 2008 that helps administrators in troubleshooting PKI problems. CAPI2 Diagnostics logs events in the Windows event log that contains detailed information about certificate chain validation, certificate store operations, and signature verification. This information makes it easier to identify the root causes of problems and reduces the time required for diagnosis.

For more information on CAPI2 Diagnostics, see Troubleshooting PKI Problems on Windows Vista (https://go.microsoft.com/fwlink/?LinkId=89570).

References

1. Credential Provider Questions alias – credprov@microsoft.com
2. Credential Provider Technical Reference (https://go.microsoft.com/fwlink/?LinkId=93340)
3. Windows Vista SDK Documentation (https://go.microsoft.com/fwlink/?LinkId=93342)
4. Microsoft Base Smart Card Cryptographic Service Provider (Base CSP) for Windows 2000, 2003 and XP (https://go.microsoft.com/fwlink/?LinkId=93341)
5. Smart Card Mini Driver Specification (https://go.microsoft.com/fwlink/?LinkId=93343)  
6. Smart Card Mini Driver (Card Module) API and Header file Documentation on MSDN (https://go.microsoft.com/fwlink/?LinkId=18885); Feedback Alias: CardMod@microsoft.com ; Header file download available as a part of CNG SDK (https://go.microsoft.com/fwlink/?LinkId=93344)
7. Smart Card Certification Requirements (https://go.microsoft.com/fwlink/?LinkId=93345)
8. PC/SC Workgroup (https://go.microsoft.com/fwlink/?LinkId=93346)
9. WinSCard API Reference (https://go.microsoft.com/fwlink/?LinkId=93347)
10. OSCP support for PKINIT (https://go.microsoft.com/fwlink/?LinkId=93348)
11. Enterprise Smart Card Deployment in the Microsoft Windows Smart Card Framework (https://go.microsoft.com/fwlink/?LinkId=93349)
12. Session 0 in Windows Vista (https://go.microsoft.com/fwlink/?LinkId=93350)
13. Global Platform Specifications (https://go.microsoft.com/fwlink/?LinkId=93351)
14. Troubleshooting PKI Problems on Windows Vista (https://go.microsoft.com/fwlink/?LinkId=89570)
15. RFC 4556: Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) (https://go.microsoft.com/fwlink/?LinkId=93352)
16. Active Directory Certificate Server Enhancements in Windows Server 2008 (https://go.microsoft.com/fwlink/?LinkId=83212)
17. Smart Card Infrastructure Blog, for latest information and feedback (https://go.microsoft.com/fwlink/?LinkId=96591)