“ NT AUTHORITY \ SYSTEM”是用户还是组？

在Windows中，用户System显示为组符号： 。 （使用内部Win32 API LookupAccountSid还显示它似乎是一个SidTypeGroup组。）

另一方面，进程可以system context类似的方式运行user context。此外，Microsoft文档将其描述为“系统用户”或“系统帐户”，而不是“系统组”。

是否将出于任何旧版目的显示为组的用户？

（或者是Werner Heisenberg会感兴趣的东西？）

注意：什么是NT AUTHORITY \ SYSTEM用户？相似，但没有回答为什么将其显示为组并表现得像用户的问题。

首先，访问令牌 包含的内容远远超过安全标识符（SID）。只需“以管理员身份运行”程序，即可在任务管理器中看到其用户是自己而不是管理员，而这个奇迹仅通过修改访问令牌而不是替换SID即可实现。

其次，尽管有各种说法（即使在Microsoft内部），NT-AUTHORITY和SYSTEM也不是帐户也不是组。SID通常具有在需要时显示的名称。用户帐户将其SID作为主体SID贡献给访问令牌，访问令牌还将确定各种实用程序显示的名称。但是访问令牌可能包含其他SID，例如该用户帐户所属的所有组的SID。在检查权限时，Windows将在具有该权限的访问令牌中查找任何SID。

一些众所周知的Windows SID将具有Windows报告的名称，尽管它们实际上并不属于任何帐户。

维基百科将安全标识符定义为：

用户，用户组或其他安全主体的唯一的，不变的标识符 。

SID甚至不需要定义用户帐户或组。它只是定义了一组权限。上面的维基百科文章添加了：

Windows根据访问控制列表（ACL）授予或拒绝对资源的访问和特权，访问控制列表（ACL）使用SID唯一标识用户及其组成员身份。当用户登录计算机时，将生成一个访问令牌，其中包含用户和组SID和用户特权级别。当用户请求访问资源时，将根据ACL检查访问令牌，以允许或拒绝对特定对象的特定操作。

的SID NT-AUTHORITY\SYSTEM可以添加到其他帐户。例如，这是关于LocalSystem帐户的说法 ：

LocalSystem帐户是服务控制管理器使用的预定义本地帐户。[...] 它的令牌包括NT AUTHORITY \ SYSTEM和BUILTIN \ Administrators SID；这些帐户可以访问大多数系统对象。

在上面的文本中已经可以看到，即使在Microsoft文档中，关于系统SID的混乱也依然存在，系统SID并非完全是帐户或组-仅仅是一组权限。这种混乱进一步扩展到其他实用程序和文章，因此，应仔细检查返回的任何信息。

Microsoft文章 Windows操作系统中的知名安全标识符 详细介绍了所有系统SID，我在其中包括了其中的一些：

结论：NT-AUTHORITY \ SYSTEM是安全ID的名称，它既不是组也不是帐户。当它是程序的主要SID时，在任务管理器中显示为SYSTEM。我最多称其为“伪帐户”。

恕我直言，您的观察是正确的。NT-AUTHORITY\SYSTEM是一个组，因此您可以将其称为系统组。此组至少从Windows NT 4开始就存在，并且已经是那里的一个组：

特殊团体

[...]

系统-操作系统。

还有一个名为帐户本地系统，其

[...]包括NT AUTHORITY \ SYSTEM [...]

因此您可以将其称为SYSTEM组成员的系统用户。

Sysinternals的PsGetSid支持系统中的群论：

C:\>PsGetsid.exe S-1-5-18

PsGetSid v1.44 - Translates SIDs to names and vice versa
Copyright (C) 1999-2008 Mark Russinovich
Sysinternals - www.sysinternals.com

Account for YOURPCNAMEHERE\S-1-5-18:
Well Known Group: NT-AUTHORITY\SYSTEM

关于以组为单位开始进程：

为了管理安全性，进程获取访问令牌。访问令牌仅包含SID。我不确定是否要检查用户的SID是用户还是组。原则上没关系：SID定义可以访问的内容。也许CodeProject文章可以帮助实现