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.
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.
Hey, i see you are pretty knowledgeable in MS smart card topics, and win security internals in general.
Im dealing with the same issues pretty often myself, i have written a CSP for a national smart card, Vista cardmodule alpha rev for the same card, done a "fake" winlogon-capable CSP, custom full GINA implementation and various related bits and pieces.
There is one thing that is very poorly documented, the automatic SC certificate propagation ( used to be SCCertProp winlogon notififaction package and is now a separate service in Vista ) .. is there any docs on how to configure that ? My main concern is to remove the certs when smart card is removed.
I also have tried to get my Winlogon notification DLL, ISensLogon inherited class and WMI events to get notifications on smart card removal, but none of them have worked for SC events, i can catch other events like logon and stuff fine.
So it would be nice if anyone could shed some light on this, asking in newsgroups has resulted in nothing so far.
Just as a reference, one real funny thing that i have tried is to get Win2K Smartcard PKI to interoperate with Heimdal Kerberos Domain ( using custommade certificates and all that ) so that Win2K desktop machine could log onto Heimdal domain, but we were ultimately stalled on an issue where some bit or piece of protocol simply had a byte or two wrong, and it didnt work out.
For some related policies\config around the new CertPropSvc in Vista - see Shivaram's blog here: http://blogs.msdn.com/shivaram/archive/2007/02/26/smart-card-related-group-policy-settings-in-vista.aspx
However, it doesnt take care of the removal events to cleanup the SC certs (it does roots "Clean up certificates on smart card removal" )
You can also use SCardGetStatusChange to do any store cleanup if you wanted to.
"You can also use SCardGetStatusChange"
Yes i know, but SCardGetStatusChange needs to have a separate thread running .. under which process ?
I could launch it from a winlogon notification package, but these are deprecated under Vista.
Also SCardGetStatusChange has one drawback: it does not take a synchronization parameter that would cancel the wait ( either a signal, mutex, semaphore or something ) so i have two options:
1) do SCardGetStatusChange with a short timeout and loop while checking for quit condition
2) kill the thread forcibly when quit is needed
neither is a very clean approach. i utilize the 1st in a CSP that i have developed and it results in registry access in each loop .. ie unneeded system load.
Best way to handle this would probably be via an NT service, which could get session change notifications from the service control manager. You'd have to spin up one thread per user session, due to the nature of SCardGetStatusChange.
Note that the proper way to cancel the GetStatusChange wait is via SCardCancel.
It seems I do spend a fair bit of time with smartcards lately, but I have some other interesting posts
How does WinScard determines if reader is remote or not? Could you please elborate on it.
this is really an internal implementation - what are your goals here?
Perhaps we can address it more directly?
Actually, I would like to understand how Winscard & scredir works.
I did small test using Process Explorer, if smart card reader is available (no matter if remote or locally) and you open RDP client, RDP client load both dll's i.e. WinScard.dll & Scredir.dll.
Does this means that these two dll's works independently? becuase if Winscard is actually detect if smartcard is remote and then calls scredir.dll then why Scredir.dll is loaded even if smartcard is local.
They work together ( in XP\2k3 ) in Vista they were merged into winscard.dll if I recall.
Anyway - we basically query the current session to see if it is a remote session - if it is, we then set some flags in the SCARDCONTEXT which is querieed when the SCard function is called - like SCardReconnect -- it will then redirect the call thru scredir if the remote flag was set in the context.
Hi, is it possible to access a smartcard reader that is physically connected to a 2K3 server within a RDP session? If I disable smartcard redirection within the client I expected, that I can access the smartcard readers connected to the server, but instead a call to SCardEstablishContext fails.
I do not believe this is possible
I am so happy to have found this blog...enormous help in understanding SC with TS.
I am a newbie to this so please need some help.
I have a 2K3 server with Terminal Server and about to load Gemalto drivers on it. My clients are however Win 2000 (yes!! - may move to Vista later this year). The company has deployed successfully SmartCard and now wants that when users who access TS need to have their SmartCard redirection. Any help or tips.? Another engineer who worked on this tested but said it took a long long time to authenticate and so gave up effort. But this is being revisted and The version of Reflex 2.0 PCMCIA. Are there any prior art on specific CSP related issues that could cause this time delays?
thanks in advance.
Is it possible to detect whether the user has logged in through a smart card or not,within a DLL which is meant for capturing the logon notifications , through the ISensLogon implementation route?
First to Sid..
The best I can give you is to test yourself, and make sure that you are on the latest CSP version from your vendor. Legally, I dont think I can officially recommend a specific vendor, as it can come back as "microsoft said use X left us out" or some such nonsense.