Smartcard logon over Terminal Services ( RDP redirection )
In a recent post I outlined a number of ‘challenges’ to implementing smartcards.
I also asked about people who were hitting slow logons after implementing smartcards. Well I had a few responses as well as some interest in how RDP redirection works in general.
When a user logs on to a machine via smartcards there is a complex interaction between, the client, the terminal server, the domain controller and the CRL retrieval points.
Additional complexity may be added if they use an OCSP client\responder.
From a pure PKI perspective, the DC needs to validate and perform any necessary CRL retrievals for the smartcard certificate, and the client needs to mutually authenticate the Domain Controller certificate.
In addition, there are checks on specific certificates issued to the Active Directory as well as the underlying Kerberos authentication and account checks against the UPN of the user to the data contained in the certificate.
Redirection
When the client chooses to redirect the calls from the Terminal Server, it becomes much more complex.
At this point any calls that the CSP makes to the smartcard functions will take longer due to the roundtrip needed to the client ( however near or far that may be )
This will introduce natural delay for those CSP’s which are not optimized for this scenario ( i.e make many calls to the various smartcard functions in Winscard.dll.
Details on the call from the TS perspective
CSP calls the smartcard API’s in winscard.dll, winscard determines if the reader is remote. If it is remote the call is passed to scredir.dll which will hand off to the RDP driver in order to send it over to the client.
Details on the call from the Client perspective
MSTSC.EXE receives the inbound call from the Server side. It hands this call to Winscard.dll on the client and from there determines it needs to talk to the actual smartcard device.
In order to talk to the smartcard device, it will utilize a private communications channel to scardsvr.exe
Scardsvr.exe will coordinate the communications to the smartcard driver via IOCTLS sent via DeviceIoControl. Once the HW device handles the call via the driver from the vendor – it will send its response back up the stack and over the same network connections previously used.
Now that the background is laid, here is how the problem surfaced. Users logon at home or from a hotel ( let’s say Washington ) VPN to the nearest point – let’s say Denver, and then try to TS to a client in Florida.
You can imagine some delay would be introduced, however it was taking 4-7 minutes to logon ( and sometimes it would simply never logon ) when they used smartcards to TS to the Florida server in this scenario.
There is no logging in this area so we had to instrument scredir.dll a bit in order to determine where the latency was. We did this on the server side, so we knew when the client hit the server and the server needed to ask for data from the client.
It turned out that there were large delays, so we turned to the client. From the client’s perspective, we finally narrowed it down to a delay in the CSP. We contacted the CSP vendor and when they got a fix, logon times went to about 10 seconds!
With this story , and my last post – you can see that it is imperative that you do your homework and TEST TEST TEST before choosing a vendor.
Spatdsg
