设计有效的 OU 结构

过度强调 OU 结构就会忽略 Active Directory 设计的其他方面，例如规划站点拓扑或考虑域控制器大小。另一方面，如 OU 规划不受重视，组策略和委派将会受到不良影响。

我曾听到的一种托辞是 OU 结构很灵活，如果不合适，之后可以进行更改。的确，OU 结构很灵活；不过，管理员通常发现后期更改 OU 结构要比他们原来预期的困难。当然，可以添加新 OU，但旧 OU 却很难清除。

计划欠佳的 OU 结构往往会我行我素。如果在目录中创建了一个新对象，但管理员不知道将其置于 OU 结构中的什么位置，他只能选择要么创建一个新 OU，要么将该对象放在某个不相干的位置。这两种情况都比较危险。创建一个新 OU 很容易做到，但从长远角度来看很难进行跟踪。猖獗的 OU 创建形成了混乱的 OU 结构，而且易于让各种内容蔓延到未记录的目录中。另一方面，如果您将某个对象添加到与其不相干的现有 OU 中，则此新对象可能会接收它不应获得的策略，或者该对象的权限可能被委派给非目标用户。

设计 OU 结构时，应记住一个基本等式：简单性 + 适用性 = 可持续性。如果您的设计过于简单，则它可能并不适用，因此将不得不过于频繁地进行更改。如果您的设计适用性过强，则所有内容都将被分类，这会使情况变得过于复杂。

有三个关于组策略、委派和对象管理的关键原则，它们可为您的设计决策提供指导。这些原则可被归结为三个您应自问的问题，帮助确保所创建的 OU 结构体经得起时间和组织更改的考验：

如果上述任一问题的答案均为“是”，则您可能应创建此 OU。如果所有三个问题的答案均为“否”，则您应重新考虑布局并确定其他设计是否更加合适。但是，在我对此做更深入的探讨并为您显示如何应用这些原则之前，我应首先解释这些原则之所以重要的原因。

OU 设计的第一个原则是考虑将应用于 OU 的组策略对象。GPO 允许您强制对用户和计算机设置进行配置。您可以在 Active Directory 中定义多个 GPO，并将其应用于整个域、各种 OU 乃至域中的站点。GPO 分为两类—一类用于用户，一类用于计算机。

计算机策略和用户策略可在同一 GPO 中定义。GPO 的“用户配置”大多定义用户登录时的体验。这些设置类型也存在于“计算机配置”中，但此部分还包含与计算机安全性相关的更多设置，例如谁可在本地登录到计算机或如何加密数据。

以下是您在定义支持 GPO 的 OU 时需要记住的一些基础知识。首先，仅仅因为用户和计算机策略可在同一 GPO 中定义，就认为最好将用户和计算机对象放入同一 OU 中是错误的。将它们合并到同一 GPO 中会使 GPO 应用更难以进行故障排除。当您启用环回策略时，这一点非常明显。

其次，许多人会忘记您可以在站点级别应用 GPO，因此为与 GPO 的应用目标相符，应模拟其站点结构设计 OU 结构。这是 OU 设计的一种常见模型，称为“地理模型”。我将进一步探讨此模型。我必须承认“地理模型”在 OU 设计中的地位，但正如您稍后将看到的，我不认为 GPO 应用是实施此模型的主要原因。

此外，当根据 GPO 考虑 OU 结构时，目标应该是消除复杂性。请确保将 OU 添加到 GPO 继承流中。如果您 OU 所包含的服务器要求与其他服务器相同的策略，请考虑将这些计算机对象置于范围更广的服务器 OU 下，并在此服务器 OU 下为不同的服务器类型创建多个 OU（请参阅图 1）。这可以简化策略应用程序，因为更低层 OU 中的每个计算机对象将从服务器 OU 获取策略，还会获取特定于此特定服务器类型的任何其他策略。

另一基础知识是确保不要创建或链接多个不必要的 GPO。使用 GPO，您可以创建一个策略并将其应用于多个 OU。这有时是有益的，但也可能是有害的。如果您必须更改 GPO 设置，而且链接的 GPO 系统过于复杂，则会偶然将更改应用于错误对象。您创建的链接越多，掌握策略范围的难度就越大。同样，您应避免使用与其他策略相同的设置来创建附加策略。如果您发现您经常如此，则考虑修改您的 OU 结构以应用新的 GPO 继承模型。

最后，您应尽量始终为用户对象和计算机对象创建新的 OU。默认情况下，用户和计算机对象被置于容器中，这不允许您将 GPO 与这些对象直接链接。可将 GPO 应用于域中的用户和计算机容器，但除非您在其他位置阻止继承，否则，这些策略将应用于域中的每个用户和计算机。在 Windows Server® 2003 中，您可以使用 rediruser.exe 和 redircomp.exe 工具将用户对象和计算机对象的默认位置更改为您为其创建的 OU。

您创建 OU 结构的方式与在域中委派权限的方式一致，这一点非常重要。请记住，当在 Active Directory 中委派权限时，权限更改仅对对象生效。因此，如果您为某位用户授予了对特定计算机对象的“完全控制”，则此人员可以修改该对象的属性，但其并不具有对计算机本身的“管理员”权限。

