[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
Is the user in the administrators group on the Windows 7 box? Can you try removing the user from the admin group? Or temporarily disable the UAC and see if things work.
There are some cases where the UAC will interfere with login scripts.
See the section 'Group Policy Scripts can fail due to User Account Control' on this page. http://technet.microsoft.com/en-us/library/cc766208(WS.10).aspx
Best Answer
I found the answer in the Apache documentation. Duh.