访问服务器资源是否需要客户端进程登录服务器计算机？

Question

重新发布我的 在 technet 中未得到答复。微软问题？

MSDN“ASP.NET 委派”文章 讲述：

• 1)“当当您配置使用特定帐户作为进程标识时，ASP.NET 会尝试委派该帐户，如果该帐户与远程计算机上的本地帐户相同（包括密码），则委派是可能的。如果远程计算机上不存在该帐户，则它在网络中显示为 Windows 匿名帐户 (NT AUTHORITY\ANONYMOUS LOGON)。此外，如果该帐户是有权访问远程计算机的域帐户，则也可以进行委派。在这种情况下，它使用该帐户的域网络身份。”

与在工作组中手动/交互访问远程计算机（服务器资源）的情况相同的频繁重复的故事 - 需要使用相同的用户名、相同的密码创建本地帐户。但为什么？

如果工作组 Windows 客户端进程无法访问服务器计算机上的资源，而无需在目标计算机上预先创建此类（本地）帐户的副本， 这是否意味着客户端（进程、计算机或用户）只有在登录（打开登录会话）到服务器计算机后才能访问服务器资源？

或者，如何理解如果服务器计算机上没有相应的重复本地帐户，这种访问是不可能的？

同一篇 MSDN“ASP.NET 委派”文章 讲述：

• “NetworkService帐户的行为与系统帐户相同。该帐户拥有与其所属域中的计算机帐户（域名\计算机名）关联的网络凭据”

没有任何 Windows 帐户（（NT AUTHORITY\NETWORK SERVICE） )?
以及许多其他常见的预建帐户？
为什么安装它们（在加入域之前）但不能用于远程网络访问和客户端识别？

当身份（NT AUTHORITY\NETWORK SERVICE）下的工作组Windows进程访问远程服务器时使用什么身份？

---

我的相关问题：

• Windows-es 中的域 LocalSystem 与非域 LocalSystem 帐户？
• 如何检查“NT AUTHORITY\”帐户的组成员身份？
• 客户端本地系统（系统）是否由目标/服务器计算机识别？以及其中上下文？
• 窗口工作组 LocalSystem 与域 (AD) LocalSystem [关闭]
• 如何更好地设置机器以在工作组和Windows域中进行开发？ [关闭]
• 与工作组中的 Windows 域计算机进行互操作Windows [已关闭]
• AD加入机器的本地用户上下文？是域计算机帐户还是本地计算机帐户？
• 来自非 AD Windows 的域帐户下的 RunAs [已关闭]
• 如何更好地设置机器在工作组和Windows域中进行开发？ [关闭]
• 如何与多启动工作组 Windows 设置共享同一域计算机帐户？

Answer 1

Q1：与手动/交互访问工作组中的远程计算机（服务器资源）的情况一样经常重复的故事 - 需要创建具有相同用户名、相同密码的本地帐户。但为什么？

A1：是的。参见下面的 A3。

问题 2：如果工作组 Windows 客户端进程无法在目标计算机上预先创建此类（本地）帐户的副本的情况下无法访问服务器计算机上的资源，这是否意味着客户端（进程、计算机或用户）只能通过以下方式访问服务器资源： /登录（打开登录会话）到服务器计算机后？

A2：是的 - 系统 1 上的进程对系统 2 上的资源的所有访问都必须经过身份验证 - 除非在极少数情况下，有人在系统 2 上配置了一个或多个资源（和系统策略）以允许匿名（即未经身份验证）访问。此外，Server2 只能对提供 System2 可以验证的凭据的网络请求进行身份验证 - 通过 System2 上的本地用户帐户和密码，或者通过联系受信任的域控制器（如果 System2 加入到域）。 System2 不知道任何有关仅与 System1 相关的用户帐户或“用户上下文”（那些特殊的“帐户”，如 LocalSystem、Interactive、LocalService，仅由特殊的硬编码 SID 表示） - 其中包括任何本地用户System1 上定义的帐户，以及任何这些特殊 SID。

Q3：或者，如何理解如果服务器计算机上没有相应的重复本地帐户，则无法进行此类访问？

A3：唯一的例外（这不是例外，而是设计的用例）是 System1 使用与 System2 相同的用户名 + 密码进行身份验证。您将在网络流量中看到的是，System1 的进程（当前以 System1\UserX 的身份运行）将通过网络请求 System2 上的资源（例如文件共享、数据库对象、网页）。在来自 System1 的请求中，包含“System1 尝试用于身份验证的凭据”（这是一个抽象概括，以避免描述特定于任何一种身份验证协议的事物 - 只需忍受它）。在其他情况下，UserX 帐户在 System2 上不存在，或者具有不同的密码，从而导致 System2 上的身份验证尝试失败，System1 的请求失败。也就是说，System2 假定 UserX 必须是 System2\UserX，并且帐户不存在或密码不匹配。

在存在匹配的本地帐户的情况下，System2“认为”System1不是使用帐户“System1\UserX”而是使用“System2\UserX”登录，并且由于密码匹配，因此身份验证尝试成功。

Q4：没有任何Windows有帐户（（NT AUTHORITY\NETWORK SERVICE）吗？
以及许多其他常见的预建帐户？
为什么安装它们（在加入域之前）但不能用于远程网络访问和客户端识别？

A4：请记住，NETWORK SERVICE 不是一个定义的帐户（您不会在本地用户和组小程序中找到它），而只是一个 SID - 如果任何进程在其令牌中包含该 SID（取决于该进程的情况）创建具有该令牌的进程），那么任何允许“网络服务”（实际上意味着“允许网络服务 SID 的任何资源”）访问该资源的资源都将允许其通过。否则，网络服务只是一个用户友好的抽象，不幸的是，用户友好通常会使事情更难了解其真正的工作原理。

您也许可以在系统加入域之前向网络服务 SID 分配权限或特权，但是对于作为网络服务运行的服务，对远程系统的请求的响应将非常不同，具体取决于计算机是否加入域或不是。如果加入域，远程请求通常（在现代 Windows 版本上）尝试使用本地系统的域计算机帐户进行远程身份验证。如果未加入域，则远程请求不会发送任何凭据，并且远程系统必须将其视为匿名（即未经身份验证）请求。

Q5：当工作组 Windows 的身份（（NT AUTHORITY\NETWORK SERVICE）下的进程访问远程服务器时，使用什么身份？

A5：正如 A4 所暗示的，远程服务器没有身份看到这个场景。