Smart Card Authentication Changes
Overview
Although Windows Server 2003 includes support for smart cards, the types of certificates that smart cards can contain are limited by strict requirements. Each certificate needs to be associated with a user principal name (UPN) and needs to contain the smart card logon object identifier (also known as OID) in the Enhanced Key Usage field. In addition, each certificate requires that signing be used in conjunction with encryption.
To better support smart card deployments, Windows Vista enables support for a range of certificates. Customers now have the ability to deploy smart cards with certificates that are not limited by the previous requirements. Specific certificate requirements that were changed are itemized in the following list:
- UPN is no longer required.
- For smart card logon, the Enhanced Key Usage (no need for smart card logon object identifier) and Subject Alternative Name (need not contain e-mail ID) fields are not required. If an enhanced key usage is present, it must contain the Smart Card Logon enhanced key usage.
- You can enable any certificate to be visible for the smart card credential provider.
- Smart card logon certificates do not require a Key Exchange (AT_KEYEXCHANGE) field.
- Certificate Revocation List (CRL) is no longer a required field.
Because the restrictions found in previous versions of Windows are still considered best practices for certificate deployment, the listed changes are not enabled by default except for multiple certificates support (some certificates are excluded). Administrators need to configure the registry keys on client computers to enable the functionality. Group Policy can be used to accomplish this configuration.
In addition to these changes to the smart card requirements, the following functional changes have been made for smart card logon:
- When a smart card is inserted into a smart card reader, the logon process does not start automatically. Typically, users are now required to press CTRL+ALT+DELETE to start the logon process.
- All valid smart card logon certificates are enumerated and presented to users. The smart card must be inserted before users can enter a personal identification number (PIN).
- Keys are no longer restricted to being in the default container, and certificates in different smart cards can be chosen.
- Multiple Terminal Services sessions are supported in a single process. Because Windows Vista is closely integrated with Terminal Services to provide fast user switching, this functionality is an important improvement.
Additional changes to common smart card logon scenarios
The following section describes the changes in Windows Vista for common smart card authentication and logon scenarios.
Smart card logon of a single user with one certificate into multiple accounts
In Windows Vista, a single user certificate can be mapped to multiple accounts. For example, a user can log on to his or her user account or can log on as domain administrator.
Smart card logon of multiple users into a single account
Windows Vista supports the ability for multiple users with unique smart card certificates to log on to a single account, such as an administrator's account.
Smart card logon across forests
In some situations, such as logon across forests, there might not be enough information in the smart card certificate to reliably route the logon request. Windows Vista allows users to enter a "hint" in the form domain\user username or a fully qualified UPN such as user@DNSnameofdomain.com that allows reliable authentication routing.
For the Hint field to appear during smart card logon, the X509HintsNeeded registry key must be set on the client computer.
OCSP support for PKINIT
The Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) protocol is the smart card authentication mechanism for the Kerberos authentication protocol. Online Certificate Status Protocol (OCSP), defined in RFC 2560, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP," (https://go.microsoft.com/fwlink/?LinkID=67082), enables applications to obtain timely information regarding the revocation status of a certificate.
Because the Windows KDC is a high-volume transactional service, it benefits greatly by using OCSP instead of relying on CRLs. Windows Server 2008 KDCs will always attempt to use OCSP to verify certificate validity.
Certificate revocation support
The following table describes the registry key values you can use to disable CRL checking.
Note
The settings must be enabled on both the client and KDC computers to disable CRL checking.
Registry key values to disable CRL checking
| Key | Value |
|---|---|
HKLM\SYSTEM\CCS\Services\Kdc\UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors |
Type=DWORD Value=1 |
HKLM\SYSTEM\CCS\Control\LSA\Kerberos\Parameters\UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors |
Type=DWORD Value=1 |
Smart card root certificate requirements for use when joining a domain
When using a smart card to join a domain, the smart card certificate must comply with one of the following conditions:
- The smart card certificate must contain a Subject field that contains the DNS domain name within the distinguished name. If it does not contain this field, resolution to the appropriate domain will fail, causing the domain join with smart card to fail.
- The smart card certificate must contain a UPN in which the domain part of the UPN must resolve to the actual domain. For example, the UPN "username@engineering.corp.example.com" would work, but "username@engineering.example.com" would not work because the Kerberos client would not be able to find the appropriate domain.
The solution for both of the listed conditions is to supply a hint (enabled via the X509HintsNeeded registry setting) in the credentials prompt when joining a domain.
If the client computer is not joined to a domain, then the client will only be able to resolve the server domain by viewing the distinguished name on the certificate (as opposed to the UPN). For this scenario to work, the Subject field for the certificate must include "DC=" for domain name resolution.
To deploy root certificates on smart cards for the currently joined domain, the following command can be used:
certutil –scroots
Terminal server redirection
In terminal server scenarios, remote servers are used to run services. However, the smart card is local to the computers from which the connections are established. In smart card logon scenarios, the Smart Card service on the remote servers will appropriately redirect to the smart card readers that are connected to the remote computers from which users are trying to log on.
Terminal server sign on experience
As a part of Common Criteria compliance requirements, the Terminal Services client must be able to be configured to use Stored User Names and Passwords to acquire and save users' passwords and smart card PINs. Common Criteria requires that applications must not have direct access to users' passwords or PINs.
Specifically, the Common Criteria requirement is that passwords and PINs never leave the highly trusted Local Security Authority (LSA) unencrypted. When this requirement is applied to a distributed scenario, it should allow passwords and PINs to travel between one trusted LSA and another if they are encrypted during transit.
In Windows Vista, smart card users will need to log on for every new Terminal Services session. However, users are not prompted for their PINs more than once to establish a Terminal Services session. For example, after a user double-clicks a Microsoft Word document icon that resides on a remote computer, the user will be prompted to enter his or her PIN. This PIN will be passed via a secure channel established by CredSSP. The PIN is routed to the Terminal Services client over the secure channel, where it is used to access the keys on the smart card.
Users are not prompted again for their PINs unless a PIN is incorrect or if a smart card fails due to problems with the card or reader.
Terminal Services and smart card logon
This feature enables users to log on with smart cards by entering a PIN on the Terminal Services client, which securely relays this information to the server in a manner similar to authentication that uses a user name and password.
Smart card logon with Terminal Server was first introduced in Windows XP. It is not available in any earlier versions of the Windows operating system. In Windows XP, users can use only one certificate from the default container to log on.
Note
This feature requires terminal servers running Windows Server 2008. If Windows Vista–based client computers are used to log on to terminal servers running Windows Server 2003, the user experience and capabilities are equivalent to using Terminal Server with Windows XP–based client computers.
To enable smart card logon to a terminal server, the KDC certificate must be present on the local Terminal Services client computer.
Terminal Services and smart card logon across domains
With Windows Vista, it is now possible to use smart cards to log on across domains or from computers that were not joined to domains trusted by the users' account domains. Common scenarios where this functionality is required include:
- Using Routing and Remote Access to access an organization's network resources across the Internet.
- Using Terminal Services across domains that are not trusted or computers that are not joined to a domain.
To enable this functionality, the root certificate for the user's account domain must be provisioned on the smart card. To provision the domain root certificate while using a computer that is a member of the domain, type the following at a command prompt:
certutil -scroots update
In addition, for Terminal Services access across trusting domains, the KDC certificate of the domain of the Terminal Services computer needs to be present in the NTAuth store of the client computer. The following command can be used to provision this certificate onto the client computer:
certutil -addstore -enterprise NTAUTH certfile
Replace certfile with the root certificate of the KDC certificate issuer.
To log on to a terminal server by using a smart card from a client computer that is not a member of the domain, the smart card needs to be provisioned with the root certificate of the terminal server's domain controller. Furthermore, cross-domain terminal server logon will only work if the UPN attribute of the certificate is in the form username@domain_dns_name.
If it is impossible or impractical to deploy certificates with the UPN attribute in this form, enabling domain hints with Group Policy is a potential solution.
Terminal Services and smart card logon registry settings
Warning
Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.
If smart card logon is the only form of logon that is supported, enable the following registry setting:
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\CredentialsDelegation
AllowFreshCredentials
If the user also has a corresponding password-enabled account, enabling the following setting would also be useful:
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\CredentialsDelegation
AllowFreshCredentialsWhenNTLMOnly
Delegation of default and saved credentials are not supported for Terminal Services with smart card logon. The following Group Policy settings are ignored:
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\CredentialsDelegation
AllowDefCredentials
AllowDefCredentialsWhenNTLMOnly
AllowSavedCredentials
AllowSavedCredentialsWhenNTLMOnly