In this short article we are going to provide half a dozen answers to common Local System account questions.
The Local System account is a user account created when the operating system is installed and is used primarily to run Windows Services that relate to the operation and maintenance of the local computer.
If you look at the screenshot in the next section, you will see the “Local System” is running most of your services by default.
Put simply, the LocalSystem account has unrestricted access to everything on the local computer. It has even more rights on the local host than a full Domain or Local Admin.
It’s username and GUID are stored on the machine in which it exists, and not in Active Directory.
The Local System account does NOT have a password so you cannot reset the Local System account’s password. That is why Windows Services does not even give you an option to enter a password when you select the LOCAL SYSTEM account (see screenshot to the right).
Further, LocalSystem does not have its own user profile so it uses C:\USERS\DEFAULT if required.
They “interact with desktop” checkbox on the Local System account option in Windows Services no longer does anything.
Up to Windows Server 2003 and Windows XP, the Interact With Desktop checkbox allowed the program / service to pop up dialog boxes and show the program’s GUI. However that was shown to be a serious security risk and by Windows Server 2008 and Windows Vista that check box was being maintained only for legacy reasons. Windows Server 2012 and 2016 had a workaround involving a registry hack but Windows Server 2019 and Windows Server 2022 have it completely blocked. It does nothing today.
In a word, yes… but quite limited on member computers and servers.
All Active Directory accounts (user and computer) have read permission to Active Directory however the Local System account is not an Active Directory account; it is a local account. It has the same rights and access as the computer which is why it gets confusing. Put more technically, LocalSystem its token includes the BUILTIN\ADMINISTRATORS and NT AUTHORITY\SYSTEM GUID’s.
This means that if you run a service on a Domain member PC or server, the service has only the network access that was granted to the host computer account (or to any groups of which the computer account is a member).
If that service needs to connect to a different computer on your network, it will present itself as the host computer name. So
On a Domain Controller the Local System account has FULL permission to the Active Directory which is why most companies have policies against using LocalSystem account to run services on DC’s:
If your service must run as LocalSystem, the documentation for your service should justify to domain administrators the reasons for granting the service the right to run at elevated privileges. Services should never run as LocalSystem on a domain controller.
learn.microsoft.com/en-us/windows/win32/ad/the-localsystem-account
The big differences between the LocalSystem and LocalService accounts are that:
As you can see the LocalSystem account is quite powerful and can do an awful lot to the local machine which is why it is generally not the best account to use to run services:
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)
This website uses cookies.
