客户端 LocalSystem (SYSTEM) 是否由目标/服务器计算机识别？在什么情况下？
[1] 讲述：
- “当您配置使用特定帐户作为进程身份时，ASP.NET 会尝试委派该帐户。如果它是与本地帐户相同（包括密码）的本地帐户，如果远程计算机上不存在这样的帐户，则它在网络上显示为 Windows 匿名帐户 (NT AUTHORITY\ANONYMOUS LOGON)。帐户是有权访问远程计算机的域帐户，在这种情况下，它使用该帐户的域网络身份。”
[2] 通知：
- “所有区域设置中的帐户名称都是 .\LocalSystem。也可以使用名称 LocalSystem 或 ComputerName\LocalSystem”
- “该服务向远程服务器提供计算机的凭据
此外，预定义的“NT AUTHORITY\LOCAL SYSTEM”（或 SYSTEM [3]）存在于任何 Windows 中
并且应该可用于识别（即使客户端（进程）从工作组 Windows 访问），不应该吗？
不过，例如，[3] 的一排答案说明了相反的情况：
- “在工作组中，SID 仅在本地工作站上有意义。”当访问另一个工作站时，SID 不会仅传输名称。 “本地系统”无法访问任何其他系统'
LocalSystem 是否被远程/目标计算机识别？ 又如何呢？
- 作为计算机名\本地系统？
或者 - 作为 NT AUHORITY\LOCAL SYSTEM ？
更新：
这个问题完全在Windows工作组开发环境的范围内......
尽管所有答案都偏离了 Windows 域...
引用：
[1]
ASP.NET 委托
http://msdn.microsoft.com/en-us/library/aa291350。 .aspx
[2]
本地系统帐户
http://msdn.microsoft.com/en-us/library/ms684190。 .aspx
[3]
sysadmin1138 对我的问题“Windows LocalSystem 与 System”的回答
https://serverfault.com/questions/168752/windows-localsystem-vs-system
我的相关问题：
- 域化 LocalSystem 与非域化 LocalSystem 帐户在 Windows-es 中？
- 如何检查“NT AUTHORITY\”帐户的组成员身份？
- 访问服务器资源是否需要客户端进程登录服务器计算机？
- Windows 工作组 LocalSystem 与域 (AD) LocalSystem [已关闭]
- 如何更好地设置机器在工作组和Windows域中进行开发？ [关闭]
- 与工作组中的 Windows 域计算机进行互操作Windows [已关闭]
- AD加入机器的本地用户上下文？是域计算机帐户还是本地计算机帐户？
- 来自非 AD Windows 的域帐户下的 RunAs [已关闭]
- 如何更好地设置机器在工作组和Windows域中进行开发？ [关闭]
- 如何与多启动工作组 Windows 设置共享同一域计算机帐户？
[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"
https://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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您的场景有两种可能性，具体取决于本地（“客户端”）计算机上的 Windows 版本以及服务与 Windows 服务 API 的集成程度：
- 远程计算机将把来自“客户端”计算机的请求视为 NT AUTHORITY\ANONYMOUS
- 远程计算机会将来自“客户端”计算机的请求视为 DOMAIN\COMPUTER_ACCOUNT_NAME
远程计算机将仅将来自其自己进程的请求视为来自 SYSTEM/LocalSystem。
如果您想通过测试找出由于远程请求而看到的帐户上下文，请在远程系统上的审核策略中启用审核登录事件（成功和失败）。您还可以使用 Microsoft 网络监视器，并捕获从“客户端”发送到远程计算机并返回的数据包流。
编辑：另请参阅我对此处相关/重叠问题的回答以获取相关详细信息。
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.
System/LocalSystem和NETWORK SERVICE也都将作为计算机帐户DOMAIN\MACHINENAME$进行远程身份验证。还有另一个内置帐户，LOCAL SERVICE，它将始终以ANONYMOUS LOGON进行远程身份验证（因此大多数授权都会失败）。试图将这些概念理解为 SID 和名称并没有多大意义。身份验证是在结束时的 SSPI 握手验证者将查询被验证者的上下文令牌并验证访问（执行授权），并且也可以从安全上下文中查询被验证者的名称。如果 SSPI 握手是远程的（在两个不同的 LSA 之间），则名称
QueryContextAttributes将返回远程计算机名称domain\machine$。如果这是一次仅涉及一个 LSA 的环回握手，则同一调用将返回 NETWORK SERVICE 或 System.握手也有可能验证“匿名登录”，例如工作组案例、使用本地帐户或尝试跨域信任边界，但基本上都会出现身份验证失败的情况。System/LocalSystemandNETWORK SERVICEas well will all authenticate remotely as the computer account,DOMAIN\MACHINENAME$. There is a another built in account, theLOCAL SERVICEwhich will always authenticate remotely asANONYMOUS 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
QueryContextAttributeswould return, in a successful authentication scenario, the remote machine namedomain\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.