Using the LocalSystem Account as a Service Logon Account

One advantage of running under the LocalSystem account is that the service has complete unrestricted access to local resources. This is also the disadvantage of LocalSystem because a LocalSystem service can do things that would bring down the entire system. In particular, a service running as LocalSystem on a domain controller (DC) has unrestricted access to Active Directory Domain Services. This means that bugs in the service, or security attacks on the service, can damage the system or, if the service is on a DC, damage the entire enterprise network.

For these reasons, domain administrators at sensitive installations will be cautious about allowing services to run as LocalSystem. In fact, they may have policies against it, especially on DCs. 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. For more information and a code example that shows how a service or service installer can determine if it is running on a domain controller, see Testing Whether Running on a Domain Controller.

When a service runs under the LocalSystem account on a computer that is a domain member, the service has whatever network access is granted to the computer account, or to any groups of which the computer account is a member. Be aware that in WindowsВ 2000, a domain computer account is a service principal, similar to a user account. This means that a computer account can be in a security group, and an ACE in a security descriptor can grant access to a computer account. Be aware that adding computer accounts to groups is not recommended for two reasons:

• Computer accounts are subject to deletion and re-creation if the computer leaves and then rejoins the domain.
• If you add a computer account to a group, all services running as LocalSystem on that computer are permitted the access rights of the group. This is because all LocalSystem services share the computer account of their host server. For this reason, it is particularly important that computer accounts not be made members of any domain administrator groups.

Computer accounts typically have few privileges and do not belong to groups. The default ACL protection in Active Directory Domain Services permits minimal access for computer accounts. Consequently, services running as LocalSystem, on computers other than DCs, have only minimal access to Active Directory Domain Services.

If your service runs under LocalSystem, you must test your service on a member server to ensure that your service has sufficient rights to read/write to Active Directory Domain Controllers. A domain controller should not be the only Windows computer on which you test your service. Be aware that a service running under LocalSystem on a Windows domain controller has complete access to Active Directory Domain Services and that a member server runs in the context of the computer account which has substantially fewer rights.

How do you run CMD.exe under the Local System Account?

I’m currently running Vista and I would like to manually complete the same operations as my Windows Service. Since the Windows Service is running under the Local System Account, I would like to emulate this same behavior. Basically, I would like to run CMD.EXE under the Local System Account.

I found information online which suggests lauching the CMD.exe using the DOS Task Scheduler AT command, but I received a Vista warning that «due to security enhancements, this task will run at the time excepted but not interactively.» Here’s a sample command:

Another solution suggested creating a secondary Windows Service via the Service Control (sc.exe) which merely launches CMD.exe.

In this case the service fails to start and results it the following error message:

The third suggestion was to launch CMD.exe via a Scheduled Task. Though you may run scheduled tasks under various accounts, I don’t believe the Local System Account is one of them.

I’ve tried using the Runas as well, but think I’m running into the same restriction as found when running a scheduled task.

Thus far, each of my attempts have ended in failure. Any suggestions?

11 Answers 11

Though I haven’t personally tested, I have good reason to believe that the above stated AT COMMAND solution will work for XP, 2000 and Server 2003. Per my and Bryant’s testing, we’ve identified that the same approach does not work with Vista or Windows Server 2008 — most probably due to added security and the /interactive switch being deprecated.

However, I came across this article which demonstrates the use of PSTools from SysInternals (which was acquired by Microsoft in July, 2006.) I launched the command line via the following and suddenly I was running under the Local Admin Account like magic:

PSTools works well. It’s a lightweight, well-documented set of tools which provides an appropriate solution to my problem.

Many thanks to those who offered help.

1. Download psexec.exe from Sysinternals.
2. Place it in your C:\ drive.
3. Logon as a standard or admin user and use the following command: cd \ . This places you in the root directory of your drive, where psexec is located.
4. Use the following command: psexec -i -s cmd.exe where -i is for interactive and -s is for system account.
5. When the command completes, a cmd shell will be launched. Type whoami ; it will say ‘system»
6. Open taskmanager. Kill explorer.exe.
7. From an elevated command shell type start explorer.exe .
8. When explorer is launched notice the name «system» in start menu bar. Now you can delete some files in system32 directory which as admin you can’t delete or as admin you would have to try hard to change permissions to delete those files.