以下是对您在设计 OU 结构时进行委派的一些建议做法：

在此，您实际上有两个选项。第一，您可以创建两个单独的并行 OU，然后将特殊用户与普通用户分隔开来。不过，这意味着如果您要更改所有用户的委派选项，则必须在两个单独的位置更改这些权限。这还与不链接多个不必要策略的方法相抵触（请参阅图 2）。

另一个选项是创建嵌套式 OU，然后对具有特殊用户的 OU 实施显式拒绝权限。任何委派专家都会告诉您显式拒绝不可取—但在此情况下，您需要从两者中选择一个不利因素相对较少的一个（请参阅图 3）。您可以在两个单独的 OU 上复制和维护这些设置，也可以对其中一个 OU 实施显式拒绝。实际上，显式拒绝是更好的长期决策。

如果您为管理员创建单独的 OU，则会发现委派给他们的权限均消失。这由 AdminSDHolder 所致，它是一个特殊的容器，可根据指定间隔将其“访问控制列表”应用于每个管理员帐户。结果是，如果尚未对 AdminSDHolder 容器进行更改，则将取消您对管理员帐户所做的任何委派更改。因此，出于委派目的，您不应将管理员帐户与其他帐户分开。但对于组策略，最好将管理员帐户分出来—在您可以拥有多个密码策略 Windows Server 2008 中，这一点尤为突出。

OU 应有助于对象的管理。将对象归组到同一 OU 中通常更易于执行大量更改。Active Directory 用户和计算机管理单元允许您在选择多个对象时编辑某些属性。因此，如果您必须定期更改某个对象组的属性，则此操作在这些对象全部位于同一 OU 中时更易于完成。

当您使用脚本进行更新时，这一点也特别有用。脚本编写语言可以非常轻松地枚举 OU 中的所有对象并逐个进行处理。另一个选项是搜索并分别修改各个对象。只需将对象放入同一 OU 中进行管理，有时便可以节省您每周不必要的工作时间。

另一个有助于对象管理的方法是根据类型将对象分到不同的 OU 中。为打印机对象或发布的共享创建单独的 OU，可确保您在对 OU 中的其他对象执行管理时不必清除这些对象。这一原则与不将用户和计算机帐户归组到同一 OU 中的原则也是一致的。

既然我已经提到了 OU 设计的原则，那么我可以进一步查看某些常用设计模型。请注意，由于篇幅所限，还有许多模型我无法在此一一介绍。您不要限于仅使用单一模型。您可以拾取每个模型的片段来构建您自己的混合模型，从而解决特定需求。

几乎任何模型都可以实现小范围的成功，但随着企业的扩大，您对环境的处理能力会逐渐缩减。因此，请确保首先在充分的实验室环境中对您的模型进行全面测试。请记住，尽管您最初可以很轻松地更改 OU 结构，但这些结构实施的时间越长，就越难以更改。

“浅模型”的名称源自它大多保持平整这一事实。在此模型中，几个高级别的 OU 包含绝大多数对象（请参阅图 4）。此模型主要在小型企业中运用，在此类企业中，有一个小型 IT 商店，没有过多的部门，或者人员往往扮演多个角色。为避免对性能产生负面影响，我通常建议子 OU 数不要超过 10 个，尽管 Microsoft 提出的子 OU 限制数是 15 个。

如果人力资源人员同时也是您工资单中的人员，则为“人力资源”和“工资单”创建两个单独的 OU 毫无意义。在“浅模型”中，可将所有用户对象归组到一个大的帐户 OU 中，也可将其保留在默认用户容器中。最起码，您的用户对象应与计算机对象分开。

对于此模型，我还建议您进一步将工作站与服务器分开。然后，您至少可以应用不同的组策略，而无需定义一个使用 Windows® Management Instrumentation (WMI) 查询过滤出工作站或服务器的 GPO。

保持 OU 结构范围广泛（而不是深度）的一个优势是 Active Directory 搜索速度将更快。我通常会建议子 OU 数不要超过 10 个。虽然在此模型中您对对象的控制不是非常精准，但是，如果您管理的是小型企业中的对象，则不需要这种精准控制。因而，此模型很难在大型企业中成功使用，但其在小型组织中的效果却非常好。

在地理模型中，您针对不同的地理区域创建单独的 OU。此模型最适合用于 IT 部门分散但不希望因操作多个域而带来成本的组织（请参阅图 5）。

假设您的办事处设在亚特兰大、巴尔的摩和西雅图。如果每个站点管理它自己的用户和计算机，则就委派而言这可能是一个很好的方法。但如果西雅图用户飞到巴尔的摩参加培训，然后封锁了其帐户，将会怎样？如果位于巴尔的摩的 IT 人员没有被委派该用户帐户的权限，则他们可能无法为其提供帮助。如果在巴尔的摩是上午 8 点，那么在西雅图就是上午 5 点，这意味着该用户可能必须等待几个小时才能在西雅图办事处找到可以提供帮助的人员。

