LocalSystem Account
The LocalSystem account is a predefined local account used by the service control manager. This account is not recognized by the security subsystem, so you cannot specify its name in a call to the LookupAccountName function. It has extensive privileges on the local computer, and acts as the computer on the network. Its token includes the NT AUTHORITY\SYSTEM and BUILTIN\Administrators SIDs; these accounts have access to most system objects. The name of the account in all locales is .\LocalSystem. The name, LocalSystem or ComputerName\LocalSystem can also be used. This account does not have a password. If you specify the LocalSystem account in a call to the CreateService or ChangeServiceConfig function, any password information you provide is ignored.
A service that runs in the context of the LocalSystem account inherits the security context of the SCM. The user SID is created from the SECURITY_LOCAL_SYSTEM_RID value. The account is not associated with any logged-on user account. This has several implications:
- The registry key HKEY_CURRENT_USER is associated with the default user, not the current user. To access another user's profile, impersonate the user, then access HKEY_CURRENT_USER.
- The service can open the registry key HKEY_LOCAL_MACHINE\SECURITY.
- The service presents the computer's credentials to remote servers.
- If the service opens a command window and runs a batch file, the user could hit CTRL+C to terminate the batch file and gain access to a command window with LocalSystem permissions.
The LocalSystem account has the following privileges:
- SE_ASSIGNPRIMARYTOKEN_NAME (disabled)
- SE_AUDIT_NAME (enabled)
- SE_BACKUP_NAME (disabled)
- SE_CHANGE_NOTIFY_NAME (enabled)
- SE_CREATE_GLOBAL_NAME (enabled)
- SE_CREATE_PAGEFILE_NAME (enabled)
- SE_CREATE_PERMANENT_NAME (enabled)
- SE_CREATE_TOKEN_NAME (disabled)
- SE_DEBUG_NAME (enabled)
- SE_IMPERSONATE_NAME (enabled)
- SE_INC_BASE_PRIORITY_NAME (enabled)
- SE_INCREASE_QUOTA_NAME (disabled)
- SE_LOAD_DRIVER_NAME (disabled)
- SE_LOCK_MEMORY_NAME (enabled)
- SE_MANAGE_VOLUME_NAME (disabled)
- SE_PROF_SINGLE_PROCESS_NAME (enabled)
- SE_RESTORE_NAME (disabled)
- SE_SECURITY_NAME (disabled)
- SE_SHUTDOWN_NAME (disabled)
- SE_SYSTEM_ENVIRONMENT_NAME (disabled)
- SE_SYSTEMTIME_NAME (disabled)
- SE_TAKE_OWNERSHIP_NAME (disabled)
- SE_TCB_NAME (enabled)
- SE_UNDOCK_NAME (disabled)
Most services do not need such a high privilege level. If your service does not need these privileges, and it is not an interactive service, consider using the LocalService account or the NetworkService account. For more information, see Service Security and Access Rights.
Send comments about this topic to Microsoft
Build date: 2/7/2012
The list above is inaccurate. A list of the privileges I got from a service on Windows 7.
SeAssignPrimaryTokenPrivilege Disabled
SeAuditPrivilege Enabled
SeBackupPrivilege Disabled
SeChangeNotifyPrivilege Enabled
SeCreateGlobalPrivilege Enabled
SeCreatePagefilePrivilege Enabled
SeCreatePermanentPrivilege Enabled
SeCreateSymbolicLinkPrivilege Enabled
SeDebugPrivilege Enabled
SeImpersonatePrivilege Enabled
SeIncreaseBasePriorityPrivilege Enabled
SeIncreaseQuotaPrivilege Disabled
SeIncreaseWorkingSetPrivilege Enabled
SeLoadDriverPrivilege Disabled
SeLockMemoryPrivilege Enabled
SeManageVolumePrivilege Disabled
SeProfileSingleProcessPrivilege Enabled
SeRestorePrivilege Disabled
SeSecurityPrivilege Disabled
SeShutdownPrivilege Disabled
SeSystemEnvironmentPrivilege Disabled
SeSystemProfilePrivilege Enabled
SeSystemtimePrivilege Disabled
SeTakeOwnershipPrivilege Disabled
SeTcbPrivilege Enabled
SeTimeZonePrivilege Enabled
SeUndockPrivilege Disabled
Please note for instance that there is the SeCreateSymbolicLink privilege in that list. From the LocalSystem account on my system, I usually get 4 additional privileges but there is also no SeCreateTokenPrivilege. Oh, and please note, this isn't an attempt at passing off my list as a "definitive list" it is just to point out that the list given in this topic is missing some privileges that this account normally has when the token hasn't had privileges stripped on Windows 7.
Re: the comment by GeekWench.
The comment by GeekWench was originally aimed at this comment, but since I wanted to edit this to make it less like "this is a definitive list" and more like "this topic isn't quite right, see what I get" it is now above.
Anyway, about the registry key that you pointed out. Yes it is true that if the RequiredPrivileges key is set then the SCM removes privileges from the user token, this is assuming that I wasn't in control of the service. The service being used was written by me and completely under my control. In doing this, I guaranteed that the RequiredPrivileges registry value wasn't set. When this isn't set, it is documented to give all privileges available to that user. See http://msdn.microsoft.com/en-us/library/windows/desktop/ms685976(v=vs.85).aspx for this.
- 7/7/2011
- crescens2k
- 5/11/2012
- crescens2k
- 3/18/2011
- Prashant Thakwani