Users who try to rename or deleate System files in any protected directory of windows should know that all windows files are protected by DACLS while renaming a file you have to change the owner and replace TrustedInstaller which owns the file and make any user like a user who belongs to administrator group as owner of file then try to rename it after changing the permission, it will work and while you are running windows explorer with kernel privilages you are somewhat limited in terms of Network access for security reasons and it is still a research topic for me to get access back

Found an answer here which seems to solve the problem by adding /k start to the binPath parameter. So that would give you:

sc create testsvc binpath= «cmd /K start» type= own type= interact

However, Ben said that didn’t work for him and when I tried it on Windows Server 2008 it did create the cmd.exe process under local system, but it wasn’t interactive (I couldn’t see the window).

I don’t think there is an easy way to do what you ask, but I’m wondering why you’re doing it at all? Are you just trying to see what is happening when you run your service? Seems like you could just use logging to determine what is happening instead of having to run the exe as local system.

Using Secure Desktop to run cmd.exe as system

We can get kernel access through CMD in Windows XP/Vista/7/8.1 easily by attaching a debugger:

Run CMD as Administrator

Then use this command in Elevated:

Then run osk (onscreenkeyboard). It still does not run with system Integrity level if you check through process explorer, but if you can use OSK in service session, it will run as NT Authority\SYSTEM

so I had the idea you have to run it on Secure Desktop.

Start any file as Administrator. When UAC prompts appear, just press Win + U and start OSK and it will start CMD instead. Then in the elevated prompt, type whoami and you will get NT Authority\System . After that, you can start Explorer from the system command shell and use the System profile, but you are somewhat limited what you can do on the network through SYSTEM privileges for security reasons. I will add more explanation later as I discovered it a year ago.

The difference between the ‘Local System’ account and the ‘Network Service’ account?

I have written a Windows service that spawns a separate process. This process creates a COM object. If the service runs under the ‘Local System’ account everything works fine, but if the service runs under the ‘Network Service’ account, the external process starts up but it fails to create the COM object. The error returned from the COM object creation is not a standard COM error (I think it’s specific to the COM object being created).

So, how do I determine how the two accounts, ‘Local System’ and ‘Network Service’ differ? These built-in accounts seem very mysterious and nobody seems to know much about them.

1 Answer 1

Since there is so much confusion about functionality of standard service accounts, I’ll try to give a quick run down.

First the actual accounts:

A limited service account that is very similar to Network Service and meant to run standard least-privileged services. However, unlike Network Service it accesses the network as an Anonymous user.

• Name: NT AUTHORITY\LocalService
• the account has no password (any password information you provide is ignored)
• HKCU represents the LocalService user account
• has minimal privileges on the local computer
• presents anonymous credentials on the network
• SID: S-1-5-19
• has its own profile under the HKEY_USERS registry key ( HKEY_USERS\S-1-5-19 )

Limited service account that is meant to run standard privileged services. This account is far more limited than Local System (or even Administrator) but still has the right to access the network as the machine (see caveat above).

• NT AUTHORITY\NetworkService
• the account has no password (any password information you provide is ignored)
• HKCU represents the NetworkService user account
• has minimal privileges on the local computer
• presents the computer’s credentials (e.g. MANGO$ ) to remote servers
• SID: S-1-5-20
• has its own profile under the HKEY_USERS registry key ( HKEY_USERS\S-1-5-20 )
• If trying to schedule a task using it, enter NETWORK SERVICE into the Select User or Group dialog

Completely trusted account, more so than the administrator account. There is nothing on a single box that this account cannot do, and it has the right to access the network as the machine (this requires Active Directory and granting the machine account permissions to something)

• Name: .\LocalSystem (can also use LocalSystem or ComputerName\LocalSystem )
• the account has no password (any password information you provide is ignored)
• SID: S-1-5-18
• does not have any profile of its own ( HKCU represents the default user)
• has extensive privileges on the local computer
• presents the computer’s credentials (e.g. MANGO$ ) to remote servers

