You've come to this page because you've asked a question similar to the following:
What is a "session" on Windows NT? It is a login session?
This is the Frequently Given Answer to such questions.
The use of the term "session" on Windows NT is confusing. On other operating systems, the concept of a "session" is related to that of a "login session". On Unix and Linux, for example, when one has logged in using the TUI login program, a "session" is a "login session".1 On Windows NT, it is not.
The notion of a "session" arose from the introduction of Terminal Services to Windows NT. Terminal Services allows a remote machine to act as a secondary graphical "terminal" to a Windows NT system2, allowing multiple users to interact with a single machine simultaneously.3
Unfortunately, whilst the security part of Windows NT had been designed to support multiple users, much of the design of the rest of the system had wrongly assumed that there would only ever be one user interacting with the system at any given time. Many inter-process communication objects used by system processes, by the desktop user interface, and by subsystems such as the Win32 subsystem, had been assigned global names.
Terminal Services broke this assumption quite drastically. Therefore a
new concept was introduced, that of a "session". On Windows NT a
"session" is a way of partially virtualizing the operating system kernel.
Changes to the Object Manager in the kernel allow programs to continue to
use the old global names for things, whilst assigning them per-session
names under the covers. So the CSRSS can continue to use the name
"\BaseNamedObjects\CsrStartEvent" for an event object, and
the kernel's Object Manager ensures that for (say) session 3 the actual
name used under the covers for that event object is
"\Sessions\3\BaseNamedObjects\CsrStartEvent".
Because this mechanism was introduced to support multiple users logging in to the system simultaneously via Terminal Services, the name "session" was used for it, on the mistaken grounds that it mapped onto the concept of a login session. But it does not. With Terminal Services (and indeed with Fast User Switching), users can log in and log out arbitrarily within the same "session". A single "session" can comprise an arbitrary number of login sessions. The two concepts are not the same.
A "session" is simply a bodge added to the kernel's Object Manager to fix a broken DOS Think assumption made by a lot of code on the rest of the system. It provides a partial virtualization of the Object Manager's namespace.
Windows NT has two other mechanisms that are closedly related to "sessions":
A "window station" represents a collection of (zero or more) displays and
input devices, along with a Win32 clipboard and a Win32 global atom table.
Window stations are created by WINLOGON in every session that is used for
running GUI user programs, and by WININIT in "session 0" for GUI service
processes. Every session of the former type thus has at least one window
station, "\Sessions\ID\Windows\Windowstations\WinSta0",
presented by the Object Manager under the global name
"\Windows\Windowstations\WinSta0" to processes running in
that session.
There's irony here. As can be seen from the name "WinSta0",
the original intention was clearly that there be "WinSta1",
"WinSta2", and so forth. But DOS Think struck again. It
became documented that "WinSta0 is the name of the
only interactive window station" (You can read the documentation
here,
where the MSDN even now, years after the advent of Terminal
Services, still says exactly this.), and people thus hard-coded that name.
So sessions and virtualization of the Object Manager namespace had to be
used to ensure that different interactive user applications, logged in at
different displays and input devices but all (thanks to DOS Think) using
the name "WinSta0" as the name of the (single)
interactive window station that they presumed to exist, all ended up
correctly using different actual window stations — all, ironically,
named "window station #0".
A "logon session" is a fancy name for the scheme whereby the Local Security Authority creates a nonce security identifier (SID) that WINLOGON then uses to control who can access the user desktop — one of the three desktops that WINLOGON creates on the window station, and the one on which user programs' user interfaces are visible. (A minimal level of kernel participation is required in order to ensure that the nonce SIDs are truly unique, in the face of process tokens being duplicated and handed around to server processes. But otherwise the kernel largely ignores logon sessions, and they are primarily an artifact of the user-level LSA process.)
Whenever each WINLOGON performs the process of logging in a new user, the process token that it obtains from the LSA (which WINLOGON then attaches to all processes run by that user) contains the nonce SID for the logon session in addition to the SIDs for the user xyrself and for the user's groups. WINLOGON also adds an ACL to the user desktop to allow that SID, and only that SID, access to it. (WINLOGON does not add ACLs that allow the SIDs for the currently logged in user xyrself or for xyr groups access.4)
Thus even if the same user is logged in twice to the same system, xyr processes can only access the one desktop, the one that matches the logon session in which those processes are run.
Strictly speaking: On Unix and Linux a "session" is a collection of process groups that is managed by a "session leader". It is a kernel concept. Whereas the concept of a "login session" is an application concept, which the kernel is wholly ignorant of. When one has logged in using the TUI login program, one's initial shell process is set up as a session leader by the login program, all process groups belong to the same session, and the "login session" is effectively synonymous with the "session" managed by one's initial shell. When one has logged in via the GUI login program, however, the concept of a "login session" is unrelated to any kernel "session"s, and is instead denoted by the lifetime of one, selected, graphical program (usually one's graphical desktop user interface program). The kernel concept of "sessions" is not used by GUI login programs.
A "terminal" in Terminal Services is more akin to a remote X Window System server in Unix/Linux than it is to a Unix/Linux "terminal". Once again, the terminology does not align.
Terminal Services provides remote terminals. It does not provide "multi-head" support, where multiple display adapters, mice, and keyboards can be attached to a single physical machine and assigned to multiple "heads", i.e. physical stations where individual interactive users have their own individual collections of input and display devices. Windows NT does not yet have proper multi-head support. Multiple users can be logged in simultaneously, but "Fast User Switching" only allows multiple users to share one single "head" by switching it amongst them. They cannot interact with the system simultaneously using their own individual input and display devices, via multiple "heads".
This is in stark contrast to the way that things are organized on Unix and on Linux. On Unix and on Linux, the logon programs, and elements such as the pseudo-TTY subsystem, arrange for the ownership of the display and the input devices to be changed whenever a user logs in and logs out, setting it to the user's own user ID when xe logs in and resetting it to a system account user ID when xe logs out. As a consequence, if a user logs in twice or more, then xe can access (and, indeed, owns) all displays and input devices that xe has been assigned, from any login session.
© Copyright 2006,2008
Jonathan de Boyne Pollard.
"Moral" rights asserted.
Permission is hereby granted to copy and to distribute this web page in its
original, unmodified form as long as its last modification datestamp is preserved.