我必须授予某些用户在Windows Server 2003 Active Directory中的某些权限，这些用户只能在特定用户集合上处于活动状态。 最初的想法是只有一个OU，我们将允许这个特定的用户有一定的权利（用户创build，密码重置，将用户添加到组等）。 但是，在进一步阅读之后，我不确定是否需要一个OU，而且我不确定什么时候需要OU。 这是在烦我，我真的想更好地理解OU使用或不使用它们的目的。
我已经在网上search了一下，结果有点不同，从模糊的“使用组织单元组织AD”到具体的 “如果一个完全独立的组需要对一部分用户进行特殊pipe理访问，将OU添加到域”。 在这一点上，后者听起来是最合适的。 从技术上讲，您只能在OU上使用“委派控制向导”。 但是，我没有看到任何阻止我单独手动分配权限到一个域组，并有效地具有相同的事情。 我在这里错过了什么？ 谢谢。
通常，OU用于：
保持事物的清洁和结构。 您的用户远离小组，您的小组远离计算机，站点A中的对象远离站点B中的对象，等等。
控制权的授权。 只有真正需要，如果你有多个级别的访问或多个网站与不同的pipe理员在每个。 即使如此，我还是要提前计划，并且设置一些东西来启用它。
组策略。 不是完全必要的，因为策略应用程序可以通过权限或WMIfilter进行pipe理，但同样有助于了解如果用户在OU X中，则会获取策略Y.
请注意，在上面，您不能将GPO应用于容器，因此如果您不创buildOU，则必须将所有GPO都设置为顶级（域）级别，并使用WMI或安全性对其进行筛选。 对于您和其他人来说，使用OU 更容易 ，除非您有使用OU模型无法完成（或可以完成但是很混乱）的特定策略的场景。
除了最后两点的明显的技术要求外，我觉得保持干净整洁是足够的理由。 例如，从列表100中find想要的对象比从列表1500中find对象更容易。 它还将您创build的对象（主要是用户，计算机和组）与内置对象分离，这可以帮助防止意外事故（“确定，删除pipe理员帐户的人员？”）。
OU用于在Active Directory中组织对象。 一个典型的例子如下：
myDomain.loc ├─Users ├─Servers │ ├Domain Controllers │ └Member Servers └─Workstations ├New York ├London └Brisbane 这使得区分视觉领域中的对象变得更容易，而不必依赖于记忆或挖掘。 使用这种结构，您也可以将策略应用于特定的容器。 您可以将一般的Internet Explorer策略应用于Workstations OU，以便适用于该树中的所有子对象。 然后，您可以将具体的Internet Explorer设置设置到子OU（例如，为伦敦工作站设置IE主页的不同策略，而不是为纽约工作站设置不同的主页等）
在您的具体示例中，似乎您想将AD控制委托给一组用户。 在这种情况下，正确的方法是创build一个新的安全组，并使所有目标用户成为该组的成员。 然后，您将打开“AD用户和计算机”，右键单击要让用户/组进行控制的OU，然后select“委派控制”。
现在…如果您正确地组织您的AD，您可以精确地控制您希望该组用户的控制权。 例如，您可以创build一个名为NewYork-Admins的组，并将该组的控制权委托给纽约工作站，而不是所有工作站。
这种授权的理想AD结构将是一个像下面这样的结构：
myDomain.loc ├─Domain Controllers ├─Special Users └─Locations ├─New York │ ├─Users │ ├─Workstations │ ├─Servers │ ├─Contacts │ ├─Servers │ └─Groups ├─London │ ├─Users │ ├─Workstations │ ├─Servers │ ├─Contacts │ ├─Servers │ └─Groups └─Brisbane ├─Users ├─Workstations ├─Servers ├─Contacts ├─Servers └─Groups
这允许您以非常细粒度的方式将控制委派给AD对象。
我创build了两个OU，一个用于存储“员工”，另一个用于存储需要对我们的FTP服务器进行身份validation的客户端。
我使用OU的原因是，我的一些设备可以对LDAP进行身份validation，但是（看起来）只能识别组成员身份。 此外，“感觉”更好的封锁外部帐户。 如果我拥有更多客户的基础设施，我会为他们创build自己的域名。