我们希望为我们的 (Win 2003) AD 层次结构添加一些逻辑结构。我们有一个域和大约 500 个用户。当前,所有用户和计算机都被组织到一个 OU 中。所有安全组和通讯组都在第二个 OU 中。组成员身份本质上是基于单个用户的,没有组嵌套。
我的问题:
- 对于这种规模的组织,是否值得根据部门、地理和/或对象类别(即计算机、用户、组)设计 OU 的层次结构并将用户、计算机和组移动到相关的 OU 中?
- 如果是这样,您将如何构建层次结构,例如部门->位置->对象类?
- 我们是否应该在适当的时候嵌套组,以便更好地映射到企业应用程序角色和 Exchange 地址条目?
以下是微软推荐的 AD 逻辑设计的核心原则:
首先为控制委派设计,因为它基于 AD 权限并且是最不灵活的修改轴。如果您没有进行控制委派,请不要担心这一点(但无论如何我都会计划这样做 - 即使在一个很小的组织中,您可能需要分支机构中的指定用户能够重置密码, ETC)。
为组策略的应用设计第二个。按安全组成员身份过滤组策略应用程序允许 GPO 仅应用于目录中链接点以下的用户或计算机对象的子集,因此该轴比 AD 权限具有更大的灵活性。
最后为组织和易用性而设计。让您和其他管理员轻松查找内容。
在您设计时考虑这些注意事项中的每一个,并按照建议对它们进行优先排序。以后(相对而言)很容易改变事情,而且你永远不会在第一次尝试时“做对”。在我什至 DCPROMO 我的第一个域控制器之前,我通常会在纸上或白板上画出建议的结构,并通过潜在的使用场景来查看我的设计是否“站得住脚”。这是解决设计问题的好方法。
(也不要忘记站点对象上的组策略应用程序。当您在站点上链接 GPO 时,您必须小心跨域 GPO 应用程序,但如果您是单域环境,您可以获得很多很棒的将 GPO 链接到站点的功能。使用它处理一些示例场景——我发现它非常适合加载具有“站点特定”设置的软件,或者在某些情况下登录到计算机时向用户提供特定的登录脚本物理位置,通过环回组策略处理。)
我总是将用户、计算机和组拆分为单独的 OU,原因很简单,因为它更易于管理。
如果您对特定的 AD 结构没有令人信服的理由,那么请从管理的角度设计您的 AD。想想你将在哪里应用政策。
如果您在部门级别应用大部分策略,请使用 Department\Location\Object
如果您在位置级别应用大部分策略,请使用 Location\Department\Object
如果您以其他方式执行此操作,则意味着您必须将您的策略链接到多个 OU,这涉及到不必要的工作。
嵌套组非常好,并且再次使 AD 管理更加容易。
我倾向于在设计广告结构时考虑到“易于管理”,而不是反映公司的实体结构,但两者通常是相同的。
我认为,如果我不得不再次重新设计我的广告,我会做一些不同的事情,但我发现:
用户 - 将论文分成部门,但也有临时或代理人员的区域。毫无疑问,这些地点的位置不会像人们四处走动那样重要。
计算机 - 将它们拆分为位置和子位置。即 OfficeComputers/LondonOffice/Room103(财务)。这意味着您可以将设置应用到一个位置或办公室——例如不同的代理服务器,或不同的防病毒设置(当然只有当 AV 管理程序使用 AD 时)——而无需重新组织,并且希望不必打开可以是环回处理的蠕虫。
我还发现不使用内置用户或计算机组很有用,不是任何技术问题,只是为了让您可以轻松地看到不应该出现的地方。
最后,将您的服务器也分开,我已经选择了似乎运作良好的位置/角色。
正如已经回答的那样,这是我的一个小例子,请注意,没有对错,这完全取决于需求 - 即首先是组织还是位置?即使对于计算机/服务器角色,我也更喜欢组织角色。我还喜欢指出单个 OU 以获取所有员工并且没有垃圾来填充 Intranet 员工列表的能力。随意编辑!
在这种情况下,我只是按位置拆分它们。生成的 OU 结构如下所示:
等等
我真的认为这里不需要进一步划分,例如按部门划分,因为它会产生额外的管理开销而没有真正给予太多回报。但是,按位置拆分将使您能够在每个站点实施委派。
我使用的指导方针是:用户;根据 HR chartflow Groups 组织;根据工作流程组织计算机;按地理位置组织
这个线程中的其他答案也非常好。