RDP client does not consider smart card as valid for authentication

Question

I have:

• A Windows 7 client machine. I am not Administrator for that machine.
• A Windows 2008R2 server, on which I want to open a session using Remote Desktop.
• A Remote Desktop Gateway, also running Windows 2008R2.
• A smart card.

The server is configured to allow smart card logon. The gateway requires smart card authentication as well. All client and servers know and trust all relevant CA certificates, no certificate is expired, all CRL are published where they should.

Crucially, the certificate on the smart card has an Extended Key Usage extension (EKU) which does NOT contain the "smart card logon" OID. It features "client authentication", though. The server and the gateway have been configured to nevertheless accept the certificate: this is a policy setting called "Allow certificates with no extended key usage certificate attribute", as described there.

The Problem

The client uses a .rdp file in which are specified the server name and the gateway name. Since the gateway is a gateway, and not an actual remote desktop servers, it has no "login screen" to show. Instead, smart card authentication relies on a GUI handled by the client (mstsc.exe, the standard RD client in Windows) to let the user select his smart card, and enter his PIN code. Here is how the popup should look like:

(Sorry for the French-speaking popup; I don't have a British-speaking Windows 7 at hand.)

Unfortunately, that popup does not appear like this. Instead, I get this:

Analysis

As described here, the client application (mstsc.exe) will let the OS (Windows 7) "enumerate" the smart cards. The OS will look for smart cards containing certificates which fulfil some criteria, in particular that any EKU extension found in any such certificate contains the "smart card logon" OID. This is done prior to actually trying to talk to the gateway, let alone the ultimate target server. The gateway and server would be perfectly happy with my certificate; they have been configured that way. However, the client OS enforces the same rules, according to its own configuration. In my case, the Windows 7 refuses to let me use my smart card because its local policy would reject it for opening a local session (even though I am not trying to open a local session at all).

This used to work with a Windows XP client, because the "smart card selection popup" of Windows XP does not enforce these checks (Windows XP checks the EKU in an even more restrictive way, because it does not tolerate a lack of EKU extension, but it enforces these checks only when actually trying to open a local session, not when selecting a certificate for a remote session).

The Solution That I Cannot Use

The "normal" solution is to configure the local client (Windows 7) with the same "Allow certificates with no extended key usage certificate attribute" as the server. That way, the smart card selection popup now accepts to show the smart card, and things are fine. I tested it on another system. However, I cannot do that on my target systems, because changing the local policy requires Administrator rights, that I do not have. Similarly, for clients which are part of a domain, the setting could be pushed from a GPO on the AD server, which is again barred to me for lack of appropriate privileges.

One may also say that this policy setting actually allows login on the client machine with a certificate which does not have the proper OID in its EKU, and that can be considered as an undesirable side effect. I am trying to open a session on a remote server; I should not have to change the conditions for opening a session on the local client.

Older mstsc.exe versions (from Windows XP) could apparently connect to the server without requiring any client authentication; in that case, the remote server would display its login screen (the "big blue-green screen") and handle smart card enumeration itself. Since the server has the appropriate policy, then this would work. However, I cannot use such a solution for two reasons:

• The mstsc.exe from Windows 7 apparently insists on doing authentication with its own popups.
• There is a gateway, which, contrary to the ultimate target server, has no "login screen" to show. When using a gateway that requires client smart card authentication, the client smart card selection must be managed by the client software.

The Question

So here is my question: is there a way out of this issue ? Ideally, some sort of configuration setting in mstsc.exe (a command-line switch or a clause in a .rdp file) which would instruct mstsc.exe NOT to use the OS smart card selection popup, but to do the enumeration on its own, without trying to enforce anything about the EKU. I have found no trace of such a feature, but absence of proof is not proof of absence. I may have simply missed it.

Solution

Create an .rdp file for the connection, set enablecredsspsupport:i:0 inside the .rdp file and make sure that you have the smart card option for local resource mapping enabled (It defaults to on, so that should be the case already unless you explicitly changed the settting.)

See the following entry for more details: http://blogs.msdn.com/b/rds/archive/2007/01/22/vista-remote-desktop-connection-authentication-faq.aspx#_When_to_use

I'm not quite sure if this will work to solve your issue because of the gateway in the middle, but frankly, I can't think of any possible other solution for this issue.

Comments

[Thomas Pornin]

I will try it tomorrow, when I am back to work. From your description, it looks promising.

[Thomas Pornin]

Unfortunately, it does not work: the client is necessarily aware that it must talk to a gateway, and decides to ask for user credentials before talking to the gateway; and enablecredsspsupport changes nothing to it.

[A for A]

IMHO, that warrants a support call with Microsoft.