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

Table 2   Windows Vista interactive logon components

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.

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.

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.

Container specification levels

Container operations

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

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

Making a smart card match

Open existing default container - no reader specified

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

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

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

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

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.

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

Data caching

PIN caching

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

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.

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

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 9 shows how the setting in Figure 8 will configure the local policy setting.

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

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

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.

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.

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

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.

Table 11   Windows Vista certificate requirements

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.

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.

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

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.

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 (http://go.microsoft.com/fwlink/?LinkId=83212).

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

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.

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 (http://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 (http://go.microsoft.com/fwlink/?LinkId=93738) under CERT_CHAIN_POLICY_NT_AUTH.

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.

Note
Because each account has a different user name, we recommend that you enable the X509Hints Group Policy Object to provide the user information for whom he/she will want to login as.

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.
      

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.

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

Note
For the hint field to appear during smartcard logon, the X509HintsNeeded registry key must be set on the client to enable display of an additional hints field to the logon UI with the PIN field (see Table 7).

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.

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

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

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.

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.
   

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.

Note
If a Windows Vista terminal services client is used and a Windows 2003 Server is used, then only a single certificate on a smart card in the default container is supported. To avail Windows Vista support for multiple certificates and domain hints features, use only Windows Vista and Windows Server 2008 computers.

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”

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.

Note
If you use the credential SSP on Windows Vista to log on with a smart card from a non-domain-joined computer, the smart card must contain the root certification of the domain controller. A PKI secure channel cannot be established without the root certification of the domain controller.

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.

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

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
  

Listing certificates available on the smart card

Deleting certificates on the smart card

You can use the following resources to begin troubleshooting Kerberos:

• Troubleshooting Kerberos Errors (http://go.microsoft.com/fwlink/?LinkId=93730).
  
• Troubleshooting Kerberos Delegation (http://go.microsoft.com/fwlink/?LinkId=93731).
  
• The Trace Log tool in the Windows 2000 Resource Kit (http://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

Kerberos

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

Note
To stop tracing remotely, run the following at the command line: logman.exe -s <ComputerName> The default location for logman.exe is %systemroot%system32\. Use the -s option to supply a computer name.

Configure tracing with the registry

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.

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:\>

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 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 (http://go.microsoft.com/fwlink/?LinkId=89570).