|
切勿低估设计良好的组织单位 (OU) 结构的重要性和复杂性我发现 IT 部门经常盲目行事他们有时过分关注 OU 结构有时又不对其进行认真思考总之这会导致 Active Directory? 模型发生问题 过度强调 OU 结构就会忽略 Active Directory 设计的其他方面例如规划站点拓扑或考虑域控制器大小另一方面如 OU 规划不受重视组策略和委派将会受到不良影响 我曾听到的一种托辞是 OU 结构很灵活如果不合适之后可以进行更改的确OU 结构很灵活;不过管理员通常发现后期更改 OU 结构要比他们原来预期的困难当然可以添加新 OU但旧 OU 却很难清除 计划欠佳的 OU 结构往往会我行我素如果在目录中创建了一个新对象但管理员不知道将其置于 OU 结构中的什么位置他只能选择要么创建一个新 OU要么将该对象放在某个不相干的位置这两种情况都比较危险创建一个新 OU 很容易做到但从长远角度来看很难进行跟蹤猖獗的 OU 创建形成了混乱的 OU 结构而且易于让各种内容蔓延到未记录的目录中另一方面如果您将某个对象添加到与其不相干的现有 OU 中则此新对象可能会接收它不应获得的策略或者该对象的权限可能被委派给非目标用户 设计 OU 结构时应记住一个基本等式简单性 + 适用性 = 可持续性如果您的设计过于简单则它可能并不适用因此将不得不过于频繁地进行更改如果您的设计适用性过强则所有内容都将被分类这会使情况变得过于复杂 有三个关于组策略委派和对象管理的关键原则它们可为您的设计决策提供指导这些原则可被归结为三个您应自问的问题帮助确保所创建的 OU 结构体经得起时间和组织更改的考验 是否需要创建此 OU 结构以便可对其应用唯一的组策略对象 (GPO)? 特定管理员组是否需要对此 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(请参阅图 )这可以简化策略应用程序因为更低层 OU 中的每个计算机对象将从服务器 OU 获取策略还会获取特定于此特定服务器类型的任何其他策略 Figure Creating multiple OUs for different server types 另一基础知识是确保不要创建或链接多个不必要的 GPO使用 GPO您可以创建一个策略并将其应用于多个 OU这有时是有益的但也可能是有害的如果您必须更改 GPO 设置而且链接的 GPO 系统过于复杂则会偶然将更改应用于错误对象您创建的链接越多掌握策略范围的难度就越大同样您应避免使用与其他策略相同的设置来创建附加策略如果您发现您经常如此则考虑修改您的 OU 结构以应用新的 GPO 继承模型 最后您应尽量始终为用户对象和计算机对象创建新的 OU默认情况下用户和计算机对象被置于容器中这不允许您将 GPO 与这些对象直接链接可将 GPO 应用于域中的用户和计算机容器但除非您在其他位置阻止继承否则这些策略将应用于域中的每个用户和计算机在 Windows Server? 中您可以使用 rediruserexe 和 redircompexe 工具将用户对象和计算机对象的默认位置更改为您为其创建的 OU 原则 委派 您创建 OU 结构的方式与在域中委派权限的方式一致这一点非常重要请记住当在 Active Directory 中委派权限时权限更改仅对对象生效因此如果您为某位用户授予了对特定计算机对象的完全控制则此人员可以修改该对象的属性但其并不具有对计算机本身的管理员权限 以下是对您在设计 OU 结构时进行委派的一些建议做法 设计时应注意权限继承 例如假设您希望第 层管理员能够更改大多数帐户的密码对于特殊的用户组管理员不应具有重设密码的能力但他们确实应该可以更改有关这些帐户的显示名称 在此您实际上有两个选项第一您可以创建两个单独的并行 OU然后将特殊用户与普通用户分隔开来不过这意味着如果您要更改所有用户的委派选项则必须在两个单独的位置更改这些权限这还与不链接多个不必要策略的方法相抵触(请参阅图 ) Figure Maintaining two separate parallel OUs 另一个选项是创建嵌套式 OU然后对具有特殊用户的 OU 实施显式拒绝权限任何委派专家都会告诉您显式拒绝不可取—但在此情况下您需要从两者中选择一个不利因素相对较少的一个(请参阅图 )您可以在两个单独的 OU 上复制和维护这些设置也可以对其中一个 OU 实施显式拒绝实际上显式拒绝是更好的长期决策 Figure Using an explicit deny permission 注意 AdminSDHolder 本示例适用于大多数情况除非特殊用户全部都属于一个管理员组(域管理员架构管理员企业管理员或管理员)因为这些组中的帐户权限的处理方式不同原则是您不希望意外地为某个人授予管理员帐户权限 如果您为管理员创建单独的 OU则会发现委派给他们的权限均消失这由 AdminSDHolder 所致它是一个特殊的容器可根据指定间隔将其访问控制列表应用于每个管理员帐户结果是如果尚未对 AdminSDHolder 容器进行更改则将取消您对管理员帐户所做的任何委派更改因此出于委派目的您不应将管理员帐户与其他帐户分开但对于组策略最好将管理员帐户分出来—在您可以拥有多个密码策略 Windows Server 中这一点尤为突出 原则 对象管理 OU 应有助于对象的管理将对象归组到同一 OU 中通常更易于执行大量更改Active Directory 用户和计算机管理单元允许您在选择多个对象时编辑某些属性因此如果您必须定期更改某个对象组的属性则此操作在这些对象全部位于同一 OU 中时更易于完成 当您使用脚本进行更新时这一点也特别有用脚本编写语言可以非常轻松地枚举 OU 中的所有对象并逐个进行处理另一个选项是搜索并分别修改各个对象只需将对象放入同一 OU 中进行管理有时便可以节省您每周不必要的工作时间 另一个有助于对象管理的方法是根据类型将对象分到不同的 OU 中为打印机对象或发布的共享创建单独的 OU可确保您在对 OU 中的其他对象执行管理时不必清除这些对象这一原则与不将用户和计算机帐户归组到同一 OU 中的原则也是一致的 选择模型 既然我已经提到了 OU 设计的原则那么我可以进一步查看某些常用设计模型请注意由于篇幅所限还有许多模型我无法在此一一介绍您不要限于仅使用单一模型您可以拾取每个模型的片段来构建您自己的混合模型从而解决特定需求 几乎任何模型都可以实现小范围的成功但随着企业的扩大您对环境的处理能力会逐渐缩减因此请确保首先在充分的实验室环境中对您的模型进行全面测试请记住尽管您最初可以很轻松地更改 OU 结构但这些结构实施的时间越长就越难以更改 浅模型 浅模型的名称源自它大多保持平整这一事实在此模型中几个高级别的 OU 包含绝大多数对象(请参阅图 )此模型主要在小型企业中运用在此类企业中有一个小型 IT 商店没有过多的部门或者人员往往扮演多个角色为避免对性能产生负面影响我通常建议子 OU 数不要超过 个尽管 Microsoft 提出的子 OU 限制数是 个 Figure The Shallow Model has a few highlevel OUs that contain the majority of objects 如果人力资源人员同时也是您工资单中的人员则为人力资源和工资单创建两个单独的 OU 毫无意义在浅模型中可将所有用户对象归组到一个大的帐户 OU 中也可将其保留在默认用户容器中最起码您的用户对象应与计算机对象分开 对于此模型我还建议您进一步将工作站与服务器分开然后您至少可以应用不同的组策略而无需定义一个使用 Windows? Management Instrumentation (WMI) 查询过滤出工作站或服务器的 GPO 保持 OU 结构范围广泛(而不是深度)的一个优势是 Active Directory 搜索速度将更快我通常会建议子 OU 数不要超过 个虽然在此模型中您对对象的控制不是非常精准但是如果您管理的是小型企业中的对象则不需要这种精准控制因而此模型很难在大型企业中成功使用但其在小型组织中的效果却非常好 地理模型 在地理模型中您针对不同的地理区域创建单独的 OU此模型最适合用于 IT 部门分散但不希望因操作多个域而带来成本的组织(请参阅图 ) Figure The Geographic Model separates OUs by geographical region 假设您的办事处设在亚特兰大巴尔的摩和西雅图如果每个站点管理它自己的用户和计算机则就委派而言这可能是一个很好的方法但如果西雅图用户飞到巴尔的摩参加培训然后封锁了其帐户将会怎样?如果位于巴尔的摩的 IT 人员没有被委派该用户帐户的权限则他们可能无法为其提供帮助如果在巴尔的摩是上午 点那么在西雅图就是上午 点这意味着该用户可能必须等待几个小时才能在西雅图办事处找到可以提供帮助的人员 一些全球性的公司使用全天候模型在其中帮助台呼叫被路由到当前采用标准工作时间的时区中的站点这意味着公司不必在每个站点都运行 小时帮助台但仍可以为夜班员工提供必要的帮助例如解除对其帐户的锁定 如果您采用的是这一模型那么对于您的运营需求而言根据地理位置创建单独的 OU 可能不是最佳选择您必须将单独的权限委派到用户各个 OU 中的每一区域帮助台不过如果您的站点确实拥有它们自己的 IT 部门则实际上对于您的组织而言地理模型可能是理想之选 此外由于域操作方式的性质很难在单个域中实现地理模型某个域的安全模型往往与其他域的不同当您查看企业范围的应用程序(如 Microsoft? Exchange)时这一点更为明显 位于亚特兰大的 Exchange Server 可能定义了不同的消息策略但该企业中的所有 Exchange Server 可能应用同一 GPO如果是这种情况则按区域将 Exchange Servers 置于单独的 OU 中将导致您不必要地将同一 GPO 链接到多个 OU就委派而言您必须询问 Exchange 管理员是否确实需要 Exchange Server 计算机对象的唯一权限在大多数情况下被拆分到地理 OU 中的计算机对象是为组策略(而非委派)做此处理 基于类型的模型 基于类型的模型按用途来分类对象(请参阅图 )当您创建上一个用户对象时它是用于普通用户帐户管理帐户还是服务帐户?在基于类型的模型中上述每种对象的处理方式均不同 Figure The TypeBased Model groups objects according to their functions 在大多数情况下您应针对策略区分用户对象的不同类别您的策略将很可能根据用户帐户类型而有所不同例如允许人员使用服务帐户登录计算机通常是一个糟糕的业务惯例服务帐户密码通常在许多人员之间共享因此如果某个人使用服务帐户登录则其身份是匿名的如果发生什么事情您很难跟蹤到事件发生时所登录的用户在本示例中您需要对服务帐户设置一个防止交互登录的策略这非常适合层次模型如图 所示 此时可利用 GPO 继承为您带来益处例如您可以具有所有用户策略它是指用于所有用户对象的策略另外您还可以针对服务帐户具有独立但截然不同的策略(它基于所有用户策略而构建)这一方法可确保您的服务帐户与所有其他帐户具有相同的基础策略集同时还具有特定的登录限制 此方法还对委派十分有效在其中您使用权限继承而非 GPO 继承假定您希望第 层管理员可以重设除第 层管理员帐户之外的所有帐户的密码使用平面 OU 结构您必须将权限委派给持有用户帐户的每个 OU不过在具有层次结构的基于类型的模型中您可以在帐户 OU 上为第 层的组授予重设密码权限然后在第 层 OU您只需取消继承这些权限甚至可以为第 层设置显式拒绝来重设密码 这对于计算机对象同样有效服务器和工作站可以分开从而允许对它们应用不同的策略服务器然后可被进一步细分为多个功能(请参阅图 )在本设计中您可以对服务器 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 中的对象数或者 OU 访问控制列表上的每个访问控制项 (ACE) 吗?对于 OU 文档以下信息通常已经足够 OU 名称 简要说明 创建者—或者更多信息或更改的相关联系人 创建时间 不要使更新变得困难 如果您不得不乏味地更新一些复杂的 Microsoft Word 文档则拖延输入更新的可能性会更大当您知道马上就要有大量更新输入时拖延输入少量更改是可以的遗憾的是人们往往忘记这些小部分更改或者只是将其一直拖延下去进而导致作业从未完成过因此更新文档必须要非常轻松免得您洩气在大多数情况下只有几列的简单 Microsoft Excel? 电子表格将非常有效 针对对象本身进行注释 OU 对象具有一个描述属性您可在其中输入注释请考虑将注释置于描述属性中而不是在设计文档中编写它们以便其他人可以立即说出 OU 的用途如果您需要包括更多的详细信息则在描述属性中输入简要说明然后在 OU 文档中加入更多详细信息 自动化文档 可以编写一个脚本以将 OU 结构的内容转储到文本文件Excel 电子表格乃至 HTML 文件中每天晚上都可以对计划好的任务运行这一脚本当您将注释合并到 OU 的说明字段中时这会非常有用之后只需将描述属性转储到文件中您即会自动获得一个记录完整始终为最新的 OU 结构如果您每次运行该脚本时都创建一个新文件而不是覆盖现有文档则可以保留有关 OU 结构如何随时间变化的历史记录 遗憾的是大多数管理员直到他们确实需要一个完善的 OU 结构文档时才意识到它的重要性但到那时(凌晨 点)不执行还原几乎不可能查明哪些其他 OU 已被意外删除 请不要等到此刻才幡然醒悟强烈建议您在此方面积极行动起来立即启动 OU 文档并指定一名人员负责其更新如果您遵循使文档易于更新这一规则这将只是一个需要反复执行的极小任务 |
