“What is the local system account?”
“What privileges does the local system account have?”
“What’s the difference between the ‘site server computer account’ and the ‘local system account’?”
“How can I utilize the local system account?”
These are questions that come up from time to time.
Fear not! In this blog post, I’ll answer these questions and show you two different ways to access this account. Why do you need to learn how to do this? When SCCM / ConfigMgr does just about anything, it uses the local system account to perform those tasks. Knowing how to log into local system account is really important for troubleshooting issues because you need to use this account.
What is the Local System Account?
The local Windows system account is also the computer account when accessing resources not located on itself. More importantly, computer accounts generally do not have security access rights to most resources which don’t reside on the computer itself such as remote shares. The local system account “user” profile can be different than normal “user” profiles too. Think of items like environmental variables.
Here is a 6-point summary about the access rights of the local system account.
1. The local system account is a predefined local account used by the service control manager (SCM).
2. It has extensive privileges on the local machine and acts as the computer on the network.
3. This account does not have a password.
4. A service (for example SCCM) that runs in the context of the local system account inherits the security context of the SCM.
5. The service presents the computer’s credentials to remote computers.
6. If the service opens a command window in interactive mode, the user can gain access to a command window with local system permissions.
Please see Local System Account, for the Microsoft definition.
SCCM and the Local System Account
If you read the official docs for SCCM, Accounts Used in Configuration Manager, you notice that the term site server computer account is used more often than the term local system account. In either case, these terms/accounts are one and the same from a security standpoint.
How Can I Use the Local System Account?
Before you start testing anything to do with an SCCM service account, you need to confirm that you are using the local system account, also known as the computer account or nt authority\system. Once you know that you are using the local system account, then you can troubleshoot an error, in most cases, by replicating how SCCM would access those resources.
In a nutshell, in order to use the local system account, you are REQUIRED to be a local administrator. There are several ways to connect to the local system account in order to perform your testing with this account. Generally speaking, all methods start with a cmd prompt, but how you get to the cmd prompt starting point is the main difference.
Once you get to the cmd prompt, you can confirm that you are using the local system account by simply running the whoami command. In the next sections, I talk about how you can get to this starting point (running the whoami command).
First Method – Create an SCCM Package
Whether you create an SCCM application or package, it doesn’t really matter. Either option works, but I generally prefer a package/program because it is less work. Since I documented the steps on how to do this within my blog post, Configuration Manager Deployment Test #1, I won’t repeat them again. This method is great because the package/program is deployed to your account, therefore it follows you anywhere that SCCM is installed.
Second Method – PsExec
PsExec is a small executable that you can download from Microsoft which allows you to access the local system account. Once PsExec is installed on a computer, open an elevated cmd prompt. Next, execute Psexec –s –i cmd from this window. This action opens another cmd window where you can use the local system account. This method is great if you don’t have the SCCM package/program deployed to your current active account.
Sure, there are other ways to access the local system account, such as Task Scheduler and SC.exe. They are painful, however, in comparison to the two solutions I just showed you above.
x86 vs x64
Rarely do you need to run the x86 cmd, but in a few cases, you need to do it.
Almost everyone is using x64 computers these days, so keep in mind that when SCCM is installing software (most of the time) it installs software as a x86 process. In a few, very rare cases, software installs correctly from a x64 cmd window, but fails in a x86 cmd window.
In these rare cases, instead of using the x64 cmd in any of the methods (the default is on x64 computers) use the x86 version. Before doing this, you first need to define the exact directory path to c:\windows\syswow64\cmd.exe.
Use the Set pro command to see the Environment Variables to confirm that the cmd is x86 by reviewing the Processor_architecture value.
The next time someone asks you if you tested <fill in the blank> with the local system account, you now have two ways to test things as SCCM / ConfigMgr would access them. If you have any questions about how to access the local system account, please feel free to touch base with me @GarthMJ.
See how Right Click Tools are changing the way systems are managed.
Immediately boost productivity with our limited, free to use, Community Edition.
Get started with Right Click Tools today: