扩展 Active Directory 架构

出处：TechNet Magazine 作者：Vikas Malhotra 时间：2008-5-23 11:51:12

概览:

了解默认的 Active Directory 架构
添加 classSchema 或 attributeSchema 对象
获得并使用对象标识符
使用 .ldif 文件扩展架构

下载这篇文章的代码: Schema2008_05.exe (151KB)

自从在 Windows 2000 中开始引入 Active Directory 以来，Microsoft 已向众多客户提供了用于实施 Active Directory 的基本架构定义。

Active Directory® 的出现也标志着 Windows® 中许多应用程序的写入和实施方式都发生了转变。在此之前，应用程序（如 Microsoft® Exchange 5.5）必须要自行加以构建来包含其自身的目录结构。Active Directory 出现后，许多应用程序（无论是 Microsoft 的还是其他公司的）都开始充分利用它所提供的底层结构，而不再从头开始构建自己的架构。

这些应用程序首先使用 Active Directory 提供的基本体系结构，然后根据需要再加以扩展。以 Microsoft Exchange 2000 为例，它利用 Active Directory 来实现消息传递，并进而定义了未来的 Microsoft 消息传递体系结构。

现在，许多被编写为在 Active Directory 环境中运行的应用程序都依赖其底层架构来发挥作用，并且有些还会根据需要来定义自己的架构变更内容。当然，正如我将在本文中介绍的，这需要一个可扩展的架构。并且，由于如此众多的应用程序都依赖于 Active Directory 中的基本定义，因此核心架构的持续稳定性至关重要。因为许多应用程序都需要在同一个 Active Directory 中彼此配合工作，因此对任意应用程序的变更均不能影响其他应用程序。

什么是架构？

对许多人来说，Active Directory 架构是个黑盒子，修改自身架构这一想法让人觉得有点恐怖。当然，扩展 Active Directory 架构并不是每天都要执行的操作，但特定的应用程序或业务需求可能会需要此操作。因此，了解架构是什么以及它都包含哪些内容非常重要，并且由于 Active Directory 在许多组织中都是非常重要的资产，因此如果因更新有误而致使其出现故障可能会造成严重的影响。

作为一种策略，许多组织都在考虑将 Windows Server® 2008 中的“Active Directory 轻型目录服务”(ADLDS) 或 Windows Server 2003 中的“Active Directory 应用程序模式”(ADAM) 作为一种替代方案加以测试，或者直接实施自定义的架构定义而不扩展 Active Directory 架构。

架构是一种提供目录服务格式的底层结构。Active Directory 架构可以定义“Active Directory 域服务”(ADDS) 中使用的对象类和属性。核心架构定义了许多众所周知的类（如 user、computer 和 organizationalUnit）和属性（如 telephoneNumber 和 objectSID）。核心架构定义中出现的对象被称为“类别 1”对象，而添加的对象被称为“类别 2”对象。

Active Directory 架构可在路径 cn=Schema, cn=Configuration,dc=X 所定义的容器中找到，其中 X 是 Active Directory 林的命名空间。请注意，Active Directory 林仅包含一个架构；对林中的架构定义进行变更会影响该林中的所有域。图 1 显示了对于不同版本的 Windows Server，在 Active Directory 架构中添加的类和属性的数量。

Figure 1 类和属性的数量

版本	添加的属性数量	添加的类数量	架构扩展文件
Windows Server 2003	208	49	Sch14.ldf 到 sch30.ldf
Windows Server 2003 R2	81	29	Sch31.ldf
Windows Server 2008	136	10	Sch32.ldf 到 sch44.ldf

在不同版本的 Windows Server 中，架构的更新都是使用名为 Adprep 的实用工具来完成的。在 Windows Server 2003 R2 的更新版本中，架构版本更新为 31，在 Windows Server 2008 中会改为 44。

要对此进行核对，可使用 ADSIEdit 等工具来检查 Active Directory 中 cn=Schema,cn=Configuration,dc=X 的 objectVersion 属性值。请注意，Exchange Server、System Management Server (SMS) 等应用程序或依赖于 Active Directory 的其他一些应用程序可能会根据应用程序的需求来修改架构。

具体细节

Active Directory 包括两种对象类型：classSchema（简称为类）和 attributeSchema（简称为属性）。如果组织希望将数据存储到未包含在现有架构中的特定属性内，通常会考虑扩展 Active Directory 架构。要在 Active Directory 架构中创建属性，首先要在架构容器中指定一个 attributeSchema 对象，然后为该新对象定义必要的属性。

