Smart Card and Remote Desktop Services

Updated: February 18, 2010

Applies To: Windows 7, Windows Server 2008 R2

Beginning in Windows Vista, smart card redirection logic and WinSCard API are combined to support multiple redirected sessions into a single process.

Smart card support is required to enable many Remote Desktop Services scenarios. These include:

• The ability to use Fast User Switching or Remote Desktop Services. A user is not able to establish a redirected smart card–based remote desktop connection. That is, the connect attempt is not successful in Fast User Switching or from a Remote Desktop Services session.

• Enabling Encrypting File System (EFS) to locate the user's smart card reader from the Local Security Authority (LSA) process in Fast User Switching or in a Remote Desktop Services session. If EFS is not able to locate the smart card reader or certificate, EFS cannot decrypt user files.

Remote Desktop redirection

In a Remote Desktop scenario, a user is using a remote server for running services, and the smart card is local to the computer that the user is using. In a smart card logon scenario, the smart card service on the remote server redirects to the smart card reader connected to the local computer where the user is trying to log on.

Notes about the redirection model:

1. This scenario is a remote logon session on a computer with Remote Desktop Services. In the remote session (labeled as "Client session"), the user runs net use /smartcard.

2. The arrows represent the flow of the PIN after the user types the PIN at the command prompt until it reaches the user's smart card in a smart card reader connected to the Remote Desktop Connection (RDC) client computer.

3. The authentication is performed by the LSA in session 0.

4. The CryptoAPI processing is performed in the LSA (Lsass.exe). This is possible because rdpdr.sys allows per-session, rather than per-process, context.

5. The WinScard and SCRedir components, which were separate modules before Windows Vista, are now included in one module. The ScHelper library is a CryptoAPI wrapper that is specific to Kerberos.

6. The 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 were made in Windows Vista to improve for smart card redirection.

RD Session Host server single sign-on experience

As a part of Common Criteria compliance, the RDC client must be configurable to use Credential Manager to acquire and save the user's password or smart card PIN. Common Criteria requires that applications not have direct access to the user's password or PIN.

Common Criteria requires specifically that the password or PIN never leave the LSA unencrypted. Applied to a distributed scenario, it should allow the password or PIN to travel between one trusted LSA and another, as long as it is not unencrypted during transit.

In Windows Vista, when smart card-enabled single sign-on (SSO) is used for Remote Desktop Services sessions, users still need to sign on for every new Remote Desktop Services session. However, the user is not prompted for a PIN more than once to establish a Remote Desktop Services session. For example, after the user double-clicks a Microsoft Word document icon that resides on a remote computer, the user is prompted to enter a PIN. This PIN is sent by using a secure channel that the credential SSP has established. The PIN is routed back to the RDC client over the secure channel and sent to Winlogon, and the user does not receive any additional prompts for the PIN, unless the PIN is incorrect or there are smart card-related failures.

Remote Desktop Services and smart card logon

The purpose of this feature is to enable users to log on with a smart card by entering a PIN on the RDC client computer and sending it to the RD Session Host server in a manner similar to authentication based on user name and password.

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

In addition to enabling the necessary Group Policy settings, policies specific to Remote Desktop Services need to be enabled for smart card–based logon.

To enable smart card logon to a Remote Desktop Session Host (RD Session Host) server, the Key Distribution Center (KDC) certificate must be present on the RDC client computer. If the computer is not in the same domain or workgroup, then the following command can be used to deploy the certificate:

certutil –dspublish NTAuthCA "DSCDPContainer"

The DSCDPContainer Common Name (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"

Remote Desktop Services and smart card logon across domains

Scenario: Remote access to an 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 computer that is joined to a domain, run the following at the command line:

certutil –scroots update

For Remote Desktop Services across domains, the KDC certificate of the RD Session Host server must also be present in the Windows Vista–based 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.

Remote Desktop Services logon across a domain works only if the UPN in the certificate uses the following form: <ClientName>@<DomainDNSName>

The UPN in the certificate must include a domain that can be resolved. Otherwise, Kerberos cannot determine which domain to contact. You can resolve this problem by enabling GPO X509 domain hints. For more information about this setting, see Smart Card Group Policy and Registry Settings.