问题标签 [dacl]

我在下面使用在安全选项卡中为文件夹添加组名并添加它。但是在 python 中，我如何验证该组是否已成功添加。

有没有办法以十进制/十六进制显示 AD 对象的 ACE 掩码，以便读取 0x80000000 或 2147483648 而不是“通用读取”？

DACL/ACE

我有一个这样的目录结构：

目录 1 -> 目录 2 -> 目录 3 -> 目录 4

dir2 在目录 dir1 内，dir3 在目录 dir2 内等。

'dir1' 有自己的一组 DACL。它们是明确的。在 'dir1' - (OI) 和 (CI) 的 DACL 上启用了继承。以同样的方式在目录 dir2、dir3 和 dir4 上启用继承。

最初 dir2、dir3 和 dir4 有自己的一组 DACL，它们是显式的。没有一个 DACL 是继承的，但它们是可继承的。

例如，每个目录 dir1、dir2、dir3 和 dir4 都有 DACL 'Allow Full control to use SYSTEM' 并从 GUI 中显示 None 的列继承。

我有一个函数 setAcl(char* path)。此函数执行以下操作：

为管理员组调用 AllocateAndInitializeSid。

1. 创建 ACL 并调用 InitializeAcl
2. 调用 AddAccessAllowedAce。此 ACE 不可继承。
3. 在传递的参数“路径”上调用 SetNamedSecurityInfo。这些标志被传递：DACL_SECURITY_INFORMATION | OWNER_SECURITY_INFORMATION | GROUP_SECURITY_INFORMATION。

在上述目录中调用 setAcl()，顺序如下：

1. 目录3
2. 目录2
3. 目录4

当它第一次在目录 'dir3' 上调用时，它会为管理员组添加一个显式的 DACL（由于 setAcl 函数而添加）。此外，由于未设置标志 PROTECTED_DACL_SECURITY_INFORMATION，它还会添加来自父级的可继承的 DACL。所以现在 dir3 目录有一个显式 DACL 和另一个从父文件夹“dir2”继承的“允许完全控制系统”DACL。最初，它具有所有显式 DACL。

当在目录 'dir2' 上调用 setAcl 时，也会发生同样的事情。它为管理员组添加了一个显式 DACL，并从父文件夹继承了其他 DACL。“允许完全控制系统”现在标记为从目录“dir1”继承。由于 SetNamedSecurityInfo 还更新了子对象 DACL，它更新了目录“dir3”（dir2 的子对象）的 DACL。由于现在 'dir2' 没有明确的 DACL 'allow Full control to System'，所以 dir3 的这个 DAC1 是从目录 'dir1' 继承的，而在函数调用之前它是从目录 'dir2' 继承的。

我认为继承规则在这里出现，首先一个对象从父级继承 DACL。如果没有一个是可继承的，它会从祖父母那里继承。我对么？

到目前为止，我可以理解一切，当我调用 setAcl("dir4") 时问题就开始了。在 setAcl("dir4") 之后，'dir4' 目录只有一个显式 DACL。它没有从它的祖父母那里继承任何东西。

为什么当我调用“SetNamedSecurityInfo”时它没有从其祖父母那里继承权限？

我的期望是，在调用 SetNamedSecurityInfo 之后，它应该从目录 'dir1' 合并可继承的 DACL，就像我调用 setAcl("dir3") 时所做的那样。但它不会发生。你能解释一下为什么吗？

有没有办法使用 powershell 或命令提示符通过使用特定的进程 ID 或句柄来获取窗口站的权限？

我查看了 Get-Acl 命令，但只能找到一种仅获取文件夹、文件等的方法。

我正在使用以下内容：

• Docker for Windows v20.10.11
• Docker 在 Windows 容器模式下运行
• mcr.microsoft.com/windows:1903 基本映像
• 安装在此基础映像之上的专有应用程序

每年我们都会使用公司软件的最新版本创建一个 Docker 映像。然而，今年的版本表现不同。主机安装运行良好。容器化安装在某些情况下无法运行。我可以将应用程序作为一个简单的 EXE 启动，例如使用 Docker 运行命令。该应用程序将启动并显示在“任务列表”中。但是我无法通过 COM API 启动应用程序，这是一个关键要求。该问题似乎与 COM 相关。通常我们可以为我们的软件创建 COM 对象，就像为任何其他应用程序一样。例如，IE 返回一个 COM 对象就好了：

为我们的应用程序创建这些对象在容器之外工作。但是在容器内，我们最新的安装给出了这个错误：

访问权限似乎没问题。我尝试了几个测试来证明这一点。首先，我可以将 MS Word 等其他软件安装到容器中并为此创建 COM 对象：

其次，我尝试在 PowerShell 中检索 + 修改应用程序的 DACL。

更改访问掩码或受托人可能会导致访问被拒绝错误：

这似乎也证实了默认情况下访问权限是好的。

接下来，我确保 COM 知道该应用程序。这似乎很好。运行此 PS 脚本时，我在主机和容器上得到相同的结果：

gci HKLM:\软件\类-ea 0| ? {$ .PSChildName -match '^\w+.\w+$' -and (gp "$($ .PSPath)\CLSID" -ea 0)} | ft PSChildName

该应用程序与其他应用程序一样显示。通过 AppID 查询时，详细信息显示良好。LocalServer32 指向正确的 EXE：

我尝试过的其他一些事情：

• 查询注册表项。安装我们的软件时创建了 7 个密钥。这些在主机安装和容器安装上看起来相同。
• 即使权限看起来不错，我仍然尝试以备用用户身份登录容器。例如“nt authority\system”是另一个虚拟管理员用户。我还更改了“builtin\administrator”用户的密码以启用该用户的登录。最后尝试完全创建新用户并将其添加到管理员用户组。所有这些尝试都有与“builtin\containeradministrator”（默认用户）相同的错误。
• 一个小的检查是确保 CMD.exe / Powershell 以 x64 运行：
• 使用 regsvr32 重新注册与安装关联的 DLL。
• 从不同的基础图像开始。https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/container-base-images。完整的 Win Server 基本映像在错误方面的行为方式完全相同。较小的 Win Server Core 基础映像问题更大，因为我什至无法使用该基础手动启动应用程序的 EXE。最后，我尝试了完整 Windows 基础映像的其他标签，例如 20H2 和 2004。这些标签的结果相同。Multiarch 或 x64 没有区别。
• 包括历史上需要使用 COM 使 MS Office 应用程序正常运行所需的“Ogawa hack”：https ://stackoverflow.com/a/1680214/7991646 。其他 COM 应用程序也可能需要它，但对我的特定安装没有帮助。

我还能做些什么来诊断或解决这个 COM 问题吗？