在 go.microsoft.com/fwlink/?LinkId=110445 中提供了 attributeSchema 对象相关属性的列表以及其他一些信息。正如您所看到的，可为 attributeSchema 对象定义多个属性；这些属性中很多都是必需的。

除常规属性以外，架构中还有一些被称为链接属性的特殊属性，它们都是通过提供前向链接和后向链接来成对实施的。以 Active Directory 中的组成员身份为例。任意组（例如，名为 ContosoEmployees 且包含一个名为 John Doe 成员的组）的 member 属性为前向链接，而成员对象的对应 memberOf 属性为后向链接（因此，当查询 John Doe 的 memberOf 属性时，会计算 ContosoEmployees 组的可分辨名称，即 DN）。

前向链接的行为方式与其他所有属性都非常相似。其值可以是单值或多值（与 member 属性一样，可包含多个对象作为组成员），并与目录中的父对象存储在一起。

另一方面，后向链接是由系统维护的，以确保引用的完整性。查询后向链接属性的值时，会根据所有匹配的前向链接值来计算结果。后向链接始终是多值链接。

ADDS 中的每个对象类都由架构容器中的 classSchema 对象所定义。在 go.microsoft.com/fwlink/?LinkId=110445 中提供了对成功定义 classSchema 对象至关重要的一些属性的列表。

可以指定下列三种类型的类：Structural、Abstract 和 Auxiliary。它们由 objectClassCategory 属性的值定义。（第四种类型称为 88，它包括在 X.500 1993 标准之前定义的所有类。这种类型的类由 objectClassCategory 属性中的值 0 来指定。这种类型的类不应该再定义。）

获得并使用标识符

目录中每个 classSchema 和 attributeSchema 对象的身份都是使用“强制对象标识符”(OID) 定义的，此标识符的定义依据是 classSchema 对象的 governsID 和 attributeSchema 对象的 attributeID。这些是由特定的颁发机构所提供的唯一数字值，可用于识别对象。编号方式由 LDAP 协议 (RFC 2251) 的定义进行管理。Active Directory 架构中的某些 OID 是由“国际标准化组织”(ISO) 颁发的，而有些是由 Microsoft 颁发的。OID 对于目录中的对象而言必须唯一。

OID 是一个数字字符串，如 1.2.840.113556.1.y.z（如图 2 所示）。例如，由此可以得出用户 classSchema 对象的 OID 为 1.2.840.113556.1.5.9。

Figure 2 用户对象的标识符

值	含义	说明
1	ISO	标识根颁发机构。
2	ANSI	ISO 指定的组名称。
840	美国	组织指定的国家/地区代码。
113556	Microsoft	国家/地区指定的组织名称。
1	Active Directory	由组织（如本例中的 Microsoft）指定。
Y	对象类型	定义不同对象类型（类别）（如 classSchema 或 attributeSchema）的数字。例如，5 定义对象类。
Z	对象	标识类别中特定对象的数字。例如，用户类被指定的数字是 9。

当组织打算扩展架构时，必须要确保 OID 的唯一性，为此首先要获取自己的 OID 根号，然后开始分支，为组织所创建的新对象类和属性提供唯一的 ID。OID 根可直接从 ISO 国家注册机构 (NRA) 获取，该机构在美国属于“美国国家标准协会”(ANSI)。

可通过 ansi.org 来了解获取根 OID 所需的程序和费用。对于其他地区，请联系相应的 ISO 成员组织；ISO 在 iso.org/iso/about/iso_members.htm 提供了其成员组织的列表。

在过去，组织可通过向 schemreg@microsoft.com 发送电子邮件来从 Microsoft 获取 OID。但是现在，它会提供一个自动回复，提示请求者从 go.microsoft.com/fwlink/?LinkId=110453 下载并运行 VBScript。

对于 Microsoft 颁发的 OID，该数字是在 Microsoft OID 数字空间下指定的：1.2.840.113556.1.8000.x，其中 x 是指定给组织的唯一编号。组织可能会进一步拆分这些 OID 来指定对象。这样，组织可以使用 1.2.840.113556.1.8000.x.1.y 来代表新的 classSchema 对象，使用 1.2.840.113556.1.8000.x.2.z 来代表 attributeSchema 对象（其中，x 代表组织的唯一编号，y 和 z 分别代表指定给特定的 classSchema 和 attributeSchema 对象的编号）。另外还建议用户在这些对象的名称中使用组织特定的前缀以区分它们。