Above when talking about accessing the network, this refers solely to SPNEGO (Negotiate), NTLM and Kerberos and not to any other authentication mechanism. For example, processing running as LocalService can still access the internet.

The general issue with running as a standard out of the box account is that if you modify any of the default permissions you’re expanding the set of things everything running as that account can do. So if you grant DBO to a database, not only can your service running as Local Service or Network Service access that database but everything else running as those accounts can too. If every developer does this the computer will have a service account that has permissions to do practically anything (more specifically the superset of all of the different additional privileges granted to that account).

It is always preferable from a security perspective to run as your own service account that has precisely the permissions you need to do what your service does and nothing else. However, the cost of this approach is setting up your service account, and managing the password. It’s a balancing act that each application needs to manage.

In your specific case, the issue that you are probably seeing is that the the DCOM or COM+ activation is limited to a given set of accounts. In Windows XP SP2, Windows Server 2003, and above the Activation permission was restricted significantly. You should use the Component Services MMC snapin to examine your specific COM object and see the activation permissions. If you’re not accessing anything on the network as the machine account you should seriously consider using Local Service (not Local System which is basically the operating system).

• NT_AUTHORITY\LocalService (aka the Local Service account), or
• NT AUTHORITY\NetworkService (aka the Network Service account).

That capability only was added with Task Scheduler 2.0, which only exists in Windows Vista/Windows Server 2008 and newer.

A service running as NetworkService presents the machine credentials on the network. This means that if your computer was called mango , it would present as the machine account MANGO$ :

How to Run a Program as SYSTEM (LocalSystem) Account in Windows

Many Windows system files, registry keys, and services are owned by the SYSTEM (a.k.a LocalSystem) account, which has a high privilege level. If you need to modify a registry key owned by the SYSTEM account, there are at least two options.

The first option that comes to your mind is to take ownership of the corresponding registry key, assign yourself Full Control permissions. Once the registry key or the values are updated, revert the permissions and ownership to SYSTEM .

There is, however, an easier option. You can run the program — e.g., the Command Prompt or the Registry Editor under the SYSTEM account directly and update the registry values.

This article lists six different methods using which you can run programs under the SYSTEM or LocalSystem account in any version of Windows, including Windows 10. You can also add a Run as SYSTEM right-click menu option for .exe files.

Method to run a program under the SYSTEM account:

Before proceeding, understand that the terms SYSTEM , LocalSystem , and NT AUTHORITY\SYSTEM are one and the same.

How to Run Programs as SYSTEM (LocalSystem account)

To run a program under the SYSTEM account, use one of the following tools:

Using PsExec.exe from Windows Sysinternals

Use PsExec.exe console tool from Microsoft’s Windows Sysinternals to run a program under the SYSTEM context. Follow these instructions:

1. Download PsExec from Microsoft Sysinternals.
2. Unzip and extract the tool to a permanent folder — e.g., d:\tools
3. Open an elevated or admin Command Prompt window.
4. To start the Registry Editor under the SYSTEM account, type the following command, and press ENTER :

The above PsExec command-line starts the Registry Editor under LOCALSYSTEM account so that you can modify protected areas in the registry.

Note: If you launch Command Prompt ( cmd.exe ) using PsExec.exe under the SYSTEM account, it spawns a new Command Prompt window. And, any program you launch from that Command Prompt window would run under the SYSTEM (LocalSystem) account, which is a high privileged account. You must be cautious when running programs under the SYSTEM account so that you don’t accidentally run an undesired program as SYSTEM .

Using Advanced Run from Nirsoft

AdvancedRun is a simple tool for Windows that allows you to run a program with different settings that you choose, including – low or high priority, start directory, main window state (Minimized/Maximized), run the program with different user or permissions, Operating system compatibility settings, and environment variables. You can also save the desired settings into a configuration file and then run the program automatically from the command-line with the desired settings.

Using Advanced Run, you also launch a program under SYSTEM or a different user context.

Type in the program name to run and choose SYSTEM user in the Run As dropdown box, and click Run.

You can also create a desktop shortcut to run a program as SYSTEM. Here is the command-line syntax you use:

