A Windows service must run unattended and also reach a file share on another server. How do LocalSystem, LocalService, NetworkService and a virtual account differ, and how would you choose between them?
answer
- two axes, not one ladder
- local power versus remote identity
- one of them is anonymous off-box
- no password to rotate
- the machine account is who you grant
basics
~20 sLocalSystem is fully privileged locally and authenticates on the network as the computer account. NetworkService has low local privilege but the same computer-account network identity. LocalService is low privilege and anonymous on the network. A virtual account gives a per-service identity with the computer account's network access and no password to manage.
solid answer
~50 sThe choice trades local privilege against network identity. `LocalSystem` (`NT AUTHORITY\SYSTEM`) is the most privileged principal on the box, so a compromise there is a full machine compromise; on the network it presents the computer account, `DOMAIN\MACHINE$`. `NT AUTHORITY\NETWORK SERVICE` keeps that same computer-account network identity but holds roughly a normal user's local privilege. `NT AUTHORITY\LOCAL SERVICE` is equally restricted locally but authenticates anonymously off-box, so it cannot reach a domain share at all. A **virtual account**, `NT SERVICE\<ServiceName>`, is the modern default: Windows creates and manages it, there is no password to rotate or leak, it has minimal local rights, and it too presents the computer account remotely. For your case I would run as a virtual account and grant the computer account access to the share; if the share must be ACL'd to a named identity across several machines, I would use a group Managed Service Account instead so Active Directory rotates the password.
code
powershell · 9 linesGet-CimInstance Win32_Service |
Select-Object Name, StartName, StartMode, State |
Where-Object StartName -eq 'LocalSystem' |
Sort-Object Name
# Move a service to its own managed virtual account
sc.exe config MyAppSvc obj= "NT SERVICE\MyAppSvc" password= ""
sc.exe sidtype MyAppSvc unrestricted
sc.exe qc MyAppSvcgo deeper
Recognise the three built-in service accounts by name and know that LocalSystem is the powerful one while LocalService and NetworkService are limited. Know that services log on as an account rather than as a person.
Explain the two axes: local privilege versus network identity. Be precise that LocalSystem and NetworkService present the computer account remotely while LocalService is anonymous, and that ObjectName on the service key records the choice.
Show the decision procedure and the mechanics behind it — virtual accounts and per-service SIDs, granting the computer account on the far side, required-privileges trimming, and diagnosing a logon failure after an account change.
Own the identity strategy: which services may ever run as SYSTEM, how service credentials are rotated fleet-wide (gMSA versus managed secrets), and how blast radius is bounded and evidenced when a service is compromised.
## The two independent axes People answer this question badly because they think of service accounts as a single privilege ladder. There are really two axes, and the built-in accounts sit at different points on each: - **Local privilege** — what the service can do to *this* machine: which files it can touch, which privileges it holds, whether it can load drivers or impersonate. - **Network identity** — who the service appears to be when it authenticates to *another* machine. ## The built-in accounts **LocalSystem** (`NT AUTHORITY\SYSTEM`, SID `S-1-5-18`). Effectively unlimited locally: it holds the powerful privileges, it is a member of the local Administrators group's effective access on most objects, and it can act as part of the operating system. Off-box it authenticates as the computer account (`DOMAIN\MACHINE$` in a domain, anonymous in a workgroup). It is the default for many Windows services because they genuinely need kernel-adjacent access; it is the wrong default for your own code, because any remote-code-execution bug in that service is immediately SYSTEM. **NetworkService** (`NT AUTHORITY\NETWORK SERVICE`, SID `S-1-5-20`). Local privilege comparable to an ordinary user, but the same computer-account identity on the network. Historically this is what you picked for a service that needed to reach domain resources without being SYSTEM locally. **LocalService** (`NT AUTHORITY\LOCAL SERVICE`, SID `S-1-5-19`). Same restricted local footing, but presents *anonymous* credentials remotely. Ideal for a service that must never leave the machine; useless for one that must mount a domain share. **A domain or local user account.** Full flexibility — a distinct, ACL-able identity — at the cost of a password that must be set at install, stored as an LSA secret, and rotated by somebody. The rotation is where this option usually falls down in practice. ## Virtual accounts and service SIDs Since Windows 7 / Server 2008 R2, configuring a service to run as `NT SERVICE\<ServiceName>` creates a **virtual account**: managed by Windows, no password to supply or rotate, minimal local rights, and the computer account's identity on the network. It is backed by the **per-service SID** feature, which gives each service its own SID (`NT SERVICE\<name>`) that can appear in an ACL. That is the key capability: you can grant *one specific service* access to a folder, a registry key or a SQL Server login, rather than granting it to every service sharing NetworkService. `sc.exe sidtype <name> unrestricted|restricted|none` controls whether a service gets a SID, and `restricted` additionally makes the process write-restricted, so it can only write where its own SID is explicitly permitted. ## Group Managed Service Accounts When several machines run the same service and the remote resource must be ACL'd to one named identity — the classic case being a load-balanced application tier hitting SQL Server — a **group Managed Service Account** (gMSA) is the right answer. Active Directory owns the password and rotates it automatically; the machines authorised to retrieve it are listed on the object; the account name ends in `$` and is configured with no password on the service. ## Choosing, in practice Work down this order: 1. Does it need to leave the machine? If not, `LocalService` or a virtual account with a service SID. 2. Does it need to reach domain resources from one machine? A virtual account, with the **computer account** granted access on the far side. 3. Do several machines need to share one authorised identity? A gMSA. 4. Does it genuinely need SYSTEM-level local access — driver loading, arbitrary impersonation? Only then LocalSystem, and only after arguing why. Whichever you choose, reduce what it holds: `sc.exe privs <name> <privilege list>` sets the *required privileges* for a service so the SCM strips every privilege not on the list from its token at start, which is a cheap, real reduction in blast radius. ## The mechanics you will be asked about The chosen account is stored as the `ObjectName` value on the service's registry key; a user account's password is not in the registry at all but in the LSA secrets store. The account must hold the *Log on as a service* right (`SeServiceLogonRight`), which is granted automatically when you set the account through the Services MMC but must be granted explicitly when scripting. Changing the account requires a restart of the service, and the classic post-change failure is error 1069, "the service did not start due to a logon failure" — a wrong password, an expired one, or a missing logon-as-a-service right.
- You grant a share on a file server to a service running as a virtual account. Which identity do you actually put in the ACL?The client machine's computer account, `DOMAIN\MACHINE$`, because a virtual account authenticates remotely as the computer account rather than as itself. The `NT SERVICE\<name>` SID is meaningful only on the local machine. Adding the computer accounts to a security group and granting the group is the manageable form of this when several hosts are involved.
- What does making a service's SID type 'restricted' buy you?It creates a write-restricted process token: the service can only write to objects whose ACL explicitly permits its own service SID, plus a small set of allowed SIDs. Reads are unaffected. It is a strong containment measure for a service that processes untrusted input, but it breaks services that write anywhere you have not explicitly permitted, so it needs testing.
- A service fails right after you change its logon account, with error 1069. What do you check?The credential and the logon right. Error 1069 is a logon failure: a mistyped or rotated password, an account that is locked, expired or disabled, or — most often when scripting — an account that has never been granted the *Log on as a service* right. The Services MMC grants that right for you; `sc.exe config obj=` does not.
- Why is running your own service as LocalSystem considered a poor default?Because it collapses two separate failures into one. Any code-execution flaw in the service is immediately SYSTEM, and anything writable by that service becomes a path to SYSTEM. There is rarely a real requirement behind it — the usual driver is that it made a permissions problem go away during development. A virtual account plus explicit ACLs solves the same problem without the blast radius.
LocalSystem is the master key to the building that also opens the front gate; LocalService is a cleaner's key that works inside but is refused at the gate; a virtual account is a badge cut for one specific job, that the building issues and re-issues itself.
saying these in an interview costs you the question
- Says LocalService can reach a domain file share
- Thinks NetworkService is a domain account with a password
- Believes virtual accounts need a password rotated manually
- Uses LocalSystem because it is easiest and calls it fine
- Grants the share to NT SERVICE\name on the remote server