定义链接属性

前向链接的 attributeSyntax 值为 2.5.5.1, 2.5.5.7（或 2.5.5.14），这一点非常重要。这些值对应于包含可分辨名称的语法，例如 Object (DS-DN) 语法。

后向链接的 attributeSyntax 值必须为 2.5.5.1，这是 Object (DS-DN) 语法。按照惯例，后向链接属性将被添加到顶层抽象类的 mayContain 值中。这将允许从任意类的对象中读取后向链接属性，因为后向链接属性实际上并非存储在对象中；它们都是根据前向链接值计算得来的。

Windows Server 2003 引入了如下所示的一个新功能，组织可使用此功能来链接架构中的两个对象：自动生成 linkID。利用此功能，当属性的 linkID 属性设为 1.2.840.113556.1.2.50 时，系统会自动为新链接属性生成一个 linkID。通过将 linkID 设置为前向链接的 attributeId 或 ldapDisplayName，可创建对应的后向链接。在创建前向链接之后及创建后向链接之前，必须重新加载架构缓存。否则，在创建后向链接时将无法找到前向链接的 attributeId 或 ldapDisplayName。架构缓存可根据需要重新加载，在架构更改后几分钟内或域控制器重新启动后也会重新加载。

如果您的 Active Directory 是在 Windows 2000 级别，则必须向 schemreg@microsoft.com 发送一封电子邮件，向 Microsoft 请求 linkID。在自动回复邮件中，您会看到：“对于发送到 schemreg@microsoft.com 的电子邮件，只有那些与原有环境下的 linkID 注册问题相关的邮件才会得到处理。”为此，请在电子邮件中提供以下信息：公司名称、联系人姓名、电子邮件地址、电话号码、注册的前缀（如果适用）、注册的 OID（如果适用）。

准备扩展架构

假设您已决定扩展您的 Active Directory 架构。在确信它已无法再满足要求后，此分析结果可能会建议减少使用 ADLDS（或 Windows Server 2003 中的 ADAM）实现的替代目录。接下来，确定要添加到架构中的新 attributeSchema 对象，这样做之后，可以定义指定这些新对象所需的所有值（例如 cn、ldapDisplayName 等）。在定义对象的属性值时，还从 Microsoft 或其他机构获取了 OID。您实际上已将上述内容记录为业务需求和技术规范。而且已实施了模拟 Active Directory 的实验室环境并已准备好进行测试。

许多组织实际都设有委员会来批准或拒绝此类变更并且会设置实施它们的过程。由于在许多组织中 Active Directory 都被用作权威的信息源，因此此类检查和平衡至关重要，而且在变更后认真加以贯彻和执行也极为重要，无论怎样强调也不为过。

当组织决定了继续推行后，就必须制定有关此项目的测试和实施计划。要对架构进行扩展，您可以使用 Microsoft 管理控制台 (MMC) 中的 Active Directory 架构管理单元来添加新对象，也可以使用编程或半编程方法来扩展架构（如使用 LDIFDE 来导入 .ldif 格式文件；使用 CSVDE 导入 .csv 格式文件；或使用 Active Directory 服务接口 (ADSI) 脚本）。

无论使用哪种方法，都必须在 Active Directory 林中，在连接到或拥有架构主机的“灵活单主机操作”(FSMO) 角色的服务器上执行此功能。并且，由于用来更新架构的帐户必须具有足够的管理权限才能执行更新，因此应使其成为“架构管理员”组的成员。最后，必须启用林的架构更新（默认为禁用）。

除非变更非常简单，否则都应以自动方式执行，以便促进测试和生产实施阶段之间的标准化并减少可能会因手动操作而产生的错误。让我们假设您已决定使用 LDIFDE 来实施变更。要在扩展架构时应用更新，您应添加新属性和类，向类添加新属性，然后触发缓存重新加载。让我们先来看几种方案。

添加属性

为了叙述方便起见，假设名为 Contoso 的组织希望将新属性添加到其 Active Directory 中，用来标识每名员工的鞋码。Active Directory 林有两个域：contoso.com 和 employees.contoso.com。具体要求是使用用户类定义创建的所有对象都应包含这一新属性。

