Windows Vista Smart Card Infrastructure

Windows Vista Smart Card Infrastruc...

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.

Note
The smart card service (SCardSvr.exe) and WinSCard API were available as optional components for Windows 95, Windows 98, and Windows ME.

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.

Note
For more information about GINA-based interactive logon architecture, see How Interactive Logon Works (http://go.microsoft.com/fwlink/?LinkId=93339).

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 (http://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 (http://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:

Create new container (CRYPT_NEWKEYSET)
Open existing container
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.

Important
The CRYPT_SILENT flag cannot be used with container operation A (create new container).

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:

Call CryptAcquireContext passing the smart card reader name in as type II, specifying the CRYPT_DEFAULT_CONTAINER_OPTIONAL flag.
Call CryptSetProvParam by specifying PP_KEYEXCHANGE_PIN or PP_SIGNATURE_PIN and a null-terminated ASCII PIN.
Release the context acquired in Step 1.
Call CryptAcquireContext with CRYPT_NEWKEYSET specifying the type I format.
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.

Find the requested reader. If it cannot be found, the process fails. (This requires a cache search by reader name.)
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).
For level II only, the name of the default container on the chosen smart card is determined.
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.
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

Note
This scenario requires that you use the smart card KSP with the Base CSP.

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.
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

Note
This scenario requires that you use the smart card KSP with the Base CSP.

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).
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

Note
This scenario requires that you use the smart card KSP with the Base CSP.

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.

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.
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

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.
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*.
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.

The application requests a CAPI operation. For example, a user certificate is to be read from the card.
The CSP first checks its cache for the item.
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.
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.

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.
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.

The user starts Outlook and tries to send a signed e-mail. The private key is on the smart card.
Outlook prompts the user for the smart card PIN. The user enters the correct PIN.
E-mail data is sent to the smart card for the signature operation. The Outlook client formats the response and sends the e-mail.
The user opens Internet Explorer and tries to access a protected site that requires TLS client authentication.
Internet Explorer prompts the user for the smart card PIN. The user enters the correct PIN.
The TLS-related private key operation occurs on the smart card, and the user is authenticated and logged in.
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.

Note
The API definitions are located in WinCrypt.h and WinSCard.h.

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 (http://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

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

Note
During deployment, additional policies might be required for ease of use or for better security. Some of these policies include: Turning off delegation for computers. Interactive logon: Do not require CTRL+ALT+DEL (not recommended).

Note

During deployment, additional policies might be required for ease of use or for better security. Some of these policies include:

Turning off delegation for computers.

Interactive logon: Do not require CTRL+ALT+DEL (not recommended).

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.

Note
The smart card KSP local settings are located under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Providers\Microsoft smart card Key Storage 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

Log on to a Windows Server computer as a domain administrator.
Click Start, click Run, type DSA.msc, and then click OK.
In the console tree, expand Active Directory Users and Computers, expand the domain that you want to configure, and then click Users.
In the details pane, right-click the user you want to enable smart card-only logon for, and then click Properties.
In the account properties dialog box, click the Account tab.
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>

Note
The inf file should specify the following for the Class and ClassGUID in order for winscard.dll to be invoked as the proper class installer: Class=SmartCardReader ClassGuid={50DD5230-BA8A-11D1-BF5D-0000F805F530}

Note

The inf file should specify the following for the Class and ClassGUID in order for winscard.dll to be invoked as the proper class installer:

Class=SmartCardReader

ClassGuid={50DD5230-BA8A-11D1-BF5D-0000F805F530}

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

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

Note
The certificate propagation service is started as a dependency on the Terminal Services service.

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

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.
The smart card resource manager notifies the smart card removal policy service that a logon has occurred.
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.
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.

Note
Non-Default CAPI containers are not supported.

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:

Note
Unless otherwise mentioned, all operations are performed silently (CRYPT_SILENT is passed to CryptAcquireContext).

The smart card resource manager database queries for the smart card's CSP.
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>\
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.
The name of the container is retrieved by requesting the PP_CONTAINER parameter using CryptGetProvParam.
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.
If the operation in Step 5 fails, then the default container context from Step 3 is queried for the AT_KEYEXCHANGE key.
The certificate is then queried from the key context using KP_CERTIFICATE. The certificate is added to an in-memory certificate store.
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).
A certificate is then chosen, and the PIN is entered.
LogonUI.exe packages the information and sends it to lsass.exe to process the logon attempt.
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:

WinLogon requests the logon UI credential information.
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.
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.
The user enters the PIN and clicks Go. The smart card credential provider encrypts the PIN.
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.
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.
LogonUI presents the data to LSA with Winlogon for LSALogonUser.
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) (http://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.
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.
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).
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.
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.
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.

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

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.

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.
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.
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.
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).
CSP to smart card resource manager communication happens on LRPC Channel.
On successful authentication, certificates will be propagated to the user’s store (MYSTORE) asynchronously by the Certificate Propagation Service (CertPropSvc).
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).

Note
A SID is a security identifier that is created for each user or group, at the time a user account or a group account is created within either the local security accounts database on Windows NT or higher computers, or within Active Directory. The SID never changes, even if the user or group account is renamed.

For more information about Kerberos, see How the Kerberos Version 5 Authentication Protocol Works (http://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.

Product Families

Resources

About Microsoft

Popular Places

Popular Searches

Popular Downloads

Audience

Windows Smart Card Infrastructure

Windows Vista enhancements

Architecture

Windows interactive logon architecture

Table 1 Pre-Windows Vista interactive logon components

Windows Vista credential provider architecture

Table 2 Windows Vista interactive logon components

Smart card subsystem architecture

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

Smart card selection heuristics

Container specification levels

Table 3 Container specification levels

Container operations

Table 4 Container creation operation restrictions

Context flags

Table 5 Restriction flags

Creating a new container in silent context

Smart card selection behavior

Making a reader match

Making a smart card match

Open existing default container - no reader specified

Open existing GUID-named container, no reader specified

Create new container, no reader specified

Delete a container

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

Data caching

PIN caching

Base CSP and KSP-based architecture in Windows Vista

Base CSP and smart card KSP properties in Windows Vista

Table 6 Base CSP and smart card KSP properties

Implications of CSPs in Windows Vista

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

Windows Vista Group Policy Settings

Table 7 Group Policy settings

Table 8

Base CSP local policy settings

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

Group Policy guidelines for administrators deploying smart card only logon

Configuring a user account for smart card-only logon

Windows Vista Services

Smart card resource manager service

Certificate propagation service

Root certificate propagation

Smart card removal policy service

Windows Vista Scenarios

Certificate requirements for smart card logon

Certificate requirements for Windows XP and earlier

Table 10 Pre-Windows Vista certificate requirements

Certificate requirements for Windows Vista

Table 11 Windows Vista certificate requirements

How does smart card logon work in Windows?

Smart card-based logon in Windows Vista

Certificate enumeration

Smart card logon flow in Windows Vista

KDC certificate