Is client LocalSystem (SYSTEM) identified by target/server machine? and in which context?

Question

[1] tells:

• "When you configure to use a particular account as the process identity, ASP.NET attempts to delegate that account. If it is a local account that is identical (including password) to a local account on a remote machine, delegation is possible. If such an account does not exist on the remote machine, to the network it appears as the Windows anonymous account (NT AUTHORITY\ANONYMOUS LOGON). In addition, delegation is also possible if the account is a domain account that has access to the remote machine, in which case it uses the domain network identity of that account."

[2] informs:

• "The name of the account in all locales is .\LocalSystem. The name, LocalSystem or ComputerName\LocalSystem can also be used"
  • "The service presents the computer's credentials to remote servers

Also, the predefined "NT AUTHORITY\LOCAL SYSTEM" (or SYSTEM [3]) is present in any Windowses
and should have been usable for identification (even when client (process) accessed from workgroup Windows), shouldn't have?

Though, a row of answers, for ex., [3] tells the opposite:

• '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'

Is LocalSystem identified or not by remote/target machine? and how?

• as ComputerName\LocalSystem ?
  or
• as NT AUHORITY\LOCAL SYTEM ?

Update:
This question is completely inside the context of development environment in Windows workgroup...
though all answers deviated to Windows domain...

---

CITED:
[1]
ASP.NET Delegation
http://msdn.microsoft.com/en-us/library/aa291350.aspx
[2]
LocalSystem Account
http://msdn.microsoft.com/en-us/library/ms684190.aspx
[3]
sysadmin1138's answer to my question "Windows LocalSystem vs. System"
http://serverfault.com/questions/168752/windows-localsystem-vs-system

---

My related questions:

• domained LocalSystem vs. non-domained LocalSystem account in Windows-es ?
• how to check group membership of an “NT AUTHORITY\” account ?
• Does access to server resources require client process to login to server machine?
• Windows workgroup LocalSystem vs. domain (AD) LocalSystem [closed]
• how to better set up machine for development both in workgroup and Windows domain? [closed]
• interoperating with Windows domain computer from workrgroup Windows [closed]
• the context of local user of AD-joined machine? Is it of domain machine account or of local machine account?
• RunAs under domain account from non-AD Windows [closed]
• how to better set up machine for development both in workgroup and Windows domain? [closed]
• how to share the same domain machine account with multi-boot workgroup Windows setup?

Answer 1

There are two possibilities in your scenario, depending on the version of Windows on the local ("client") machine and on how well the service integrates with the Windows services APIs: - remote machines will see requests from the "client" machine as NT AUTHORITY\ANONYMOUS - remote machines will see requests from the "client" machine as DOMAIN\COMPUTER_ACCOUNT_NAME

A remote machine will only see requests from its own processes as coming from SYSTEM/LocalSystem.

If you want to find out through testing which account context you're seeing due to remote requests, enable Audit Logon Events (Success and Failure) in Audit Policy on the remote system. You can also find complementary (and sometimes helpful) information by using a protocol analyser like Microsoft Network Monitor, and capture the packet stream sent from "client" to remote machine and back.

Edit: also see my answer to the related/overlapping question here for related details.

Answer 2

System/LocalSystem and NETWORK SERVICE as well will all authenticate remotely as the computer account, DOMAIN\MACHINENAME$. There is a another built in account, the LOCAL SERVICE which will always authenticate remotely as ANONYMOUS LOGON (therefore failing most authorizations).

Trying to understand these concepts as SIDs and names has not much meaning. Authentication is an SSPI handshake at the end of which the authenticator will query the context token of the authenticatee and validate access (perform authorization), and the name of the authenticatee can also be queried from the security context. If the SSPI handhsake was remote (between two distinct LSAs) then the name QueryContextAttributes would return, in a successful authentication scenario, the remote machine name domain\machine$. If it was a loop-back handshake where only one LSA is involved, then the same call will return NETWORK SERVICE or System. There is also the posibility of the handshake authenticating 'ANONYMOUS LOGON', like the Workgroup case, use of a local account, or attempt to cross domain trust boundaries, but basically there are all failed authentication.