对不同林的域用户进行大规模的权限分配

显然我的业力是这样的：以各种不平凡的方式实施标准任务。 如果有人对问题有不同的看法，请进行讨论，以便问题得到解决。

一个晴朗的早晨，出现了一项有趣的任务，即向用户组分配不同共享的权限，其中包含带有文档文件夹的项目子文件夹。 一切都很好，并且编写了一个脚本来为文件夹分配权限。 然后事实证明，这些组应该包含来自不同域、不同林的用户（对于那些忘记它是什么的人）。 假设共享本身位于 Synology 媒体上，并在 PSI 林的 FB 域中注册。 任务：允许另一个林中的域的用户能够访问此共享的内容，并且非常有选择性。

一段时间后，技术规范采用以下形式：

• 2个森林：PSI森林、TG森林。

  

• 每个森林有3个域：PSI（ZG、PSI、FB）； TG（TG、HU、KC）。
• 林之间存在信任关系；Synology 可以看到所有林中的所有安全组。
• 共享和文件夹/子文件夹必须拥有具有 FullControl 权限的 FB 域管理员帐户
• 文件夹的名称应该系统化。 管理层协调了项目 ID；我决定将安全组的名称链接到项目 ID。
• 系统共享中的项目文件夹必须包含预先在 .xlsx 文件中准备好的结构，并具有适当的访问权限（R/RW/NA，其中 NA – 无访问权限）

  

• 应该可以将一个项目的用户/组成员的权限限制为该项目的某些目录。 用户可能无权访问其他目录/项目，具体取决于组成员身份。
• 创建项目文件夹时，应尽可能在适当的域中自动创建组，其名称与项目 ID 相对应。

技术规格注释

• 建立信任关系不属于技术规范的范围
• 项目 ID 包含数字和拉丁字符
• 所有域的项目用户角色都有标准名称
• 在整个项目开始之前准备一个包含文件夹和访问权限（访问矩阵）的 .xlsx 文件
• 实施项目时，可以在相应的域中创建用户组
• 通过使用标准 MS Windows 管理工具实现自动化

技术规范的实施

在正式确定这些要求后，我们暂时暂停了测试创建目录和为其分配权限的方法。 它的目的是仅使用 PowerShell，以免使项目复杂化。 正如我之前所写，脚本算法看起来非常简单：

• 我们使用从项目 ID 派生的名称（例如 KC40587）以及访问矩阵中指定的相应角色来注册组：KC40587-EN- 用于工程师； KC40587-PM – 产品经理等
• 我们获取所创建组的 SID
• 注册项目文件夹和相应的目录集（子文件夹列表取决于在访问矩阵中创建和定义它的共享）
• 根据访问矩阵为项目的新子目录分配权限。

第一阶段遇到的困难：

• 对脚本中指定访问矩阵的方法的误解（现在实现了多维数组，但正在根据.xlsx文件/访问矩阵的内容寻找填充它的路径）

  

• 无法使用 PoSH 在 Synology 硬盘上的 SMB 共享中设置访问权限 (https://social.technet.microsoft.com/Forums/en-US/3f1a949f-0919-46f1-9e10-89256cf07e65/error-using-setacl-on- nas -share?forum=winserverpowershell），因此浪费了大量时间，并且所有内容都必须使用 icacls 访问权限编辑实用程序来适应脚本，这需要创建文本和 cmd 文件的中间存储库。

当前模式下，cmd文件的执行是手动控制的，具体取决于需要为项目注册文件夹。

事实证明，还应该执行该脚本来注册其他林中的组（使用了术语“跨域”），并且比例不仅可以是 1 比 1，还可以是 XNUMX 比多。

这意味着来自其他跨域（包括相邻林）的组现在可以声明对任何域资源的访问权限。 为了实现一致性，决定在所有林的所有服务域的 OU 中创建对称结构（黑色垂直椭圆形）。 正如他们所说，在军队里，一切都应该是丑陋的，但统一的：

因此，当在TG域中注册项目80XXX时，脚本执行：

1. 在本域和跨域（即其员工必须有权访问该资源的域）中创建相应的 OU（红色水平椭圆）。

2. 用名称如下的组填充 OU -， 在哪里：

• SRC_域 – 跨域，其员工将有权访问DST域资源
• DST_domain – 实际上应该提供对其资源的访问的域，也就是说，一切都是为了该域而启动的
• - 项目编号
• 角色 – 访问矩阵中列出的角色名称。

3. 读取所有涉及域的所有组的 SID 数组，并将其保存以供后续数据传输到定义特定项目子文件夹权限的文件中

4. 生成具有一组权限的源文件（参数 /restore），供 icacKC 实用程序在可执行文件模式下使用“icacKC "as-nasNNKCProjects" /restore C:TempKCKC40XXKC40XX.txt”

5. 创建一个 CMD 文件，将所有项目文件夹的所有启动的 icacls 组合起来

如前所述，启动可执行文件是手动完成的，执行结果的评估也是手动完成的。

我们最终不得不面对的困难：

• 如果项目文件夹已充满大量文件，则在现有卷上运行 icacls 命令可能需要相当长的时间，并且在某些情况下会导致失败（例如，当文件路径很长时）；
• 除了 /restore 参数之外，我们还必须添加带有 /reset 参数的行，以防文件夹未创建，而是从以前存在的文件夹转移，并且禁用根目录的继承权；
• 用于创建组的部分脚本必须在每个林的任意 DC 上执行，问题涉及每棵树的管理帐户。

一般结论：很奇怪的是，市场上还没有具有类似功能的实用程序。 似乎可以基于 Sharepoint 门户实现类似的功能。
同样令人无法理解的是，无法使用 PoSH 实用程序在汉学设备上设置文件夹权限。

如果需要的话，如果有人感兴趣的话，我准备通过在 github 上创建一些项目来共享脚本。

来源： habr.com