您必须要记住的一点是，架构变更对这两个域都会产生影响，因为它们位于同一林中。假设您已从 Microsoft 获得 OID 1.2.840.113556.8000.9999 并已将其拆分为 1.2.840.113556.8000.9999.1（代表 Contoso 的 classSchema 对象）和 1.2.840.113556.8000.9999.2（代表 Contoso 的 attributeSchema 对象）。现在要为这一新对象定义所有属性值（如图 3 所示）。

Figure 3 定义 contosoEmpShoe 属性

属性	值	注释
Cn	contosoEmpShoe
lDAPDisplayName	contosoEmpShoe
adminDisplayName	contosoEmpShoe
attributeSyntax	2.5.5.12	指定一个 Unicode 字符串。
oMSyntax	64	表示一个 Unicode 字符串。
objectClass	top, attributeSchema
attributeID	1.2.840.113556.8000.9999.2.1	如组织所定义。
isSingleValued	TRUE	只能存储一个鞋码值。
searchFlags	1	您的分析结果表明您希望为此属性编制索引。备注：您需要在实验室环境下执行压力测试分析。
isMemberOfPartialAttributeSet	TRUE	您希望此属性出现在全局编录中。

而且，尽管 contosoEmpShoe 属性需要可供创建为用户类对象的所有对象使用，但并不建议您对用户类的默认定义进行修改。相反，应定义一个名为 contosoUser 的辅助类，它具有指定为 contosoEmpShoe 的 mayContain 值（如图 4 所示）。然后，将为 contosoUser 辅助类定义的属性添加到用户类中。

Figure 4 定义 contosoUser 类

属性	值
Cn	contosoUser
lDAPDisplayName	contosoUser
adminDisplayName	contosoUser
governsID	1.2.840.113556.8000.9999.1.1（如组织所定义）
mayContain	contosoEmpShoe
possSuperiors	organizationalUnit, container
objectClassCategory	3（定义辅助类）

既然已经执行了分析并定义了值，就可以开始创建 .ldif 文件了（类似于图 5 所示的代码）。您可将图 5 中的内容复制到记事本并将其保存为 contosoUser.ldif（或者，也可以在 technetmagazine.com 的代码下载部分找到此代码的副本）。

Figure 5 .ldif 文件（用于扩展架构）

#Attribute definition for contosoEmpShoedn: CN=contosoEmpShoe,CN=Schema,CN=Configuration,DC=Xchangetype: ntdsschemaaddobjectClass: topobjectClass: attributeSchemacn: contosoEmpShoeattributeID: 1.2.840.113556.1.8000.9999.2.1attributeSyntax: 2.5.5.12isSingleValued: TRUEadminDisplayName: contosoEmpShoeadminDescription: contosoEmpShoeoMSyntax: 64searchFlags: 1lDAPDisplayName: contosoEmpShoesystemOnly: FALSEdn:changetype: modifyadd: schemaUpdateNowschemaUpdateNow: 1-# Classesdn: CN=contosoUser,CN=Schema,CN=Configuration,DC=Xchangetype: ntdsschemaaddobjectClass: topobjectClass: classSchemacn: contosoUsergovernsID: 1.2.840.113556.1.8000.9999.1.1mayContain: contosoEmpShoerDNAttID: cnadminDisplayName: contosoUseradminDescription: contosoUserobjectClassCategory: 3lDAPDisplayName: contosoUsername: contosoUsersystemOnly: FALSEdn:changetype: modifyadd: schemaUpdateNowschemaUpdateNow: 1-dn: CN=User,CN=Schema,CN=Configuration,DC=Xchangetype: ntdsschemamodifyadd: auxiliaryClassauxiliaryClass: contosoUser-dn:changetype: modifyadd: schemaUpdateNowschemaUpdateNow: 1

生成 .ldif 文件后，您需要在实验环境中对实施进行全面的测试、验证域和林的端对端复制情况，还需要在林中启用架构更新。此时，应以具有“架构管理员”权限的帐户身份登录。您可能希望禁用架构主机（将在其中执行变更）上的出站复制，然后再运行以下命令来导入 .ldif 文件：

ldifde –i –f <Path>\contosoUser.ldif –b<username> <domain> <password> -k –j. –c"CN=schema,CN=Configuration,DC=X"#schemaNamingContext

变更发生后，启用架构主机上的出站复制并验证所有域控制器都已执行复制操作。

