From: http://www.cnblogs.com/flier/
I briefly introduced the concept of Session in the Windows system in the previous article "DACL, NULL or NOT NULL" and lists the current system session information through a small tool KESESSTION written by itself. In this paper, I will analyze the method of traversing and acquiring the current system session information, and take this opportunity to have more in-depth understanding of the Winnt underlying account and authority management mechanism from the perspective of the session. Because the article is written in essays, it may be omission in the content, I hope everyone can supplement and correct.
Although the concept of session is very important, it is essentially transparent to high-level development in addition to programmers to deal with user login and security related transactions. Therefore, this paper is not much in this regard. To learn research sessions, the necessary articles and tools must be essential, the first push is the loggonsessions provided by www.sysinternals.com. This gadget can list all the session and related information that are currently using and related information, plus the -p parameter can further list the list of processes included in the session. Probably because www.sysinternals.com's cattle believes that the program is too simple, there is no source code, huh, wait, let's take a look at how to implement a highly identical KESESSION tool. In addition, Keith Brown's Handle Logons in Windows NT and Windows 2000 With your OWN Logon Session Broker, as well as those attached to the article Cmdasuser. This tool creates a complete session test environment with a specified user identity to create a new session and load a user configuration and environment. Finally, Jeffrey Richter and Jason Clark in Chapter 11, User Context, Programming Server-Side Applications for Microsoft Windows, provides a very powerful token management tool, token master, you can view any process of current system, thread token (Token).
The functionality of the LoggonSsSion program is actually easy. By calling the LSAENUMERATELOGONSESSIONS function provided by calling the native security Authorization (LSASS) to enumerate the current login session, call the lsagetlogonsessionData function for each session to get further session information. NTSTATUS NTAPI LSAENUMERATELOGONESSIONS (Pulong LogonsessionCount, Pluid * LogonsessionList);
NTSTATUS LSAFREERTURNBuffer; the LSAENUMERATELOGONSESSIONS function is very simple, directly returns the number of sessions and saves an array of each session ID. Each element of this array is a LUID type. It is actually a 64bit integer that releases the buffer through the LSAFReereturnBuffer function after use. NTSTATUS NTAPI LSAGETLOGONESSIONDATA (PLUID Logonid, PSecurity_logon_Session_Data * PPLogonsessionData); for each session, you can call the lsagetlogonsessionData function to get further information. This function returns a structure that saves session information and releases the buffer through the LSAFREERERETURNBuffer function after use. typedef struct _SECURITY_LOGON_SESSION_DATA {ULONG Size; LUID LogonId; LSA_UNICODE_STRING UserName; LSA_UNICODE_STRING LogonDomain; LSA_UNICODE_STRING AuthenticationPackage; ULONG LogonType; ULONG Session; PSID Sid; LARGE_INTEGER LogonTime; LSA_UNICODE_STRING LogonServer; LSA_UNICODE_STRING DnsDomainName; LSA_UNICODE_STRING Upn;} SECURITY_LOGON_SESSION_DATA, * PSECURITY_LOGON_SESSION_DATA; SECURITY_LOGON_SESSION_DATA structure stored Session data includes: size saves the size of this structure, which is a variable data pattern provided by the later size change.
Logonid Save this session's Luid internal number, user globally positioned, such as the logonid of the SYSTEM account login is 999 (0x3e7)
UserName and Logondomain save this session login account and domain, which is the full account name after logondomain / username, such as Sky / Flier $ or FLIER / Administrator
AuthenticationPackage Save this session authentication method. Generally, this machine is NTLM, and the network session is Negotiate.
Logontype is relatively complicated, except for the most common interaction logins and network logins, there are batch and service logins, and rare agents. TYPEDEF ENUM _SECURITY_LOGON_TYPE {interactive = 2, // Interactively logged on (local Or Remotely) Network NetWork , // Accessing system via network Batch, // Started via a batch queue Service, // Service started by service controller Proxy, // Proxy logon Unlock, // Unlock workstation NetworkCleartext, // Network logon with cleartext credentials NewCredentials, // Clone caller, new default credentials RemoteInteractive, // Remote, yet interactive Terminal server CachedInteractive // Try cached credentials without hitting the net} SECURITY_LOGON_TYPE, * PSECURITY_LOGON_TYPE;.. a more complete list of the type described in the landing parameters LogonUserEx function can see . Interactive Login is the user through the computer console to log in to the system. The network is logging in to the network, and the session is visiting this computer via network neighbors; Batch login is generally used Use when batch queues, such as COM SCM Services, which is available for background service, such as System SCM
The above four login types are the most common, and the additional landing type applies to special circumstances
Proxy login basically rarely used, MSDN simply said that this type does not support unlocking (UNLOCK) After the user lock screen, the Gina is used to unlock when the LogonUser function is unlocked. NetWorkclertext. Allow users to log in to the system over LogonUserex, the username and password are saved to log in again to other servers (Newcredentials) to log in to allow users to access the current token of the locally, when using a separate credential remote interaction with external network connections (RemoteInteractive) Login is logged in the login method when the terminal service is connected to the server, allowing a similar desktop operation with interaction, and caching the user's credentials, avoid redundant network verification, etc. without the need to log in locally. Wait
The login type directly determines the capabilities of this session and the restrictions, and later resolves again.
The Session field saves an explicit session number. This number is typically a user terminal server, a local session, and an interactive login session this number is 0, and the remote interaction can get a new number. The system passes this number, in the Object Manager, map / baseNameDObjects to / sessions / 1 / Wait, interested friends can further refer to the NT Object Manager related articles.
The SID field saves this session to log in to the account, corresponding to the front login name;
Logontime is a time time of a non-local time zone, indicating the session start time; the last logonserver, DNSDomainName, and UPN generally provide further information on the account when using the active directory.
After understanding this information, it is easy to write a program that traversed the login session information, and two examples of traversal and information acquisition are also available in MSDN. For example: void __fastcall tessionmanager :: refresh (void) {lsadata
m_SESSIONS.CLEAR ();
Win32Check (status_success == LSAENUMERATELOGONSESSITIONS (& Count, & sessions));
For (int i = 0; i <(int) count; i ) {lsadata
Win32Check (status_success == LsageTlogonsessionData);
IF (data) m_sessions.push_front (tkernelsession (data));}} It is worth noting how to associate the process and session. This requires NTDLL :: ZwQuerySystemInformation or PSAPI :: Enumprocesses to traverse the system process, get your token for each process, and get the statistics tokenstatistics from the token using the GetTokenformation function, where token_statistics :: authenticationID is the session of this token ID. Const Luid __fastcall tsystemprocess :: getlogonid (void) const {if (FID == 0 || fid == 4) Return Luid ();
TsystemHandle Hproc = :: OpenProcess (Maximum_Allowed, False, FID);
IF (! hproc.valid ()) Return Luid ();
TsystemHandle HtokeN;
IF (! :: openprocessToken (HProc, token_Query, & HToken) Return Luid ();
Token_Statistics Stat; DWORD DWSIZE = 0;
Win32check (:: GetTokenInformation (HTOKEN, TOKENSTATISTIS, & Stat, Sizeof (Stat), & DWSIZE);
Return stat.authenticationId;} The other is worth noting how to get the SID of the session. Each session is started, and the system will automatically register a SID to facilitate permission control for objects such as WinStation. Because a WinStation can be used by multiple session, there is a case where multiple session that may have the same account may have different access to this WINSTATION. So the system creates a globally unique SID for each session so that the control of the user objects such as WinStation can be detailed to each session, even these session use the same landing account. Using the Process Explorer tool provided by www.sysinternals.com, view the Winstation object to the Winlogon.exe process, you can find an S-1-5-5-XXX-YYY in addition to the ordinary administrator and SYSTEM. ACE. The beginning of this S-1-5-5 is the SID of the session, while XXX-YYY is generally the number of the session. This SID can be obtained by any process token in this session. Each token can have multiple groups of SIDs, which will have a Group SID type property including the SE_GROUP_LOGON_ID flag, this is the SID of the Session of this token, which can be permissions to control the level of permissions in session. You can view the token of this Group SID through the Tokenmaster tool. SID # 8SID: S-1-5-5-0-51085Use: Logon Sidname: [Logon SID] Domain Name: SID Attribs: SE_GROUP_MANDATORY SE_GROUP_ENABED_BY_DEFAULT SE_GROUP_ENABED SE_GROUP_LOGON_ID
At this point, the basic functions of enumeration and acquisition of system session information have been described. The next section will further explore how the internal system is implemented and used in the SESSION concept.
