我很难找到好的文档来准确解释如何在本地组中处理 AzureAD 帐户，而且我得到的结果很混乱，这使得我很难编写可靠的 API 来提供准确的结果来确定不同类型计算机的组成员身份。
本文概述了使用WinNT提供程序时的可能路径但我发现这并不广泛。当计算机加入域时，一切都非常简单。但是，当计算机未加入域时，我可以观察到对象通常具有与工作组名称和计算机名称相对应的路径。例如，内置组Administrators通常会有一个 ADsPath：
WinNT://<workgroup name>/<computer name>/Administrators
因此通常是这样的：
WinNT://WORKGROUP/MyComputer/Administrators
如果存在已加入 Azure Active Directory 的帐户，即使计算机本身未加入 Azure Active Directory，该帐户仍会出现在各个位置。例如，如果 John Doe 使用 设置了他的家用计算机[email protected]，并且contoso.com托管在 Azure Active Directory 上，则 John 的帐户将显示为AzureAD\JohnDoe。
但是，本地计算机实际上并不知道该帐户。在计算机管理下查看，您不会在本地用户下找到该用户。假设是AzureAD\JohnDoe用于设置的那个，它将被找到为本地计算机Administrators组下的成员。
通过枚举该组的成员Administrators，我们可以确定该帐户的 ADS 路径为WinNT://AzureAD/JohnDoe。但是，该 ADS 路径实际上不起作用。尝试使用该路径查找对象将返回错误，通常是这样的：
Run-time error '-2147024843 (80070035)':
Automation error
The network path was not found.
但是，我们可以确定该用户的 SID，并使用类似于以下格式的 SID：
WinNT://S-1-12-1-123456789-1234567890-1234567890-1223456778
这将返回一个有效对象。但是，类不同了；它现在是一个Domain，而不是User我们枚举内置组成员时得到的 。
因此，如果创建一个新的本地组并尝试以交互方式添加用户，这将失败，因为位置设置为计算机的名称。使用AzureAD\JohnDoe将失败。但是，如果以编程方式将成员添加到新的本地组，则可以使用 SID ADs 路径成功将相同的 AzureAD 帐户添加到该组。
当您通过计算机管理再次打开该组的成员时，它现在将显示AzureAD\JohnDoe在 UI 中。这也是一个User，而不是Domain。ADsPath 也是WinNT://AzureAD/JohnDoe，这仍然无效。
因此，无法使用IsMemberADS 组的内置方法来确定 AzureAD 帐户是否是该本地组的成员。我确定可以比较 SID，这似乎可行且更可靠。但是，缺点是这种方法非常慢，并且枚举组成员身份（即使在找到匹配项时使用短路）也非常慢。
我希望有更好的方法来确定组成员身份，即使是计算机上的 Azure 帐户也是如此。该 API 已经可以很好地处理工作组上的本地组检查和加入域的计算机上的域组的检查。然而，Azure 帐户是机器中的新障碍。
据我所知，这与 ADS 提供商有关，因此使用哪种语言获取数据的细节并不重要，所以无论使用命令提示符、WMI、powershell 还是 win32 API，答案都是相同的。