来一次深呼吸——大功告成啦！您已在架构中定义了一个新属性，它将与使用用户类（即用户帐户）创建的对象相关联。

要验证变更，请打开 Active Directory 用户和计算机，连接到 employees.contoso.com 域，浏览到用户组织单元 (OU)，创建一个名为 ContosoTestUser 的新用户帐户。现在，打开 adsiedit.msc 控制台并连接到域分区 dc=employees,dc=contoso,dc=com，展开用户组织单元，右键单击 ContosoTestUser，打开“Properties”（属性）页面。浏览查找 contosoEmpShoe 属性。可编辑此属性以输入一个值。也可使用 Ldp.exe 实用工具来验证和修改属性。

现在让我们来看一个定义和链接两个属性的示例，假设 Contoso 非常看重员工的鞋码并希望能通过某种方式跟踪公司中负责测量鞋码的员工的年度表现。这听起来可能有点好笑，但让我们进一步假设，Contoso 不仅希望跟踪负责测量员工鞋码的人员，还希望跟踪他们测量了哪些人的鞋码以及总人数（所有这些都通过查询一个属性来完成）。（您可能会认为此数据更适合存储在数据库表中，但此处只是为了解释前向链接和后向链接的工作机制）。

当然，您会首先执行我在先前的示例中提到过的相同类型的分析。但是，在此我们要继续生成 .ldif 文件 linkids1.ldif 和 linkids2.ldif（如图 6 所示）。然后运行以下命令来导入 .ldif 文件：

Figure 6 前向链接和后向链接 .ldif 文件

 #linkids1.ldif#Attribute definition for Forward Link Attributedn: CN=ContosoShoeSizeTaker,CN=Schema,CN=Configuration,DC=Xchangetype: ntdsschemaaddobjectClass: topobjectClass: attributeSchemacn: ContosoShoeSizeTakerattributeID: 1.2.840.113556.1.8000.9999.2.2LinkID: 1.2.840.113556.1.2.50attributeSyntax: 2.5.5.1isSingleValued: TRUEadminDisplayName: ContosoShoeSizeTakeradminDescription: ContosoShoeSizeTakeroMSyntax: 64searchFlags: 1lDAPDisplayName: ContosoShoeSizeTakersystemOnly: FALSEdn:changetype: modifyadd: schemaUpdateNowschemaUpdateNow: 1-#Reload schema#linkids2.ldif#Attribute definition for Backward Link Attributedn: CN=ContosoShoeSizesTakenByMe,CN=Schema,CN=Configuration,DC=Xchangetype: ntdsschemaaddobjectClass: topobjectClass: attributeSchemacn: ContosoShoeSizesTakenByMeattributeID: 1.2.840.113556.1.8000.9999.2.3LinkID: 1.2.840.113556.8000.9999.2.2attributeSyntax: 2.5.5.1isSingleValued: FALSEadminDisplayName: ContosoShoeSizesTakenByMeadminDescription: ContosoShoeSizesTakenByMeoMSyntax: 64searchFlags: 1lDAPDisplayName: ContosoShoeSizesTakenByMesystemOnly: FALSEdn:changetype: modifyadd: schemaUpdateNowschemaUpdateNow: 1-#Add ContosoShoeSizeTaker and ContosoShoeSizesTakenByMe Attribute as MayContain in #contosoUser classdn: CN= contosoUser,CN=Schema,CN=Configuration,DC=Xchangetype: ntdsschemamodifyadd: mayContainmayContain: ContosoShoeSizeTakermayContain: ContosoShoeSizesTakenByMedn:changetype: modifyadd: schemaUpdateNowschemaUpdateNow: 1-#Add Backward Link Attribute as MayContain in Topdn: CN=Top,CN=Schema,CN=Configuration,DC=Xchangetype: ntdsschemamodifyadd: mayContainmayContain: ContosoShoeSizesTakenByMedn:changetype: modifyadd: schemaUpdateNowschemaUpdateNow: 1

ldifde –i –f <Path>\linkedids<>.ldif –b<username> <domain> <password> -k –j. –c"CN=schema,CN=Configuration,DC=X"#schemaNamingContext

