Choosing a Windows Service Account — LocalSystem, Virtual Accounts, and gMSA

“A service running as LocalSystem was flagged in an audit as having excessive privileges. What should we change it to?” “We use a domain user so the service can connect to a shared folder, but the service stops when the password expires.” — These two are the typical consultations that arise when a service’s logon account is not a design decision but has been frozen as “the setting that worked”.

When choosing the logon account, think separately about what the service can do inside the PC, who it appears as to the systems it connects to, and who manages the password. Making local privileges stronger and being able to authenticate and connect to a shared folder are not the same thing.¹²

The conclusion of this article is to make a virtual account the first candidate for a business service that stays within a single machine, and a gMSA the first candidate when a service-specific identity is needed inside a domain. Start from a configuration in which “the service does not hold a human-style password”, and treat domain users as the last resort. That said, do not change every existing service immediately across the board; check the privileges it needs and the impact of the migration.³⁴

The intended readers are IT staff at small and medium-sized businesses and Windows application developers. The explanation, based on Microsoft Learn as of August 2026 when the original article was written, is organized in the order selection → local privileges → network identity → gMSA deployment → switching and auditing. For how to build a service itself, see “How to Build and Operate Windows Services”.

1. Choose First: Six Accounts and Four Questions

1.1 The Axes of Comparison Are Privileges, Identity, and Password Management

When a service starts, the Service Control Manager (SCM) logs on with the configured account. On success it assigns an access token to the service process, and from then on every access to files and pipes is decided by matching that token against the access control list (ACL). Choosing the logon account means deciding the contents of the token handed to the service.¹

Network authentication as PC$ in the table assumes a domain environment. The same method is not available in a workgroup. LocalSystem also has limits such as WRP-protected areas. Do not take “almost unlimited” as literally unlimited.⁵⁶²⁷

With LocalSystem, LocalService, NetworkService, and virtual accounts, the user does not need to set or manage a password for the service. In a configuration that uses a domain user or a local user, by contrast, a person manages the expiry and changes of the password stored in the SCM. A gMSA does have a password, but its management is delegated to AD.¹⁸

1.2 Work Through the Selection with Four Questions

First confirm whether the service connects to other machines with Windows authentication, and if so, decide in order whether the machine is domain-joined, whether a per-machine identity is enough, and whether the application supports gMSA.

flowchart TB
    accTitle: Decision flow for the logon account
    accDescr: Decide the logon account by answering four questions in order, whether there is network access, whether the machine is domain-joined, whether a per-machine identity is enough, and whether the app supports gMSA
    q1{"Connect to other machines with Windows auth?"} -->|No| va["Virtual account"]
    va -.-> sys["LocalSystem if privileges are required"]
    q1 -->|Yes| q2{"Domain-joined?"}
    q2 -->|No| cred["Protect and store credentials"]
    q2 -->|Yes| q3{"Per-machine identity enough?"}
    q3 -->|Yes| pcacl["Virtual account + PC$ permission"]
    q3 -->|No| q4{"App supports gMSA?"}
    q4 -->|Yes| gmsa["gMSA"]
    q4 -->|No| du["Dedicated user + mitigations"]

Figure 1: If everything stays local, use a virtual account. Inside a domain, when PC$ is not fine-grained enough, move on to a gMSA. In a workgroup, design the credentials separately.

