You know the feature that Windows has had since XP, that allows "fast user switching"...?  I knew it was implemented using some variant of Terminal Services, but until recently I thought that different users' sessions were contained inside separate Window Stations (Winstas) and their applications would render on to separate Desktops.  Not so.  Here's what actually happens...

When Windows boots, you get a single interactive Winsta, whose name is Winsta0.  There is a single Desktop in that Winsta, whose name is Winlogon.  This is the desktop that displays the various login buttons, the power menu and accessibility options.  When you log in, as soon as the shell has something to display, Windows switches to another desktop whose name is Default.  That is where all your applications render their output.  If and when a screensaver is activated in your session, Windows will switch to a third desktop, solely used for screensavers.

• You will never have another Desktop or Winsta unless one of your applications explicitly creates one.
• The Winlogon and Screensaver desktops are "secure" - once they are showing you might have to enter a password to get back to the Default desktop.

So how is it that I can have multiple user sessions active on my machine, and UI belonging to each user's processes are somehow kept separate even though they all use the same Winsta and the same Desktop?  The key's in the access token.

Every process has an access token that represents the user account under which the process is running. Each thread inherits that token, against which the OS will check ACLs when the thread calls an API that attempts to access some secured resource.  So the access token is a runtime object that represents a user account.  But it also contains a member called SessionId, and that refers to the user session that the process should run it.  In turn, that determines which processes render their UI into the Default desktop when a specific user is active on the machine.

You can use the Process Explorer tool from www.sysinternals.com to inspect the access token of a running process.  Just right-click on a process in the list, choose Properties and click on the Security tab.

Armed with this knowledge, and a highly-privileged account, we can inject a process into somebody's already-established session.  In my next post I'll show how.