ConfigMgr
How to Access the Local System Account
Topics: ConfigMgr
“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.
- The local system account is a predefined local account used by the service control manager (SCM).
- It has extensive privileges on the local machine and acts as the computer on the network.
- This account does not have a password.
- A service (for example SCCM) that runs in the context of the local system account inherits the security context of the SCM.
- The service presents the computer’s credentials to remote computers.
- 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 authoritysystem. 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.
Methods to Access the Local System Account
Here are a couple of different methods to access the local system account followed by how you can confirm that you are in fact using the correct account.
Method #1 – 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.
Method #2 – 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.
Other Methods
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:windowssyswow64cmd.exe.
Use the Set pro command to see the Environment Variables to confirm that the cmd is x86 by reviewing the Processor_architecture value.
How Can I Confirm I am Using the Local System Account?
To confirm that you are utilizing the local system account you will want to remain in the cmd prompt that you used to access the account. From there you can confirm that you are using the local system account by simply running the whoami command.
Summary
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.
Frequently Asked Questions (FAQs)
What are the specific security risks of using the Local System Account, and how can they be mitigated?
Accessing the Local System Account carries significant security risks due to its high privileges, which could potentially allow for malicious activities or accidental system-wide changes. Mitigating these risks involves strict control over who has the ability to use this account and monitoring its use.
Are there other tools or methods, besides PsExec and the Configuration Manager console, for accessing the Local System Account?
While the article highlights PsExec and Configuration Manager console as methods to access this account, other tools like PowerShell scripts or third-party utilities also offer pathways, each with their own set of features and potential use cases.
What are some common issues or errors one might encounter when trying to access the Local System Account using the methods described, and how can they be resolved?
Common issues when accessing the Local System Account may include permissions errors or tool-specific errors, which generally require proper configuration of the tool being used and ensuring the user has adequate permissions to perform the desired actions.
