Smartcard Redirection Diaries
Last month we finally closed two bugs that I've been engaged in on and off for well over a year and released two related hotfixes in the February hotfix release batch.
In late 2009, our Professional Support team got the following case from one of our ISV Partners (an established provider of security products, among them their own CSP):
" We have discovered multiple issues with Windows Server 2008 R2 Remote Desktop Services where the symptoms are as follow:
- If you connect with two users at *exactly* the same time and have the Smartcard Removal Policy set to Disconnect, you can get into a scenario where if one user pulls their smartcard the other user also gets disconnected.
- If pre-authentication is disabled in an RDP file that is used to connect and you connect with two users at *exactly* the same time, you can get into a scenario where one user sees his own smartcard credential tile on the login screen as well as the smartcard credential tile of the other user that connected at the same time.
- Occasionally, if you connect with two users at *exactly* the same time, you can get into the scenario where clicking on your tile and logging on with your PIN reconnects you to the session of another user (AKA "Session Mixup").
- If you disconnect a user and reconnect twice, that user can get into an infinite disconnect loop where she is immediately disconnected the next time she attempts to reconnect. "
When I started working on it the first hurdle was to get a reliable repro - if we can't repro the issue we simply can't file a bug report as our developers don't have anything to work with in that case.
However, we did finally get to the point where we could sit down and start talking to the development team about a possible fix, among the things we determined was that:
- The two "unexpected disconnect" issues only occurred in relation to Reconnections - the initial connections weren't affected.
- The Base CSP wasn't affected by the "foreign credential tile" problem while the 3rd party CSP was.
- The "Session Mixup" issue was never seen during our tests on RDS servers with RDP clients
(Note that the phrase "Session Mixup" is verbatim from the customer but is a very broad definition and not really accurate in technical terms in this case - "Incorrect Session Arbitration" would be a more accurate term for the reported symptoms).
So, to summarize:
- Foreign smartcard logon tile appears on logon screen
- Resolved in the Base CSP by creating and setting FilterCSPCardCacheByTSSessionConnectTime to 1 – it is by default 0 or not present.
- 3rd party CSP’s may need to do similar filtering of card entries in their cache based on session connect time or they will most likely hit the same issue.
- Using a 3rd party mini-driver that leverages the filtering functionality of the Base CSP is an alternative solution.
- Disconnect other user issue
- Resolved in W2k8 R2 hotfix http://support.microsoft.com/kb/2301288 (updates Winscard.dll to 6.1.7601.21624)
- Disconnect self loop upon 2nd reconnect issue
- Resolved in W2k8 R2 hotfix http://support.microsoft.com/kb/2424375 (updates Winscard.dll to 6.1.7601.21642)
- Session arbitration connecting users to wrong sessions when under stress conditions (AKA the “Incorrect Session Arbitration” issue)
- We never saw this in our repro attempts on W2k8 R2 RDP servers
Note that both 2301288 and 2424375 are updates to the same binary (Winscard.dll) so you need only install the more recent one (2424375).
Footnote: The primary purpose of this blog entry is to pull together disparate information about what is essentially a very generic end-user symptom (users with unexpected problems during reconnections to terminal servers) and list past fixes from the Microsoft side that have been known to address specific customer-reported issues that have exhibited those symptoms. As the symptoms are very general and there may be other components (Microsoft or third party) that exhibit similar symptoms, it should be noted that this does not mean that these particular fixes will be addressing any and all such general symptoms in either a Microsoft or a third party product, in either past, present or future OS releases.
The secondary purpose of this entry is to reinforce the awareness that in a complex system with multiple components involved such as terminal servers with smartcard redirection, you need to be aware that an issue can have multiple causes with similar symptoms being reported by the end-user and could need multiple fixes in different components.
When a generic symptom is encountered and you have two different components involved it is very easy for either party to point a finger at the other as being the cause for the issue but this ultimately doesn't help identify the issue nor does it help the end-user.
I.e. you must look at the whole picture and not just focus on one piece of it - the correct way to troubleshoot this is to analyze and debug the specific component or components from both sides.
Further details:
Available Updates for Remote Desktop Services (Terminal Services) in Windows Server 2008 R2
http://support.microsoft.com/kb/2601888
A smart card logon to a terminal session stops responding server that is running Windows Server 2008 and Windows Server 2008 R2
http://support.microsoft.com/kb/949538
A remote desktop session may be incorrectly disconnected when a smart card is removed in another remote desktop session in Windows Server 2008 R2
http://support.microsoft.com/kb/2424375
A Remote Desktop Services session is disconnected automatically if you apply the "Interactive logon: smart card removal behavior" Group Policy setting in Windows Server 2008 R2 or in Windows 7
http://support.microsoft.com/kb/2301288
Comments
Anonymous
January 01, 2003
Note that 'session hijacking' isn't really a very precise technical term and how the reader interprets it will probably vary greatly - I assume what you're talking about is similar to what is discussed in support.microsoft.com/.../949538 where you could get multiple smartcard logon tiles for one user when specific timing conditions during reconnections were hit. In either case - the general recommendation is to move to the Mini-driver+Base CSP architecture where the Base CSP takes care of the basic operations and the vendor's mini-driver only needs to deal with card-specific things (especially for terminal servers as this exposes issues that don't come to the surface on single-user systems) .Anonymous
June 16, 2011
There was another Issue with this too. Third party CSP is used with RDP. This also caused session hijacking and the issue was found in the wild. Using base CSP and the fixes above should take care of this too.