When a user is successfully authenticated, the authentication package (MSV1_0, NTLM, WDigest, Kerberos etc.) creates a logon session and returns information to the Local Security Authority (LSA) that is used to create a token for the user.
Each user logged and authenticated onto the system holds an access token with security information for that logon session (security context).
Every process executed on behalf of the user has a copy of the access token.
The token identifies the user (U.SID), the user's groups (G.SID), and the user's privileges (U. Rights), and contains information about the security context of the logon session, the Logon ID and the logon SID.
A cosmo user of the ASTRO domain makes an interactive logon (type 2).
At the time these credentials are validated (if we are in WORKGROUP the SAM database takes care of it, if we are on AD the NTDS.dit database and Kerberos take care of it), a logon session having a LUID is created. An Access Token is then generated that contains a 1:1 mapping between AuthID and LUID.
Every new logon session is identifiable via a 64 bit locally unique identifier (LUID), referred to as the logon ID, and every access token must contain an Authentication Id (or AuthId) parameter that identifies the origin/linked logon session via this LUID. The AuthID field contains a 64 bit LUID.
A logon session can have multiple access tokens associated with it, but an access token can only ever be linked to one logon session (which is typically the successful logon attempt that generated it). The mapping between Logon Sessions and Access Tokens is 1:N.
Windows has legitimate functionality which can be used to change the logon session (and hence cached credentials) that your current token is associated with.
Example:
We use the TokenViewer tool to analyze the token associated with the powershell process shown in the figure:
Through Sysinternals logonsessions.exe, we can list all the logon sessions currently created by the operating system and we see that there is a logon session 00000000:000705bd associated with the Authentication ID shown in TokenViewer:
If we launch a cmd process from powershell, as shown in the figure:
We note that the token associated with cmd is always mapped to the same logon session even though the token id is different since it is the token associated with the cmd process.
The token is issued to the user after a success logon. In the case of a local administrator, the tokens issued are 2, one for medium integrity and one for high integrity. Since Windows Vista, the concept of security context has been developed for processes to perform certain privileged operations in a secure manner. For some processes, the user who owns the service is not specified:
However, if we run ProcessHacker as an administrator, we have a higher integrity token and thus we can see higher level IntegrityID as that of NT AUTHORITY/SYSTEM.
