This question comes up from time-to-time, “How can I access the local system account?” Fear not! In this blog post, I show you two different ways to access this account. Why do you need to know how to do this? When SCCM/ConfigMgr does just about anything, it uses the local system account to perform those tasks. Knowing how to access the local system account is really important for troubleshooting issues because you need to use this account.
What is the Local System Account?
The local 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 computer 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 SCCM, 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 problems, in most cases, by replicating how SCCM would access those resources.
In a nutshell, in order to use the local system account, you MUST be a local administrator. There are several ways to access 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 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 ways 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 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 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.