Token (Windows NT architecture): Meaning (information, definition, explanation, facts)

In the Windows NT architecture, a token is a system object (type name "Token") representing the subject in access control operations, i.e. the active part (the passive part being the object being accessed). Token objects are usually built by the logon service to represent the security information known about an authenticated user, but they are essentially free-form and can include any combination and number of the possible elements.

General information

A token itself is, oddly enough, an object in the Windows NT architecture, meaning that accesses on it are checked against... another token. As such, a token has an associated security descriptor, as well as an optional path in the object namespace (the latter is a standard feature of the object manager, but it's never used for tokens).

There are two kinds of tokens: primary and impersonation tokens. Primary tokens can only be associated to processes, and they represent a process's security subject. The creation of primary tokens and their association to processes are both privileged operations, requiring two different privileges in the name of privilege separation - the typical scenario sees the authentication service creating the token, and a logon service associating it to the user's operating system shell. Processes initially inherit a copy of the parent process's primary token. Impersonation tokens can only be associated to threads, and they represent a client process's security subject. Impersonation tokens are usually created and associated to the current thread implicitely, by IPC mechanisms such as DCE RPC, DDE and named pipes.

Impersonation is a security concept unique to Windows NT, that allows a server application to temporarily "be" the client in terms of access to secure objects, although critics think it's only justified as a cumbersome replacement of UNIX setuid/setgid executables (indeed, impersonation was much more justified in the initial microkernel design, less so in a more traditional architecture where so little of the client's environment is available to the server). Impersonation has three possible levels: identification, letting the server inspect the client's identity, impersonation, letting the server act on behalf of the client, and delegation, same as impersonation but extended to remote systems to which the server connects (through the preservation of credentials). The client can choose the maximum impersonation level (if any) available to the server as a connection parameter. Delegation and impersonation are privileged operations (impersonation initially wasn't, but historical carelessness in the implementation of client APIs failing to restrict the default level to "identification", letting an unprivileged server to impersonate an unwilling privileged client, called for it).

A token is composed of various fields, among which:

• an identifier
• the identifier of the associated logon session. The session is maintained by the authentication service, and is populated by the authentication packages with a collection of all the information (credentials) the user provided when logging in. Credentials are used to access remote systems without the need for the user to re-authenticate (single sign-on), provided that all the systems involved share an authentication authority (e.g. a Kerberos ticket server)
• the user identifier. This field is the most important and it's strictly read-only
• the identifiers of groups the user (or, more precisely, the subject) is part of. Group identifiers cannot be deleted, but they can be disabled. At most one of the groups is designated as the session id, a volatile group representing the logon session, allowing access to volatile objects associated to the session, such as the display
• the restricting group identifiers (optional). This additional set of groups doesn't grant additional access, but further restricts it: access to an object is only allowed if it's allowed also to one of these groups. Restricting groups cannot be deleted nor disabled. Restricting groups are a recent addition, and they are used in the implementation of sandboxes
• the privileges, i.e. special capabilities the user has. Privileges cannot be deleted, but they can be disabled. Most privileges are disabled by default, to prevent damage from non-security-conscious programs
• the default owner, primary group and ACL for objects created by the subject associated to the token

[placeholder]

[placeholder]