There is no need to replace, without reason, every existing LocalService-based local job or NetworkService-based per-machine access. For a new choice, make the virtual account the baseline, since it combines low privileges with per-service isolation.

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (19 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

2. Decide the Privileges Inside the PC: Make Virtual Accounts the Baseline

2.1 LocalService and NetworkService Differ in Their Network Identity

LocalService and NetworkService are built-in accounts for low-privilege services. Locally, both run with roughly the minimal privileges of a member of the Users group. What differs is the credentials they present to remote systems.⁶³

The split is: LocalService if the service does not go out on the network or is never asked for an identity, and NetworkService if it needs the machine’s identity inside a domain.

Note, however, that with both, several services share the same account. As long as ACLs are granted to that shared account, the services cannot be told apart. If five services run as LocalService, all five can reach any resource permitted to that account. The reason SQL Server does not support Local Service is the same: a shared account cannot be isolated from other services.³

2.2 With a Virtual Account, ACLs Can Be Granted per Service

A virtual account is a managed local account available on Windows Server 2008 R2 / Windows 7 and later. Its name is NT SERVICE\<service name>. No account creation or password setup is required, and each service has its own unique identity. For network access in a domain environment, it uses the computer account’s credentials.²

It keeps the “no password management” advantage of LocalService and NetworkService while removing the weakness of sharing an account. SQL Server Setup using NT SERVICE\MSSQLSERVER and the like by default follows the same reasoning.³

The practical benefit is that the service can be named directly in an ACL. Without adding group creation or password management, you can configure “grant Modify on this data folder to this service”.

The following example switches an existing MyAppService to a virtual account. Before running it, check the logon right, data placement, and DPAPI covered in Chapter 7, and confirm startup and the main functions in a test environment.

# Change the service's logon account to a virtual account
# The obj= value is "NT SERVICE\service-name". Do not specify a password
sc.exe config MyAppService obj= "NT SERVICE\MyAppService"

# Check the configuration (look at SERVICE_START_NAME)
sc.exe qc MyAppService

# Grant Modify on the data folder to this service only
icacls "C:\ProgramData\MyApp" /grant "NT SERVICE\MyAppService:(OI)(CI)M"

In the GUI, open the service’s properties in services.msc, go to the Log On tab, set the account name to NT SERVICE\service-name, and leave the password fields empty. No password is specified for virtual accounts or MSAs. The change takes effect when the service restarts.³

Having a unique identity locally does not guarantee that services can be distinguished on the far side of the network. Chapter 3 explains this limitation.

2.3 Judge LocalSystem by the Privileges Required, Not by “It Works”

LocalSystem (NT AUTHORITY\SYSTEM, displayed as Local System) is a predefined account used by the SCM. Its token contains the SIDs NT AUTHORITY\SYSTEM and BUILTIN\Administrators, and it has extensive local privileges. Strong privileges such as SeDebugPrivilege and SeTcbPrivilege are enabled by default.⁵

That strength is also the size of the damage when it is compromised. If a LocalSystem service has an arbitrary code execution vulnerability, it can become the starting point for reading and tampering with every user’s files, reading other processes’ memory, stealing credentials, and lateral movement. On NTFS, SYSTEM has Full Control by default.⁶ The relationship between credential theft and lateral movement is also covered in “NTLM and Kerberos Explained with Diagrams” and “A Practical Guide to Windows LAPS”.

LocalSystem nonetheless keeps getting chosen because it is the default when obj= is omitted in sc.exe create, and because it remains in many old samples and installer templates. Permission errors rarely appear during development, so the reflex is to leave it as is “because it worked”. Microsoft, however, explains that most services do not need this privilege level, and that LocalService or NetworkService should be considered when it is not required.⁹⁵

Even LocalSystem cannot change everything unconditionally. Since Windows Vista, Windows Resource Protection (WRP) restricts changes to critical system files, folders, and registry keys to TrustedInstaller (the Windows Modules Installer service). Even SYSTEM and administrators get access denied on an ordinary write. The message “You require permission from TrustedInstaller” comes from this mechanism.⁷

Even with that restriction, LocalSystem still holds far more privilege than a business service needs. The legitimate exceptions are processing whose required privileges exceed administrator level in the first place: tight integration with device drivers, manipulating the OS security foundation, managing other services and sessions, and so on. For backup agents, EDR, and the like, that necessity is the question.

Even when a service falls under an exception, check whether a code path actually uses the privilege, and whether just that part can be isolated. For how to tell, see “When Do You Actually Need Administrator Privileges on Windows?”.

3. Decide the Identity Seen by the Target: Is PC$ Enough?

3.1 If All You Need Is a Shared Folder Connection, a Domain User Is Often Unnecessary

On a domain-joined machine, a service using LocalSystem, NetworkService, or a virtual account authenticates to remote systems as DOMAIN\computer-name$. Sometimes the only reason a service cannot access a shared folder is that this PC$ is not permitted in the target’s ACL.⁵²

What is needed here is not stronger local privileges for the service, but permitting the correct identity on the target. For a shared folder, set both the share permissions and the NTFS permissions.

The following example, run on the file server, grants Modify to the service on APPSV01. When selecting the account in the GUI, include Computers in Object Types.

# On the file server: grant the service on APPSV01 Modify on the shared folder
# Both the share permissions and the NTFS permissions must be granted
Grant-SmbShareAccess -Name "AppData" -AccountName "CORP\APPSV01$" -AccessRight Change -Force
icacls "D:\Shares\AppData" /grant "CORP\APPSV01$:(OI)(CI)M"

For SQL Server, the idea of registering the computer account as a Windows login is the same. Use Integrated Security=true in the connection string and connect without the service holding a domain user’s password.

-- On the DB server: allow Windows integrated authentication from the service on APPSV01
CREATE LOGIN [CORP\APPSV01$] FROM WINDOWS;

This is the part where the Windows login is created on the DB server. The principle of granting the required permissions on the target is no different from the shared folder.

3.2 PC$ Cannot Authorize or Audit per Service

A virtual account’s identity is local to the machine and is not recognized by the domain. Once it goes out on the network it is folded into PC$, so which service on the same machine the request came from cannot be distinguished by the account alone.¹⁰⁴

flowchart TB
    accTitle: A virtual account's identity collapses outside the machine
    accDescr: Virtual accounts that are unique per service inside the machine collapse to the computer account on the network, so the remote side cannot tell which service it is
    vaa["Virtual account A"] --> pc["Computer account PC$"]
    vab["Virtual account B"] --> pc
    pc --> remote["Identity seen by the remote side"]
    remote -.-> nodist["Cannot tell which service"]

Figure 2: Even when services are separated inside the PC, the target sees the same PC$. Local isolation and network isolation are separate decisions.

This approach has two limits.

Sharing the same identity across several servers is also beyond what a per-machine PC$ or virtual account can do. Once a service-specific identity, or one shared across several servers, is needed inside a domain, consider a gMSA before a domain user — that is this article’s policy. A gMSA cannot be used in a workgroup either.

4. The Role of gMSA: A Unique Identity with Password Management Delegated to AD

4.1 Separate Password Generation, Distribution, and Renewal from Humans

A gMSA (group Managed Service Account) is a domain account whose password management is delegated to the domain controllers. The domain controller computes the password from the Key Distribution Service (KDS) root key, and only permitted hosts retrieve it and use it for their services.⁸

flowchart TB
    accTitle: How gMSA password management works
    accDescr: The domain controller computes the password from the KDS root key, only permitted hosts retrieve it and use it to run services, and the password rotates automatically every 30 days by default
    kds["KDS root key"] --> dc["DC computes the password"]
    dc --> host["Permitted host retrieves it"]
    host --> svc["Used to run the service"]
    dc -.-> rot["Automatic rotation every 30 days by default"]

Figure 3: Without any human knowing the password, permitted hosts retrieve it and the service runs on credentials that are renewed automatically.

These are the reasons to prefer a gMSA over a manually managed domain user.¹¹ Where Windows LAPS automates the management of local administrator passwords, a gMSA takes care of service account passwords; seeing it that way makes its position easier to understand. The two mechanisms target different things.

4.2 Do Not Skip Checking Application Support

gMSAs are broadly supported by anything that configures a logon identity through the standard mechanisms: Windows services, IIS application pools, Task Scheduler, and so on. But not every application can use them. Software built to prompt for a password internally cannot, and there are constraints such as failover clustering itself not supporting gMSA.¹⁰

Once a gMSA is a candidate, confirm in a test environment before production that the service starts as the gMSA and that it can access the resources it needs. Microsoft also requires this step.¹¹

Related options include the sMSA (standalone Managed Service Account) for a single server and the dMSA (delegated Managed Service Account) introduced in Windows Server 2025. A dMSA binds authentication to device identity to counter credential theft. For new configurations, start from gMSA and consider these as the requirements dictate.²

5. Deploying a gMSA: From Prerequisite Checks to Service Configuration

5.1 Requirements to Confirm First

The gMSA name and change interval are also decided before deployment. Thinking about them after the account is created means recreating it.¹⁰

5.2 Check for the KDS Root Key and Create One If Missing

Creating the KDS root key is a one-time task per forest. Check for an existing key first, and add one only if none exists.

# Run as a domain administrator on a domain controller (or on a management
# workstation with the AD PowerShell module installed)

# Check whether a KDS root key exists and create one if not (once per forest)
Get-KdsRootKey
Add-KdsRootKey -EffectiveImmediately   # Actually usable up to 10 hours later

Even with -EffectiveImmediately, the key is not necessarily usable right after creation. To wait for replication to all domain controllers, there is a wait of up to 10 hours after creation, during which a gMSA cannot be created. This prevents the failure of proceeding to password retrieval while replication is still incomplete. Include this time in the deployment plan.¹²

5.3 Restrict the Hosts Allowed to Retrieve the Password, Then Configure the gMSA

The procedure has four steps. The first half is configuration on the AD side; the second half is work on each server that runs the service.¹⁰

Before running the next example, also configure the “Log on as a service” right from 7.1. sc.exe config succeeding and the service being able to log on are two different things.

# (1) Create a security group allowed to retrieve the password, and
#     add the computer accounts of the servers that run the service
New-ADGroup -Name "GG-SvcBatchHosts" -GroupScope Global
Add-ADGroupMember -Identity "GG-SvcBatchHosts" -Members "APPSV01$", "APPSV02$"
# Group membership is evaluated when the computer logs on, so
# restarting the target servers after adding them is the reliable way

# (2) Create the gMSA
New-ADServiceAccount -Name "svc-batch" `
    -DNSHostName "svc-batch.corp.example.com" `
    -PrincipalsAllowedToRetrieveManagedPassword "GG-SvcBatchHosts"

# (3) On each server that runs the service, install and verify the gMSA
Install-ADServiceAccount -Identity "svc-batch"
Test-ADServiceAccount -Identity "svc-batch"   # True means the password can be retrieved

# (4) Set it as the service's logon account. Append $ to the name and do not specify a password
sc.exe config MyBatchService obj= "CORP\svc-batch$"
Restart-Service MyBatchService

In services.msc as well, enter the account name with a trailing $, such as CORP\svc-batch$, and leave the password fields empty. MSA-type accounts cannot be used for interactive sign-in.³

On the target shared folder or SQL Server, grant the required permissions to CORP\svc-batch$ instead of PC$. The result is a configuration in which no person manages a password and the service accesses the network with its own identity. Do not stop at the retrieval check with Test-ADServiceAccount; verify the service’s main functions for real.

6. Domain Users Are the Last Resort: If You Use One, Put the Mitigations in Place

6.1 Avoiding Expiry Locks In a Different Risk

When a domain user or local user is assigned to a service, the SCM stores the password and uses it to log on at every start. But the SCM does not manage expiry. If the stored password expires, the logon fails and the service no longer starts.¹

From there a vicious cycle begins: to prevent expiry failures the password is set to never expire, the same password is left in plaintext in runbooks, scripts, and tasks on several servers, and finally nobody can change it even after an employee leaves, because “nobody knows what will stop if we change it”.

Microsoft also points out that using a domain account for a service costs operational effort in manually managing the password and SPN, and that maintenance can cause service outages. Setting the password to never expire alone does not solve the management problem.³

6.2 An Account with an SPN Is Also a Kerberoasting Target

A service that accepts Kerberos authentication registers an SPN (service principal name) on its logon account. Any authenticated user in the domain can request a service ticket for it, so an attacker obtains the ticket and tries to brute-force the password offline; that is Kerberoasting.

The countermeasure is to use a long, randomly generated password rather than relying on a human-chosen password of roughly 10 to 16 characters. Microsoft likewise cites enforcing long passwords and gMSAs, which use long machine-generated random values.¹³

Kerberos armoring (FAST), mentioned in the same document, protects pre-authentication data and provides resistance to KDC spoofing. It does not prevent authenticated users from requesting service tickets for an SPN, and it is no substitute for the strength of the service account’s password. For SPNs, Kerberos, and the conditions under which authentication falls back to NTLM, see “NTLM and Kerberos Explained with Diagrams”.

6.3 For Unsupported Apps, Pair a Dedicated Account with Operating Procedures

When a dedicated domain user is unavoidable, for example because the application does not support gMSA, apply all of the following mitigations.

Separating the service’s identity from human accounts is also an important principle.⁴ Moving the services that support it to a gMSA is safer and lighter to operate than having people keep up this management; that is why gMSA is preferred.

7. Switching and Auditing: Do Not Stop at Changing the Account Name

7.1 Check the “Log on as a service” Right

To start as a service, the account needs SeServiceLogonRight (Log on as a service). LocalSystem, LocalService, and NetworkService have it built in, but when running under any other account, check that this right has been assigned.¹⁴

State explicitly in the deployment procedure how the right is configured, whether in Local Security Policy (secpol.msc) or via GPO or Intune. Not relying on a tool’s side effect is important. For service-only accounts, also combine this with denying interactive logon.

7.2 Check Data Under the Profile, and the ACLs

When a service starts, the SCM loads that account’s user profile. Consequently the actual %TEMP%, %APPDATA%, and HKEY_CURRENT_USER differ per account. When settings or caches appear to have “vanished” after the switch, it is because the service is looking at a profile different from the old account’s.¹

The remedy is to place the service’s data at an explicit path such as C:\ProgramData\<app name> and grant the logon account an ACL on it. Once the data is detached from the per-account profile, the next account change no longer requires relocating the storage. For data already stored under a profile, include its migration in the switching plan.

Check permissions not only on the required folders but also on the registry and elsewhere. After changing the account to a low-privilege one, verify that processing that assumed the old LocalSystem privileges does not fail.

7.3 DPAPI-Protected Data Cannot Be Carried Over Just by Moving Files

Data protected with user-scope DPAPI (CryptProtectData, .NET’s ProtectedData, and so on) can, as a rule, be decrypted only by the same account that protected it. Change the logon account and the stored connection strings and API keys become unreadable.

For that reason, separately from migrating profile files, prepare a procedure for re-entering secrets after the switch. Even though this is DPAPI protecting the data as intended, it becomes a service outage if nobody prepared for it. For how to design the storage, see “Storing Secrets in Windows Apps”.

If the connection can be handled by Windows integrated authentication with a gMSA or PC$, the secret storage itself can be eliminated. The order is to ask “can we avoid storing it?” before “where do we store it?”.

Also, when you want to “process with the calling user’s privileges”, consider impersonation rather than strengthening the service’s logon account. This is explained in “Handling Windows Impersonation Tokens Correctly”.

7.4 Take Inventory from the Service List, and Confirm the Startup Identity in the Log

For the initial inventory, tally the logon accounts in the service list. The following example shows the count per account, and the LocalSystem services whose path is outside the Windows folder.

# Tally which services run under which account
Get-CimInstance Win32_Service |
    Group-Object StartName |
    Sort-Object Count -Descending |
    Select-Object Count, Name

# Find non-standard services running as LocalSystem (use the path to tell in-house and third-party services from built-in ones)
Get-CimInstance Win32_Service |
    Where-Object { $_.StartName -eq 'LocalSystem' -and $_.PathName -notlike '*\Windows\*' } |
    Select-Object Name, DisplayName, PathName

If a business service is running as LocalSystem or a domain user, return to the decision in Chapter 1 and confirm the privileges it needs and the identity the target requires. Use the path-based filter as a hint for finding candidates, and decide based on what the service actually does and processes.

Service startup can be confirmed in the Security event log with event ID 4624, logon type 5 (Service). This represents the logon performed by the SCM to start a service. The Virtual Account field indicates whether the logon was by an MSA or a virtual account, so it can also be used to monitor the use of managed accounts.¹⁵

7.5 A Summary of Checks Before Switching Production

Whether moving away from LocalSystem or deploying a gMSA, finish these checks before switching production. The key to the migration is to confirm least privilege and the continued operation of the required functions together.

8. Summary

When selecting a service account, think separately about local privileges, network identity, and password management. LocalSystem being the default is no reason to use it. For ordinary business services, make virtual accounts the baseline and grant the ACLs they need. Consider LocalSystem only when strong privileges are truly required.⁵³

If a per-machine identity is enough for the targets inside the domain, a virtual account or similar plus a PC$ permission may suffice. If a service-specific identity, or one common to several servers, is needed, choose a gMSA and delegate password management to AD. In a workgroup neither PC$ nor gMSA is available, and a different design that handles credentials is required.²¹⁰

When a domain user is necessary, put a dedicated account, a long random password, logon restrictions, least privilege, rotation, and a register all in place. When switching, check not only the account name but also the logon right, the profile, and DPAPI.

The question to ask the next time you configure a service is “as whom, and how far, should this service be able to access?” Choose the account to match that answer, and do not leave it frozen as “the setting that worked”.

Related Articles

• How to Build and Operate Windows Services — From Choosing Between Task Scheduler and Services to Turning a BackgroundService into a Windows Service
• When Do You Actually Need Administrator Privileges on Windows? — UAC, Protected Areas, and How to Tell by Design
• Handling Windows Impersonation Tokens Correctly — Borrowing Privileges per Thread and Reverting Safely
• NTLM and Kerberos Explained with Diagrams — Why Authentication Falls Back to NTLM
• A Practical Guide to Windows LAPS — Retiring the Shared Local Administrator Password Across All PCs
• Storing Secrets in Windows Apps — Avoiding Plaintext Configuration with DPAPI

Related Consulting Areas

KomuraSoft LLC handles designing the logon accounts of Windows services and resident apps and reducing them to least privilege, migrating existing services built around LocalSystem to virtual accounts or gMSAs, and investigating access-denied, DPAPI, and profile-related failures caused by account changes. It is fine to start from the stage of “the audit flagged it, but we do not know where to begin”.

• Windows App Development
• Bug Investigation & Root-Cause Analysis
• Technical Consulting & Design Review
• Contact

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

Should a service that has been running as LocalSystem "for now" be changed right away?

An immediate change is not automatically the right answer in every case. First confirm whether the service really needs LocalSystem-level local privileges (strong privileges that go beyond an administrator's). If all it does is read and write files and communicate over the network, moving it to a virtual account (NT SERVICE\service-name) is the first candidate. During the migration, check that the folders and registry keys it needs have been granted access, how data that depends on the profile or DPAPI will be handled, and whether the "Log on as a service" right is present. Confirm startup and the main functions in a test environment before switching production.

Should I choose a virtual account or NetworkService?

For a new choice, a virtual account is recommended. On the network both appear as the computer account (DOMAIN\computer-name$), and both have small local privileges. NetworkService, however, is shared by several services, so an ACL cannot express "allow only this service". A virtual account has an identity unique to each service, and NT SERVICE\service-name can be specified directly in an ACL. Recent Microsoft products such as SQL Server also default to virtual accounts.

Can a gMSA be used in a workgroup environment (no domain)?

No. A gMSA is a mechanism in which Active Directory domain controllers generate and manage the password, so a domain and a created KDS root key are prerequisites. In a workgroup environment, the basic approach is to complete local processing with a virtual account or LocalService/NetworkService. If access to another machine is required, a different design is needed, such as explicitly using the credentials of an account prepared on the target. Network access as the computer account (PC$) also only works in a domain environment.

After I changed the service's logon account, the settings and credentials it had saved can no longer be read. Why?

Because each logon account is tied to its own user profile, %TEMP%, HKEY_CURRENT_USER, and DPAPI keys. In particular, data protected at user scope with DPAPI (CryptProtectData and similar) can, as a rule, be decrypted only by the same account that protected it. Files saved under the profile (AppData and similar) also resolve to a different path for the new account. Before switching accounts, plan a procedure for recreating DPAPI-protected data (re-entering API keys and so on) and for migrating files stored under the profile.

If the service only needs to access a shared folder, do I need a domain user?

In many cases, no. In a domain environment, a service running as LocalSystem, NetworkService, or a virtual account authenticates to the remote side as the computer account (DOMAIN\computer-name$). Add that PC$ to the shared folder's share permissions and NTFS permissions and the service can read and write. If you need access control with a service-specific identity, or the same identity across several servers, consider a gMSA rather than a domain user.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.