/RunAs 4 instructs to start the program under the LocalSystem account. The possible value data for the /RunAs switch are below:

• 1 – Run as current user (elevate)
• 2 – Run as current user (no elevation)
• 3 – Run as Administrator (force elevation)
• 4 – Run as SYSTEM
• 8 – Run as TrustedInstaller

This starts the program under the LocalSystem account, which you can verify in the Task Manager Details tab.

Run as SYSTEM via the right-click menu

To launch a program under the SYSTEM account (with Advanced Run) from the right-click context menu, make a .reg file from the following contents and run the file.

Change the path to AdvancedRun.exe in the .reg file if necessary.

This adds the Run as SYSTEM command to the right-click menu for .exe files and its shortcuts.

Using Process Hacker

Process Hacker is an excellent process manager that looks similar to Sysinternals Process Explorer. This tool has a unique feature that allows you to launch a program under the same account as a running process or service.

1. Run Process Hacker as administrator.
2. Locate a program or service which is currently running under NT AUTHORITY\SYSTEM .
3. Right-click on the process, click Miscellaneous, and click Run as this user…

Select the program (e.g., regedit.exe, or cmd.exe) you want to launch as that user.

Click OK.

Now the program (e.g., cmd.exe) would run as SYSTEM ( NT AUTHORITY\SYSTEM )

The above method can also be used to launch any program under TrustedInstaller.

Using NirCmd.exe from NirSoft

NirCmd is a multipurpose command-line tool which we’ve covered in this site before.

NirCmd can start a program elevated as well as launch it under the SYSTEM account.

Use this command-line to start the Registry Editor elevated and under the SYSTEM account:

Context menu implementation

Make a .reg file from the following contents and run the file.

Using RunAsSystem from Uwe Sieber

RunAsSystem (from Uwe Sieber) is a console tool that launches a program under the SYSTEM account or context. It also passes the window style and its process priority to the executed process by default. You can override the window size as well as the child process priority using command-line arguments. Uwe Sieber is the one who developed the famous USB Drive Letter Manager program.

It waits for the started process to end and then passes back its return code (aka errorlevel). However, in a batch file, you have to add start /wait .

Usage:

Examples:

Context menu implementation

Make a .reg file from the following contents and run the file.

The above .reg file adds a Run as SYSTEM command in the right-click menu for .exe files. The .reg file assumes that the file RunAsSystem.exe is placed under the d:\tools folder. If not, alter the path accordingly in the .reg file.

Using “NSudo” from M2Team

NSudo (GitHub) is a similar portable utility like Advanced Run, except that it is not digitally signed. It can launch programs under SYSTEM, Current User, Current Process, or the TrustedInstaller account. We’ve earlier seen how to use NSudo to launch programs as TrustedInstaller.

Select the mode (System) from the dropdown, type in the executable path, and click Run.

Optionally, you can also add a predefined set of programs or commands in the Open: drop-down list box by editing the file named NSudo.json located in the same folder as the executable.

To run a program under the SYSTEM context using NSudo command-line, use this syntax:

See below for the full list of command-line arguments supported by this utility.

NSudo: Command-line support

Context menu addition

• Run NSudo with -Install parameter. It copies NSudo to the Windows directory and adds the context menu.
• To remove the context menu, run NSudo with the -Uninstall parameter. It removes NSudo from the Windows directory and the context menu.

Editor’s Pick: Advanced Run for GUI (and CLI), and PsExec for CLI.

One small request: If you liked this post, please share this?

About the author

Ramesh Srinivasan founded Winhelponline.com back in 2005. He is passionate about Microsoft technologies and he has been a Microsoft Most Valuable Professional (MVP) for 10 consecutive years from 2003 to 2012.

Microsoft → Windows → How to Run a Program as SYSTEM (LocalSystem) Account in Windows

2 thoughts on “How to Run a Program as SYSTEM (LocalSystem) Account in Windows”

This is a really useful article and information. Thank you for that!

I use this feature at the login screen by renaming a few files while Windows is offline. While this is a handy feature for technicians like myself, shouldn’t this be a security issue that Microsoft addresses?

Читайте также:  Linux как посмотреть видеодрайвер