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".note 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 systemnote, allowing multiple users to interact with a single machine simultaneously.note
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, each "session" has its own individual WINLOGON process. Users can thus log in and log out arbitrarily within the same "session". A single "session" can comprise an arbitrary number of login sessions. (Indeed, it can comprise several simultaneously, when "Fast User Switching" is employed.) 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 that has a
WINLOGON process (a so-called "WINLOGON session").
Therefore every such session 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).
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.note)
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.
Note: 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.
Note: 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.
Note: 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".
Note: 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.