我需要配置两种类型的用户来管理 AD 用户和安全组：
- 类型 1- 只能在特定 OU 内创建用户。
- 类型 2- 只能更改在上述 OU 中创建的用户的组成员身份。
我是根据委派控制功能来执行此操作的。想法是不要使用单一信任点来创建用户并将其添加到安全组，因此该操作至少需要 2 个人。
一切都清楚类型 1用户。我刚刚为用户帐户配置了委派控制，并设法在仅设置的 OU（即操作员）内创建用户。
和类型 2它变得更加复杂，因为我注意到它不是组链接到用户，而是用户链接到组。我只能更改 1 个 OU（即操作员组）的组成员身份，但我可以将任何用户添加到该 OU 内的组。这意味着负责修改组成员身份的用户可以将自己添加到任何组中，这对我来说是不可接受的，因为只有由类型 1可以将用户添加到由以下人员控制的安全组：类型 2用户。
理论上，我看到的唯一正确的解决方案是如何实施，即在安全组或 OU 级别进行限制，以修改不在允许 OU 中的用户的组成员身份，但是我在谷歌上搜索并调查了微软知识库，但未能找到有关如何做到这一点的足够信息。
也许有人知道如何实现这一点或者可以建议我如何实现必要的配置？
答案1
负责修改组成员资格的用户可以将自己添加到任何组
当然。这是设计使然。Active Directory 中的组和组成员之间的链接关系使得向前从组到用户的链接可写（成员属性），而反向链接从用户到组（成员属性）是内部计算的，并且是只读的。您无法委托编辑用户的 memberOf 属性的能力。有关如何将其存储在Florian 的博客。
这种情况的含义是：组成员资格由用户编辑团体，而不是要添加到组的目标用户。这通常是因为组由组织内的特定人员或团队“拥有”，因为它控制对该团队特权资源的访问。因此，该团队指定的安全负责人应有权决定组织中的哪些成员被授予该组授予的权限。这是一个酌情访问控制策略。
学习要点：您不能委托对组的控制，使得用户只能添加来自特定 OU 的成员。
我怎样才能让它工作？
您的最终目标是：强制的和酌情访问控制策略：
- 强制的：用户应仅被允许添加来自特定 OU 的用户
- 自由裁量：用户应自行决定该 OU 中的哪些用户属于其组
由于我在一开始就概述的原因，使用默认的 Active Directory 委派机制无法实现这一点。任何合适的实现都需要一个非技术（即策略）系统，或一个单独的基础，用户可以使用该基础更改其组成员身份：
政策
让所有员工意识到，他们只能将自己控制的 OU 中的成员添加到其委派的组中。设置自动报告以监控违反此政策的行为，并自动纠正（通过删除违规用户）或向相关部门发送电子邮件通知。
定制软件
不要将编辑组成员资格的控制权委托给用户。相反，请使用第三方软件包（您可以自定义开发）。该软件包被委托编辑任何托管组的控制权。它可以在代表用户进行更改之前，对用户要添加的用户选择进行合理性检查（通过根据 ACL 检查 OU 等）。
复杂的 ACL 设置
您可以设想这样一种情况，即翻转逻辑——为每个 OU 创建两个组：
- OU 组：第一组包含每个人在 OU 中。未委派对该组的控制权。
- OU 拒绝组：第二组包含应该被否认对该 OU 资源的访问权限。对该组的控制权已委托。新用户默认添加到此组（策略决定）。
在资源上创建 ACL 时，您可以添加具有完全访问权限的 OU 组，以及将所有 ACE 设置为拒绝的拒绝组。委派权限意味着最终用户可以拒绝他们选择的任何人（来自任何 OU）的访问。这不会破坏模型，因为用户需要允许获得访问权限，并且这些只能通过OU 组您没有委托修改权限。
从多个方面来看，这都不是理想的情况：
- RBAC：我还没有谈论基于角色的访问控制，这是推荐的，但这种简单的方法忽略了谈论。
- 明确拒绝在哪里隐含拒绝是可取的：我们的访问权限变得不必要地复杂，我们的拒绝权限是明确的而不是隐含的，如果我们不了解默认组和拒绝组之间的复杂相互作用，我们很容易陷入用户不知不觉地被授予访问权限的情况。
我建议您执行以下操作之一：
- 重新思考你的问题
- 重新评估你的资源，使其不特定于 OU
- 按照部门划分，将您的环境划分为多个域（提供更高的粒度）
- 集中 ACL 管理
- 实施适当的政策来管理和/或审核授予权限的过程
- 使用第三方软件来管理你的群组成员资格，这些软件可以理解你的组织需要执行的策略的具体语义