Does access to server resources require client process to login to server machine?

Question

Reposting my unanswered in technet.microsoft question?

MSDN "ASP.NET Delegation" article tells:

• 1) "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."

The same frequently repeated story as in case of manually/interactively accessing remote computer (server resource) in workgroup - it is necessary to create local account with the same username, the same password. But why?

If a workgroup Windows client process cannot access resources on server machine without having duplicate of such (local) account on target machine already pre-created, does it mean that client (process, machine, or user) can access server resources only by/after having logged (opening logon session) into server machine?

Or, how to understand that such access is impossible without having corresponding duplicate local account on server machine?

The same MSDN "ASP.NET Delegation" article tells:

• "NetworkService account. It behaves the same as the System account. This account possesses the network credentials associated with the machine account (domainname\machinename) in the domain of which it is a member"

Does not any Windows have accounts ((NT AUTHORITY\NETWORK SERVICE)?
as well as many other common pre-built accounts?
Why are they installed (before any joining to domain) but cannot be used for remote network access and client identification ?

And what is identity used when the process from workgroup Windows under identity ((NT AUTHORITY\NETWORK SERVICE) accesses a remote server?

---

My related questions:

• domained LocalSystem vs. non-domained LocalSystem account in Windows-es ?
• how to check group membership of an “NT AUTHORITY\” account ?
• Is client LocalSystem (SYSTEM) identified by target/server machine? and in which context?
• Window 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

Q1: The same frequently repeated story as in case of manually/interactively accessing remote computer (server resource) in workgroup - it is necessary to create local account with the same username, the same password. But why?

A1: Yes. See A3 below.

Q2: If a workgroup Windows client process cannot access resources on server machine without having duplicate of such (local) account on target machine already pre-created, does it mean that client (process, machine, or user) can access server resources only by/after having logged (opening logon session) into server machine?

A2: Yes - all access by processes on System1 to resources on System2 must be authenticated - except in the rare cases when someone has configured one or more resources (and system policies) on System2 to allow anonymous (i.e. unauthenticated) access. Further, Server2 can only authenticate network requests that present credentials that System2 can verify - either from the local user accounts and passwords on System2, or by contacting a trusted domain controller (if System2 is joined to a domain). System2 doesn't know anything about user accounts or "user contexts" (those special 'accounts' like LocalSystem, Interactive, LocalService which are only ever represented by special hard-coded SIDs) that are only relevant on System1 - which includes any local user account defined on System1, and any of those special SIDs.

Q3: Or, how to understand that such access is impossible without having corresponding duplicate local account on server machine?

A3: The only exception (and it's not an exception, it's a designed-in use case) is when System1 authenticates using a username + password that are the same on System2. What you'll see in the network traffic is that System1's process (currently running e.g. as System1\UserX) will make a request over the network for a resource on System2 (e.g. file share, database object, web page). In that request from System1, is included "the credentials that System1 is trying to use to authenticate" (this is an abstract generalization to get away from describing things specific to any one authentication protocol - just bear with it). Under other circumstances, the account UserX doesn't exist on System2, or it has a different password, so that the authentication attempt fails on System2, and System1's request fails. That is, System2 assumes that UserX must be System2\UserX, and either the account doesn't exist or the password doesn't match.

Under the circumstance where there are matching local accounts, System2 "thinks" that System1 is logging on not with account "System1\UserX" but with "System2\UserX", and since the password matches, the authentication attempt succeeds.

Q4: Does not any Windows have accounts ((NT AUTHORITY\NETWORK SERVICE)? as well as many other common pre-built accounts? Why are they installed (before any joining to domain) but cannot be used for remote network access and client identification ?

A4: Remember, NETWORK SERVICE isn't a defined account (you won't find it listed in Local Users and Groups applet) but simply a SID - and if any process includes that SID in its token (depending on the circumstances of how the process with that token is created), then any resource that allows "Network Service" (which really means "any resource that allows the Network Service SID") to access the resource will allow it to pass. Otherwise, Network Service is just a user-friendly abstraction, and unfortunately user friendly usually makes things harder to get to the bottom of how it really works.

You might be able to assign permissions or Privileges to the Network Service SID before the system is joined to the domain, but requests to remote systems will respond very differently for a service running as Network Service depending on if the machine is joined to a domain or not. If joined to a domain, the remote request will usually (on modern Windows versions) attempt the remote authentication using the Domain Computer account for the local system. If not joined to a domain, there will be no credentials sent with the remote request, and the remote system will have to treat it as an anonymous (i.e. unauthenticated) request.

Q5: And what is identity used when the process from workgroup Windows under identity ((NT AUTHORITY\NETWORK SERVICE) accesses a remote server?

A5: As implied in A4, there is no identity that the remote server sees in this scenario.