Freigeben über

Automatic logon to RDS using Smartcards with multiple certificates (with or without TS Gateway)

  • Artikel

Got the following escalation recently from a customer that was implementing TS Gateway and smartcards with multiple logon certificates:

When we connect with RemoteApp from our external workstations to the internal Terminal Server SSO seems to work fine if there is only one logon certificate present on the smartcard.  

If there are two logon certificates present on the smartcard however, the user gets the Username/Password prompt and is required to click the ‘Switch User’ button and manually choose the correct credential tile.

First thing we did was to remove the TS Gateway from the picture and connect directly; it was the exact same behavior without it being in the middle so we knew this was not a TSG-specific issue.

The difference between domain- and non-domain joined scenarios when the mutual authentication of the client and server occurs is that a domain-joined machine will use Kerberos (via CredSSP) and negotiate SSL (TLS 1.0) Session Security.

A non-Domain joined client will do a fallback to RDP Session Security and use NTLM – the interesting question is why it is working with NTLM when only one certificate is present on the smartcard.

After some research on this we determined the following is the cause for this:

  • When connecting (via TS Gateway or directly)from a workstation that *isn't* joined to the domain the negotiated session security falls back to RDP Session Security and NTLM.
    • When fallback to RDP Session Security is performed it means that the client can only send the PIN to the remote TS.
    • This is because the username/password fields being passed when RDP Session Security is negotiated are limited to 256 bytes which would not be enough to contain either a unique certificate hash or a complete certificate.

 

  • When connecting (via TS Gateway or directly) from a workstation that is joined to the *same* domain as the RDS the negotiated session security uses SSL (TSL 1.0) through CredSSP and Kerberos.
    • CredSSP supports multiple certificates on smartcards, RDP Session Security doesn't.
    • CredSSP is able to send enough information about the certificate chosen on the client-side to the server so that the server is able to use that to do an automatic logon using exactly that certificate.

The behavior in Vista RTM was to automatically attempt to logon with the PIN supplied using the certificate in the default container on the smartcard when RDP Session Security and NTLM are used. There is however no possibility to do any matching on the server-side between the certificates on the card inserted into the redirected smartcard reader and the PIN as that information cannot be passed in the authentication fields that are sent to the server when NTLM and RDP Session Security are being used.

This was determined to be an undesirable behavior as it could lead to either blocking of smartcards or even logging on using the incorrect security entity if the PIN happened to match the PIN on another inserted smartcard.

In short; this is a by design change from Vista that was made to the Smartcard Credential Provider code in Windows 7.

  • If RDP Session Security and NTLM is negotiated and if only one certificate exists on the smartcard the Smartcard CP attempts automatic logon using it and the PIN supplied.
  • If RDP Session Security and NTLM is negotiated and more than one certificate exists on the smartcard the Smartcard CP does not attempt an automatic logon as it cannot guarantee that the PIN supplied is for the intended target.
  • If TLS and CredSSP *is* negotiated and pre-Authentication succeeds the server can be sent information sufficient to do an automatic logon using the correct certificate even if more than one certificate is present on the card.

I.e. it all comes down to protocol limitations, as RDP Session Security doesn’t have the possibility to send the certificate information to the server and is limited to only sending the PIN it means that if you end up using RDP Session Security (like non-domain joined workstations do or workstations that fail Kerberos pre-authentication during the RDP connection) then the server cannot guarantee that the PIN supplied is for the intended smartcard certificate so the design decision for Windows 7 was made to not attempt an automatic logon in that case.

In that case the user ends up on the login screen and has to click the ‘Other User’ button and manually click the desired tile.

 

Related links:

RDS Blog post on enabling SSO on terminal server connections
http://blogs.msdn.com/b/rds/archive/2007/04/19/how-to-enable-single-sign-on-for-my-terminal-server-connections.aspx