在创建完用户对象后，它还会使 ContosoShoeSizeTaker 和 ContosoShoeSizesTakenByMe 作为其属性。当为某个人员（比如 John）创建用户对象时，ContosoShoeSizeTaker 属性将被填写为测量鞋码人员（即名为 Frank 的人员）的 DN。现在转到 Frank 的用户对象属性并查询 ContosoShoeSizesTakenByMe 属性，结果将包含 John 的以及 Frank 所测量的所有其他人的 DN。在我们方案的最后，管理层会根据 Frank 用户帐户的 ContosoShoeSizesTakenByMe 属性中存在的 DN 总数来奖励他。

系统检查和平衡

如果没有对体系结构需求的检查，将无法执行关键更新（如架构修改）。通过这些一致性检查和安全检查，Active Directory 可以验证无论何时对 Active Directory 执行添加或修改操作，这些变更都不会导致任何不一致情况或其他问题。

首先，每个类的 governsID 值在架构内必须唯一。在定义 schemaClass 对象时，在 systemMayContain、mayContain、systemMustContain 和 mustContain 列表中定义的所有属性必须都已经存在。同时，在 subClassOf、systemAuxiliaryClass、auxiliaryClass、systemPossSuperiors 和 possSuperiors 列表中定义的所有类也必须都已经存在。

并且，systemAuxiliaryClass 和 auxiliaryClass 列表中的所有类的 objectClassCategory 必须为 88 类或 Auxiliary 类。类似地，systemPossSuperiors 和 possSuperiors 列表中的所有类的 objectClassCategory 也必须被指定为 88 类或 Structural 类。

在定义各种类时，Abstract 类只能从其他 Abstract 类继承，Auxiliary 类无法从 Structural 类继承，而 Structural 类也无法从 Auxiliary 类继承。此外，在 rDNAttID 属性中指定的属性必须使用 Unicode 字符串作为其语法并且必须为单值。

这些是与 classSchema 对象相关的一些规则。那 attributeSchema 对象的规则呢？与类的 governsID 值一样，attributeID 的值也必须唯一。同样，mAPIID（如果有）的值也必须唯一。并且，如果存在 rangeLower 和 rangeUpper，rangeLower 必须小于 rangeUpper。attributeSyntax 和 oMSyntax 的值必须匹配。如果属性为对象型语法 (oMSyntax =127)，它必须具有正确的 oMObjectClass。linkID（如果有）必须唯一。此外，后向链接必须有一个对应的前向链接。

如果出了差错该怎么办？

使用新对象（类和属性）对架构进行扩展后，这些新对象将无法再删除。但是，可通过将架构对象的属性 isDefunct 设为 TRUE 来取消激活类或属性。不过对于随 Active Directory 一同提供的作为默认架构一部分的架构对象（“类别 1”对象），将无法取消激活它们。您只能取消激活被添加到默认架构中的对象；即，只有“类别 2”对象能被禁用，并且必须要经过 Active Directory 验证，确认该类未用于任何现有非无效类的 subClassOf、auxiliaryClass 或 possSuperiors 列表中。

如果试图将某个属性设为无效，Active Directory 会检查以确认任何现有非无效类的 mustContain 或 mayContain 中都未使用该属性。可通过将属性 isDefunct 设为 FALSE 来恢复被禁用的对象。如果您的 Active Directory 是在 Windows Server 2003 级别，则可重用被禁用对象的 ldapDisplayName、schemaIdGuid、OID 和 mapiID 值。

总结

在架构中添加或修改类或属性定义涉及到添加或修改对应的 classSchema 对象或 attributeSchema 对象。此过程类似于在 Active Directory 中添加或修改任意对象，不同之处在于需要执行额外的检查来确保变更在今后不会在架构中导致不一致情况或其他问题。

尽管修改 Active Directory 架构非常简单，但必须要了解架构的构成以及它是如何实施这些变更的。对生产型 Active Directory 架构进行任何变更前都需要进行周密的规划，并且执行时务必要小心谨慎。对新对象而言，为其定义业务需求和技术规范并执行大量的实验室测试至关重要。由于变更可能会产生深远的影响，因此建议只有在绝对必要的情况下才扩展 Active Directory 架构。

Vikas Malhotra 就职于纽约的 Microsoft Consulting Services。在 12 年的职业生涯中，他曾与许多大型和中型企业的 IT 组织一起工作，研究他们的基础设施体系结构需求（如目录、消息传递、安全性以及数据联网等）。他拥有电子和电信工程学学士学位以及电信（技术）管理理学硕士学位。可通过电子邮件 vikasmal@microsoft.com 与他联系。

操作系统

扩展 Active Directory 架构