一些全球性的公司使用“全天候”模型，在其中，帮助台呼叫被路由到当前采用标准工作时间的时区中的站点。这意味着公司不必在每个站点都运行 24 小时帮助台，但仍可以为夜班员工提供必要的帮助，例如解除对其帐户的锁定。

如果您采用的是这一模型，那么对于您的运营需求而言，根据地理位置创建单独的 OU 可能不是最佳选择。您必须将单独的权限委派到用户各个 OU 中的每一区域帮助台。不过，如果您的站点确实拥有它们自己的 IT 部门，则实际上对于您的组织而言，地理模型可能是理想之选。

此外，由于域操作方式的性质，很难在单个域中实现地理模型。某个域的安全模型往往与其他域的不同。当您查看企业范围的应用程序（如 Microsoft® Exchange）时，这一点更为明显。

位于亚特兰大的 Exchange Server 可能定义了不同的消息策略，但该企业中的所有 Exchange Server 可能应用同一 GPO。如果是这种情况，则按区域将 Exchange Servers 置于单独的 OU 中将导致您不必要地将同一 GPO 链接到多个 OU。就委派而言，您必须询问 Exchange 管理员是否确实需要 Exchange Server 计算机对象的唯一权限。在大多数情况下，被拆分到地理 OU 中的计算机对象是为组策略（而非委派）做此处理。

基于类型的模型按用途来分类对象（请参阅图 6）。当您创建上一个用户对象时，它是用于普通用户帐户、管理帐户还是服务帐户？在基于类型的模型中，上述每种对象的处理方式均不同。

在大多数情况下，您应针对策略区分用户对象的不同类别。您的策略将很可能根据用户帐户类型而有所不同。例如，允许人员使用服务帐户登录计算机通常是一个糟糕的业务惯例。服务帐户密码通常在许多人员之间共享，因此，如果某个人使用服务帐户登录，则其身份是匿名的。如果发生什么事情，您很难跟踪到事件发生时所登录的用户。在本示例中，您需要对服务帐户设置一个防止交互登录的策略。这非常适合层次模型，如图 3 所示。

此时，可利用 GPO 继承为您带来益处。例如，您可以具有“所有用户”策略，它是指用于所有用户对象的策略。另外，您还可以针对服务帐户具有独立但截然不同的策略（它基于“所有用户”策略而构建）。这一方法可确保您的服务帐户与所有其他帐户具有相同的基础策略集，同时还具有特定的登录限制。

此方法还对委派十分有效，在其中，您使用权限继承而非 GPO 继承。假定您希望第 2 层管理员可以重设除第 3 层管理员帐户之外的所有帐户的密码。使用平面 OU 结构，您必须将权限委派给持有用户帐户的每个 OU。不过，在具有层次结构的基于类型的模型中，您可以在帐户 OU 上为第 2 层的组授予“重设密码”权限，然后在第 3 层 OU，您只需取消继承这些权限，甚至可以为第 2 层设置显式拒绝来重设密码。

这对于计算机对象同样有效。服务器和工作站可以分开，从而允许对它们应用不同的策略。服务器然后可被进一步细分为多个功能（请参阅图 1）。在本设计中，您可以对服务器 OU 设置影响所有服务器的高级别策略，同时仍对每个低级别 OU 设置单个策略。

例如，假设您有一个 Microsoft Operations Manager (MOM) 服务帐户。使用此分层模型，您可以创建一个 MOM GPO 并将其应用于 MOM 服务器 OU。然后在此 GPO 内部，您可以授予 MOM 服务帐户权限，从而以服务形式登录。这仅适用于此 OU 中的 MOM 服务器。MOM 服务器仍将从高级别服务器 OU 获取服务器 GPO，但它们还将获得在 MOM OU 链接的专用 MOM GPO。

设计一个经受得起 Active Directory 环境所遇到的多种变化的 OU 结构非常有意义。但是，您需要设法跟踪 OU 的动态特征。如果您不具备此条件，则会很快失去对环境的掌控。如果内容确实需要更改，而且需要添加或删除 OU，则就所执行操作必须要有明确的指导，以确保您的模型继续沿袭设计模型，从而遵循三个指导原则。这就是您为什么必须对设计进行完整文档记录的原因。

Microsoft 在 Windows Server 资源工具包中提供了文档指南。如果您的结构是一个较为可靠的框架，而且您不想进行太多更改，则这些指南会提供很好的帮助。但是，大多数组织的结构都十分动态，需要频繁更改。因此，下面提供了一些重要提示，以确保您的 OU 结构有完整的文档记录，而且能够支持动态环境。

遗憾的是，大多数管理员直到他们确实需要一个完善的 OU 结构文档时才意识到它的重要性。但到那时（凌晨 3 点），不执行还原几乎不可能查明哪些其他 OU 已被意外删除。

请不要等到此刻才幡然醒悟。强烈建议您在此方面积极行动起来，立即启动 OU 文档并指定一名人员负责其更新。如果您遵循使文档易于更新这一规则，这将只是一个需要反复执行的极小任务。