Windows LocalSystem vs. System

Solution 1:

[wiped large answer, summarizing for clarity. See edit-history for sordid tale.]

There is a single well-known SID for the local system. It is S-1-5-18, as you found from that KB article. This SID returns multiple names when asked to be dereferenced. The 'cacls' command-line command (XP) shows this as "NT Authority\SYSTEM". The 'icacls' command-line command (Vista/Win7) also shows this as "NT Authority\SYSTEM". The GUI tools in Windows Explorer show this as "SYSTEM". When you're configuring a Service to run, this is shown as "Local System".

Three names, one SID.

In Workgroups, the SID only has a meaning on the local workstation. When accessing another workstation, the SID is not transferred just the name. The 'Local System' can not access any other systems.

In Domains, the Relative ID is what allows the Machine Account access to resources not local to that one machine. This is the ID stored in Active Directory, and is used as a security principle by all domain-connected machines. This ID is not S-1-5-18. It is in the form of S-1-5-21[domainSID]-[random].

Configuring a service as "Local Service" tells the service to log on locally to the workstation as S-1-5-18. It will not have any Domain credentials of any kind.

Configuring a service as "Network Service" or "NT Authority\NetworkService" tells the service to log on to the domain as that machine's domain account, and will have access to Domain resources. The Windows XP Service Configurator does not have the ability to select "Network Service" as a login type. The SQL Setup program might.

"Network Service" can do everything "Local System" can, as well as access Domain resources.

"Network Service" has no meaning in a Workgroup context.

In short:

NT Authority\System = Local System = SYSTEM = S-1-5-18

If you need your service to access resources not located on that machine, you need to either:

• Configure it as a Service using a dedicated login user
• Configure it as a Service using "Network Service" and belong to a domain

Solution 2:

"Most services run in the security context of the local system account (displayed sometimes as SYSTEM and other times as LocalSystem)."

"...The local system account is the same account in which core Windows user-mode operating system components run, including the Session Manager (smss.exe), the Windows subsystem process (csrss.exe), the Local Security Authority process (lsass.exe), and the Logon process (winlogon.exe)."

"...From a security perspective, the local system account is extremely powerful - more powerful than any domain or local account."

-- Windows Internals, 5th Edition (page 288 - 289).

Note that if you configure a service to logon as .\LocalSystem, it will still appear as logged on as NT AUTHORITY\SYSTEM in Process Explorer or System in Task Manager.

In Windows 7 a service set to Log on as: "Local System" account has the User Name "SYSTEM" in the Task Manager Processes tab.