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 concept maintained by the Local Security Authority, and is largely an entirely application-mode mechanism, outwith the kernel. Each time that something in the system makes a (successful) request to the LSA to log on, with a username and a password, the LSA assigns a new logon session ID, which it returns to whatever was requesting the logon. The LSA process never assigns the same logon session ID twice. Since there's only one LSA process per machine, logon session IDs are locally unique to an individual machine until it is restarted.
The logon session ID also forms part of a nonce security identifier (SID), that is incorporated into the process token that the LSA returns in response to a log on request, alongside all of the other SIDs for the user xyrself and xyr groups. WINLOGON uses this logon SID 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. WINLOGON adds an ACL to the user desktop to allow that logon SID access to the user desktop. (WINLOGON does not add ACLs that allow the other SIDs in the token to access the user desktop.)
Thus even if the same user is logged in twice to the same system, xyr processes can only access the one user desktop associated with the relevant logon session, and cannot access the other desktops of the user. Conversely, every time that one uses "Run As…" to log on and run a program on the same desktop as someone else, a new process token with a new logon SID is created. In order to allow the programs running with that process token to access the user desktop, a additional access-control entry has to be added to the desktop's discretionary access-control list, with the new logon SID.
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".
© Copyright 2006,2008,2012
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.