在 Windows Server 2003 中计划和实施联合森林
Windows Server 2003 Standard Edition ；Windows Server 2003 Enterprise Edition ；以及 Windows Server 2003 DataCenter Edition
本页内容
 | 介绍 |
| 范围 |
| 概述 |
| 多森林部署情境 |
| 联合多个森林技术 |
| 部署森林信任需要考虑的事项 |
| 启用 Windows Server 2003 中的多森林方案 |
| 演练 |
| 附录 A 端口列表 |
| 附录 B 白皮书中用到的词汇 |
介绍
Active Directory 森林的概念是在 Microsoft Windows 2000 系列产品中引入的。据推测，大多数单位都是部署一个单独的横跨整个单位的森林。然而，也有很多单位部署多个森林。此外，跨越不同单位的森林进行工作可能需要协作。当这种情况发生时，建立一套外部信任关系需要大量的管理工作而不是最新的技术优势。
森林信任的概念是在 Windows Server 2003 中引入的，用以简化多森林部署。在跨森林时，森林信任允许管理员联合两个 Active Directory 森林，使用一个单独的信任关系来提供一套无缝的身份验证和授权体验。在本白皮书中，将为您介绍部署森林信任常用的方案，森林信任包含的基本概念，以及 Windows Server 2003 中多森林部署包含的技术。
注： 本文档涉及的功能包含在 Windows Server 2003 Standard Edition ； Windows Server 2003 Enterprise Edition ；以及 Windows Server 2003 DataCenter Edition 中。这些功能不包含在运行 Windows Server 2003 Web 版操作系统的计算机上。
范围
本白皮书涉及的范围限制在身份验证，授权以及跨越多森林信任管理相关的概念。 尽管您部署多森林的原因很充分，但本白皮书不宜作为多森林部署决策指南。此外，本白皮书也不讨论如何同步 Microsoft Outlook 地址簿联系人和 Microsoft Exchange Server 公用文件夹。然而，本白皮书提供相关的其他技术信息，如 Microsoft Metadirectory 服务 （MMS） 以及 Exchange Server 公用文件夹复制工具。
概述
在 Windows 2000 中，引入了集成传统 Windows NT Server 4.0 域的 Active Directory 森林的概念。该集成使您得以在森林中的多个域间进行随心的协作。应用系统也可以使用该协作。例如，用户可以搜索 Exchange Server 全球地址列表来定位森林中的其他用户，以便其基于各种属性发送邮件。
集成引入后，很多 Windows NT Server 4.0 的限制都消失了。域之间不再是完全的独立。域之间开始相互依赖，而转移到一个单独的森林需要某种层次上的赞同和不同的域的管理员之间的信任。
在达不到信任层次的地方，必须部署多森林。此外，也有方案针对已经部署多森林的情况，比如并购或者跨企业的协作。 正因为复杂性和单位间缺乏信任，转移到一个单独的森林环境不太可能。
Windows 2000 Server 并不完全提供多森林部署情境。为使身份验证生效，管理员必须建立在一个森林中的每一个域与其他森林中的每一个域的信任。这将导致过多的信任，以至于很难去管理。 此外，由于信任粒度的限制，您要么信任另一个森林中的每一个用户，要么不能信任另一个森林中任何一个用户。在跨企业的方案中，需要更好的粒度方法使您允许其他公司的特定用户获得身份验证。跨企业的信任很可能必须跨越防火墙。 Windows 2000 提供的信任对跨越防火墙的支持是有限的。
在 Windows Server 2003 家族中，引入了森林信任的概念。这个概念使两个森林间的信任成为可能，一个森林的所有域都是信任的一部分。信任粒度的问题通过 选择性身份验证 得到解决，该选项仅允许特定用户或用户群通过信任得到身份验证。管理跨越网络防火墙的信任也变得轻松，因为管理员可以控制为使信任生效而必须开放的特定远程过程调用 （RPC） 端口。
多森林部署情境
您可能因为很多原因需要使用多个森林。在资源所有者之间，在另一个单位管理基础结构的缺乏信任的单位，合并或重组，地理位置分散的业务部门，等等 ，您可能需要不同的架构和政治划分。
您需要部署多森林通常由两个因素。
| • | 您可能因为自主管理的需要而使用多个森林。每个部门都不相信其他部门的管理员（处于政治或安全性的考虑），或者在目录结构和配置方面不能达成一致的共用变更控制策略。 -以及- |
| • | 您可能因为资产隔离而部署多森林。因为安全或者预算原因，通过合并和重组而组成的政府机构以及商业单位有时保持完全独立的计算基础结构；应用服务提供商建立分开的基础结构以便外包大型企业客户的业务。“Design Considerations for Delegation of Administration in Active Directory" 白皮书指出了您可能需要多森林的原因： 因为存储在Active Directory 中和加入到 Active Directory 计算机上的数据不能从目录的服务管理员中隔离，对公司而言，要想达到完全的数据隔离，唯一的办法就是建立一个分开的目录树。 查看 Microsoft TechNet 上的 "Design Considerations for Delegation of Administration in Active Directory" 白皮书，请到 http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/plan/addeladm.mspx |
同一个公司中的多森林
在一个单独的公司中， 首选的方法是部署一个单独的森林。然而，由于前面部分所述的原因，您可能需要部署多森林。在多数方案中，森林应该通过专用的租借线路或者虚拟专用网（VPN） 连接，以保证在森林中传递必需的数据。如果有数据包过滤器或者防火墙，通常都会有“允许全部，拒绝明确定义的” 的方法。两个森林的管理员可能是相同的人，或者不同，但他们可能希望以相同的方式对待其他森林的用户，就像在他们自己森林中的用户。
考虑下面的例子。在 Contoso, Inc. Corporation 中有三个森林： contoso.com， plant.contoso.com，以及 hr.contoso.com。人力资源 （HR） 部门因为有一套需要更改架构的应用程序而拥有自己的森林。 HR 公司的 IT 部门希望不用通过中央的 IT 部门，就可以控制这些更改。此外， hr.contoso.com 森林拥有一个 contoso.com 森林希望排斥在信任关系之外的测试域。
Fabrikam 制造厂也需要运行一套使用 Active Directory 的应用系统。在此方案中，他们需要一个隔离的森林因为域控制器必须放置在工厂厂区；厂内的每一个人在物理形式上都可以访问域控制器。
不同公司的多森林
每一家公司都拥有自己的森林。然而，在一个企业对企业（B2B） 情境中，一家公司森林和另一家公司森林之间的协作是必须的。在此方案中，需要在两个森林间建立信任。然而，每个森林的管理员都希望其他森林的用户只能访问有限的资源。两个森林可能通过专用的租借线路或 VPN 建立连接，但在两个森林间，只能交换有限的数据。因此，防火墙都制定了拒绝全部数据通讯，允许明确定义的通讯规则。
本方案中， Contoso.com 和 Fabrikam.com 已经结成伙伴，共同开拓牙膏和牙刷结合的产品的市场。然而，他们愿意限制市场开拓队伍相互访问对方的项目文件，因为协作是有关市场开拓的。为了让员工清楚概要的进度，两家公司愿意相互开放其内部 Web 站点给另一家公司。
周边网络方案
公司可能需要在周边网络（也称作 DMZ ，非武装区，遮蔽的子网）发布资源并运行需要 Active Directory 的应用系统。然而，我们不建议在周边网络部署一个分开的内部森林的域，因为它在外部域受到安全威胁时，很容易成为威胁整个内部森林的侵入点。因此，如果您希望在一个域中得到所有的管理周边网络服务器的管理和安全收益，就必须在周边网络部署一个分开的森林。
在本方案中， contoso.com 的管理员希望拥有一个分开的森林称作 dmz.contoso.com。在周边网络，他们拥有一套使用 Microsoft .NET Passport 身份验证的 Web 应用系统，这样用户可以获得对门户站点的访问。管理员也希望允许内部森林的用户在周边网络森林发布资源。因此，内部森林的用户需要能够通过使用其内部森林帐户获得到周边网络上资源的访问权。
图3：周边网络方案
联合多个森林技术
这个章节描述了包含在 Windows Server 2003 中解决多森林部署相关问题的技术。
森林信任
森林信任使 Windows Server 2003 中的联合森林成为可能。森林信任使信任可以在两个森林之间的域传递。这种信任是在两个森林根域之间建立的。森林信任可以是单向或双向的信任。在图 4 中，森林 A 和 森林 B 相互之间有一个双向的信任。因此，森林 A 中的用户可以访问森林 B 中的资源，而森林 B 中的用户可以访问森林 A 中的资源。除了身份验证之外，该信任启用了授权，因此每一个森林资源的所有者都可以从其他的森林向任意访问控制列表 （DACL） 和组添加安全主体。
森林 信任要求
在您生成一个森林信任之前，需要核实森林中所有的域控制器的操作系统都是 Windows Server 2003。您也需要确认在适当的位置放置有正确的域名解析系统 （DNS） 基础结构，以及您已经为 Active Directory 建立了适当的功能级别。这意味着森林已被提升到 Windows Server 2003 功能级别，并且您不能再添加任何 Windows 2000 或者 Windows NT Server 4.0 域控制器到森林中。
要生成森林信任， Fabrikam 和 Contoso 中生成信任的人必须在相应的森林拥有企业管理权限。每一个信任都了分配一个密码，管理员在这两个森林都必须知道这个秘码。两个森林中拥有企业管理权限的管理员可以一次生成 Fabrikam 和 Contoso 中的信任。在本方案中，密码是为两个森林随机自动生成并经过加密的。
Windows NT Server 4.0 和 Windows 2000 客户端可以使用森林信任以获得身份验证。然而， Windows NT Server 4.0 客户端仅支持 NTLM 而且不支持用以登录网络的用户主体名称 （UPN） 。
外部信任 与 森林信任
外部信任用在 Windows 2000 中来启用不同森林中两个域的信任。森林信任类似于一个森林根域间的外部信任，但更进一步以包含全部的域。基本的信任信息（包括外部信任和森林信任）由受信任的域对象（TDO）所代表。用于外部信任的 TDO 包含了其他的建立信任的域的名字、其域安全标识符 （SID） 、信任说明、信任类型以及一些其他属性。
当森林信任存在时，信任被标记为 “森林”。TDO 也包含了一些其他的附加 森林信任信息 属性。 森林信任信息 属性包含了关于远程森林中的所有域、目录树名称以及任何可选名称后缀的信息。该信息用于发送身份验证并在需要时查找远程森林。该信息被传播到全局编录，使域控制器就可以搜索。TDO 存储在 Active Directory 域容器中。
目录树名称以及可选的名称后缀存储在 TopLevelName （或者 TLN ） 记录中。DNS 名称，网络基本输入/输出系统 （NetBIOS） 名称，以及每个域的 SID 存储在 DomainInfo 记录中。因此，森林信任包含了足够的信息以适当的判别哪些服务或用户可以驻留在其他森林。
下表说明了外部信任和森林信任之间的关键区别。
表 1 外部信任 与 森林信任
| 外部信任 | 森林信任 | |
TDO | 是 | 是 |
顶层名称 | 否 | 是 |
DomainInfo （每个域） | 否 | 是 |
支持 Kerberos V5 | 有限的支持 | 是 |
浏览对象选取器 | 是 | 是 |
支持 NTLM | 是 | 是 |
UPN 登录 | 只能隐式 UPN | 隐式的和显式的 UPN |
Kerberos 身份验证的路由
在您建立森林信任后，Kerberos 和 NTLM 身份验证因此被路由到其他的森林，这样其他的森林就可以验证用户凭据。
通过使用 Kerberos ，当用户登录到计算机时，会接收到一个授权票证的票证 （TGT） 。当用户需要被认证到一个资源时，TGT 被提交到域控制器，然后域控制器返回一个用于验证的服务票证。这将通过 Kerberos 票证授权服务 （TGS） 请求完成。如果资源在另一个域，用户域控制器就不能讨论范围票证。相反，如果用户拥有与之相关的某个直接信任，域控制器将为其提供推荐以便联系资源域控制器。如果不存在直接信任，域控制器颁发推荐给下一个在信任链中的域控制器。最终的资源域控制器再将颁发服务票证给用户。如果资源是在同一个森林，用户所在的域控制器将通过查询全局编录来判别资源是否在同一森林。
如果资源在另一个通过森林信任连接的森林，全局编录不包含在另一个森林所有资源的信息。然而，通过在全部森林TDO查找森林信任信息，全局编录能够判别哪一个森林包含资源。在该信息被判别之后，推荐被颁发，用户就可以达到本地的森林根。本地森林根将引导 用户到信任的森林根。在推荐到达信任森林后，用户就被授权并被引导到资源域控制器以获得服务票证。
如果一个从受信任的森林来的用户登录到一台位于信任森林的计算机， Kerberos Authentication Service （AS） 请求以相近的方式被路由。然而，在这种情况发生时，用户不必遍历在信任路径中的全部域；用户只需直接引用根域，然后引用另一个森林中包含用户帐户的域控制器。
图5 展示了客户端如何使用 Kerberos 获得认证并在另一个森林得到服务。
1. | 客户端联系域控制器 （DC1） 以请求一张服务票证来使用服务。 |
2. | 域控制器在本域找不到服务，因此域控制器会请求一个全局编录。检验森林信任信息后，全局编录会发送一个服务可能在另一个森林的提示，域控制器会颁发一个推荐到其父结点。 |
3. | 然后客户端联系父根域控制器 （DC2） 以请求一张服务票证来使用服务。根域控制器 （DC2）为 客户端发送一个推荐到其他森林的根域控制器 （DC3） 。 |
4. | 客户端再联系位于另一个森林的根域控制器 （DC3） 以请求一张服务票证来使用服务。在本例中，根域控制器 （DC3） 在讯问全局编录后，判定服务是在其自己的森林内，然后根域控制器 （DC3） 推荐客户端到下个信任路径内的域控制器（DC4）。 |
5. | 客户端再联系被推荐的下一个域控制器 （DC4） （服务域控制器） 以请求一张服务票证。由于该域控制器判定了服务就在本域中，就为客户端颁发了服务票证。 |
6. | 客户端然后在Kerberos KERB_AP_REQ 信息中出示服务票证。服务器接受相应并建立起一条安全信道。 |
对象选取工具是如何工作的
您可以使用对象选取器命令行程序添加用户或组到资源中的 DACLs 或者成为其他组的成员。例如，如果信任森林中的管理员需要从受信任的森林添加用户到信任森林，管理员打开活动目录用户与计算机 Microsoft Management Console （MMC） 管理单元，点击所需的组，然后点击 添加成员。对象选取器就会提示管理员键入远程森林用户的名称。首先，对象选取器会尝试定位用户所在的域。因为用户来自另一个森林，在本地的森林全局编录中是找不到用户名称的。全局编录再检查森林信任信息以判定被请求的对象是否在不同的森林。如果该对象可能在不同的森林，一张推荐将被发送给对象选取器以联系其他森林中的全局编录。对象选取器再联系远程森林的全局编录以权威的判定哪个远程森林域包含所需的对象。判定后，对象选取器连接到该域的域控制器然后执行轻量目录访问协议 （LDAP） 以查找该对象的某些属性，如其安全标识符 （SID）。获得信息后，您可以设置 DACL 或者更改组成员信息。
运行 Microsoft Windows XP 及其后发布的操作系统的计算机均支持从受信任的森林选取对象的对象选取器。注意您在使用对象选取器来从受信任的森林来选取对象时，必须输入用户或组的 UPN 全称。运行 Windows Server 2003 的计算机支持通过使用通配符进行搜索的对象选取器浏览功能。
注意，如果您希望从远程森林查找用户，您必须拥有远程森林的凭据。如果信任是双向的，那么远程森林也信任本地的森林，就可以使用本地的森林凭据。如果本地的森林仅信任远程森林，对象选取器就会提示本地森林的远程森林用户凭据。
注： 组成员规则将防止产生包含其他森林成员的通用和全局组。
最好的 Active Directory 实践就是在每个域都有一个全局组，并把这些全局组添加到一个在资源域中的域本地组。
SID 过滤
当授权数据请求从受信任森林传来时，您信任该森林拥有适当的经验证的用户凭据。然而，您也会接收到以安全标识符 （SID） 列表为形式的授权信息和身份验证请求。如果 SID 符合该信任森林企业管理员的 SID （相似的权限或用户 SID ），那么这个来自受信任的森林的用户将得到较高的资源权限。为了防止通过签署假冒的 SID 产生受信任的森林，操作系统会经常过滤 SID 以验证其是否与受信任的森林中的一个域 SID 相关。这个过程确保受信任的森林仅颁发授权信息给授权的域。例如，当 fabrikam.com 森林的根域域控制器接收到了来自客户端的请求是，系统将过滤请求 SID 来验证客户端没有使用未授权的 SID （请看图 5 中的步骤 4 ）。经过森林信任时， SID 过滤功能是自动启用的。
SID 过滤功能打破了跨森林的 SID 历史。如果某个来自 fabrikam.com 森林的用户迁移到了 contoso.com 森林，该用户在 contoso.com 的 SID 历史将包含其在 fabrikam.com 森林中帐户的 SID 信息。当用户试图通过使用帐户访问位于 fabrikam.com 森林中的资源时， fabrikam.com 帐户 SID 和从 contoso.com 发来的帐户 SID 一同展示出来。 fabrikam.com 根域域控制器判定用户提供的 fabrikam.com 帐户 SID 未被授权转成 contoso.com 森林的用户帐户，于是就过滤掉了。SID 过滤功能打破了 SID 的历史，因为用户不能访问该用户以前的帐号资源。
如果受信任的森林管理员可以被信任而不会发生假冒的未经授权的 SID ，您可以通过禁用 SID 过滤功能而启用 SID 历史。禁用 SID 过滤功能，可以使用 Netdom 工具 （Netdom.exe） ，其包含在 Windows Server 2003 支持工具中。您可以从Windows Server 2003 CD-ROM中Support\Tools 文件夹中安装 Windows Server 2003 支持工具。右击 Support\Tools 文件夹中的 Suptools.msi 文件再点击 安装。
为获得更多有关 SID 过滤功能的信息，请查看 http://support.microsoft.com。
选择性身份验证
该 选择性身份验证 选项概念性的类似于网络防火墙的工作方式。与网络防火墙仅允许特定的网络访问请求通过防火墙类似， 选择性身份验证 选项仅允许特定的身份验证请求。获得更多有关如何启用 选择性身份验证 选项的信息，请查看本文中“演练”的部分。
信任粒度问题
当用户从一个受信任的森林用户获得授权时，这些用户在其森林接收到经身份验证的用户 SID （ Authenticated Users SID）。用户的很多默认的在森林中的权限都是通过经身份验证的用户 SID 赋予的。因为经身份验证的用户组是一个计算的组而且其 SID 被添加到用户身份验证服务器上，您就不能改变组的成员信息。因此，来自森林的用户拥有一些对信任森林全部资源默认的权限，在您建立起森林信任后，这些资源对经身份验证的用户都是可以访问的。如果在受信任的森林中，只为一小群用户建立信任，您可能就不需要这样做了。
解决方案
该 选择性身份验证 选项提供了一种方法，您可以使用该方法来获得更好的用于跨信任森林的身份验证请求粒度。当您启用了 选择性身份验证 选项，全部的身份验证都将通过服务域控制器检查。在运行验证请求通过前，该服务域控制器将明确允许到资源的验证通过用户验证。因此，您需要明确哪些跨信任森林的用户可以允许经过到域内资源的验证。这在您启用跨信任森林 选择性身份验证 选项时是需要的。如果您为某些特殊的来自其他森林或域的用户或组设置了“允许身份验证”控制访问权限，您可能就不需要这样设置了。当跨信任森林的用户验证使用 选择性身份验证 选项时， “其他组织” SID 被添加到用户授权数据中。这个 SID 的存在触发了在服务域上的验证，用以确保用户允许通过验证来获得特定的服务。在用户通过验证之后，用户验证通过的服务器将添加另一个 SID，即“本组织” SID。（如果“其他组织” SID 未被提供，该“本组织” SID 就被添加进来。）例如，假若用户未跨信任森林验证，启用 选择性身份验证 选项，这时就将显示“本组织” 标识。正因如此，这些特殊 SID 中只有一个可以显示在用户的相关资料中。
信任端口配置
信任需要跨越多种网络边界进行部署。因此，信任可能需要跨越一个或多个防火墙。需要跨越防火墙时，您要么通过隧道穿过防火墙，要么打开防火墙特定的端口来允许信任的数据流量通过。在 Windows Server 2003 中，这个过程通过配置远程过程调用 （RPC） 端口而使主要的信任服务得到简化。
| • | 本地安全认证 （LSA） RPC 端口。该端口用于生成信任和其他到 LSA 策略数据库的访问： TCP/IP 端口 条目在 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters 注册表项。 -以及- |
| • | Netlogon RPC 端口。该端口用于 NTLM 和安全隧道： DCTcpipPort 条目在 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters 注册表项。 查看全部有关针对不同方案可以打开的端口，请浏览本文附录 A 中“端口列表”一章。 |
部署森林信任需要考虑的事项
本部分讨论在您部署森林信任时，需要考虑的各种各样的事项和需要谨记的最佳实践。
UPN 需要考虑的事项
当您部署森林信任时，为跨越多森林，您可以使用确切的 UPN 后缀。在使用外部信任跨越多森林时，您可能不需要使用确切的 UPN 后缀。希望使用确切 UPN 后缀的管理员应该认真规划其 UPN 结构来跨越森林。跨越森林的 UPN 后缀应该唯一并不被重叠。
您可以使用重叠的 UPN 后缀，比如在 plant.contoso.com 和 contoso.com，但您也必须使用 TopLevelName Exclusion （TLNEx） 记录。这是因为 contoso.com 的 TopLevelName 记录（UPN 后缀和受信任的树名或者在本地森林中被存储为 TopLevelName 记录的信任森林） 声明了所有在 contoso.com 之下的命名空间，包括 plant.contoso.com。因此，在哪里对一个命名请求进行路由会引发矛盾，比如 服务器.plant.contoso.com。为确保请求被发送到正确的森林，所有拥有 contoso.com 信任的森林为该信任都应该添加一个 TopLevelName Exclusion 记录到 plant.contoso.com。TopLevelName Exclusion 记录指明了在 plant.contoso.com 之下的命名请求都不应该被路由到那个森林。TopLevelName Exclusion 记录增加了一级复杂度，因此建议管理员选择不要重叠 UPN 后缀。
当您使用森林信任时，禁止使用共享的 UPN 后缀，比如都声明了 contoso.com 的两个森林。在其森林（用户仅能使用 UPN 后缀来登录他们帐号所在的相同的森林）仅想使用共享的 UPN 后缀来登录的管理员必须删除块约森林的后缀定义并仅能在用户对象上定义 UPN 属性。这意味着您不能在用户对象上通过活动目录用户和计算机 MMC 管理单元用户界面 （UI） 设置 UPN 属性。因此，您必须以编程方式写入属性到用户对象中。当您通过活动目录用户和计算机 MMC 管理单元删除跨森林的 UPN 后缀定义时， UPN 后缀不被传递到其他共享后缀的森林，因此结果不会冲突。（注意，冲突是在两个森林声明了相同的 TLN 时产生的。） 如果还是发生了冲突，森林信任将被停用。注意，如果两个森林都声明了相同的命名空间，您不能设置排除记录。 （例如，如果两个森林都声明了 contoso.com。）通过这种方法，您不能使用共享的 UPN 来登录跨域的森林。因此，您只能在登录另一个森林（而不是用户所在的森林）内的计算机窗口最小化时使用此方法。注意，在您使用共享的 UPN 登录到一台位于另一个森林的计算机而成为组员后，就可以获得到资源的无缝访问。
限制森林信任范围需要考虑的事项
您有两种方法可以限制哪些用户可以从受信任的森林获得到森林的访问：
| • | 您可以在用户界面中禁用相应域的 DomainInfo 记录或者目录树的 TopLevelName 记录。这种方法仅在只有一小部分其他森林不被信任时有效。注意，当您禁用 DomainInfo 记录时，只有该域用户的身份验证请求被禁止。当您禁用一个 DomainInfo 记录时，如果身份验证请求来自本地森林的用户，而这些用户希望获得在禁用域内资源的访问，那么该身份验证请求并没有被禁用。 -或者- |
| • | 您可以使用 选择性身份验证 选项。该选项在您只希望允许一小部分用户访问时有效。如果有大量的用户希望获得大量资源的访问，将很难管理请求并赋予用户“允许身份验证”的权限。注意只有拥有 Active Directory 中资源 Write_DAC 权限的用户才有资格设置权限。该权限被严格限制在域管理员组和生成该对象的委派管理员。注意，当一个用户通过“添加工作站到域”权限而将一台计算机添加到域中时，用户并未接到 Write_DAC 权限，因此该用户不能在其已加入的计算机中授予其他森林用户“允许身份验证”的权限。 |
智能卡登录时需要考虑的事项
对于使用智能卡登录并跨越森林工作的用户，必须拥有公共密钥基础结构 （PKI） 信任和森林信任。这意味着用户要登录的森林必须信任为用户提供智能卡登录的 证书颁发机构（CA） 。此外，用户要登录的计算机必须信任用户所在域的域控制器颁发的计算机证书以获得服务器身份验证。您可以通过两种方法实现：使该 CA 成为受信任的根 CA，或者通过合格的从属。
迁移时用户体验的变化 森林 来自外部信任的信任
用户体验在迁移到森林信任后会有某些变化。为使这些变化最小并确保计算机拥有一致的体验，您可能需要升级运行 Windows XP、Windows 2000 或者 Windows NT Server 4.0 的计算机到最新的补丁。您可能还需要部署适当的 QFE。以下列表说明了服务补丁的效用和 QFE：
| • | Windows 登录及身份验证：当用户登录到一台加入到森林的计算机上时， 而不是登录到用户帐户所在的森林时，用户在登录对话框中看不到帐户域列表。用户必须在对话框中输入其用户主体名称 （UPN）。这可能是隐式的 UPN 后缀 （user_ID@DNS_domain_name.com） 或者一个管理员显式定义的 UPN 后缀，如： someone@fabrikam.com。如果您希望以 Windows NT Server 4.0 风格名称登录，您需要申请相应的 QFE 到计算机上。注意：如果在其他森林的域没有显示在登录对话框窗口中，您必须输入形如 domain\user 的名称到对话框中。如果您的用户当前尚未使用 UPN 登录，让他们使用 Windows NT Server 4.0 风格以使用户登录体验一致。 |
| • | 授权：在未运行 Windows Server 2003 或者 Windows XP Service Pack 2 （SP2） 的计算机上，您无法浏览其他森林的主体来添加到 DACL 和组。相反，您可以输入位于其他森林主体的 UPN 或者 Windows NT Server 4.0 名称。在运行 Windows Server 2003 或者 Windows XP SP2 的计算机上，可以浏览并查找在其他森林中的主体。您必须运行 Windows 2000 Service Pack 4 （或者下述的 QFE ）或者 Windows XP 以解决在对象选取器工具中使用 UPN 或者 Windows NT Server 4.0 名称查找位于其他森林中主体的问题。在运行 Windows NT Server 4.0 的计算机上，您可以输入 Windows NT Server 4.0 风格名称来查找位于其他森林的用户。在运行 Windows 95，Windows 98，或者 Windows Millennium Edition （Me） 的计算机上，您可以通过浏览用户的域来选择域，然后选择用户。 Microsoft Exchange Server 5.5 管理员以及 Microsoft SQL Server 2000 管理员在选择用户时，必须显式输入 Windows NT Server 4.0 风格的名称以添加 Windows 用户，通过邮箱关联用户，然后启用 SQL 服务器帐号。注意，您不能浏览其他森林的用户。 |
下表说明了普通用户从外部信任迁移到森林信任的体验。
登录及身份验证
| Windows 95、Windows 98、Windows Me | Windows NT Server 4.0 | Windows 2000 | Windows XP | Windows Server 2003 | |
登录框 | 未变化 | 增加了启用 Windows NT Server 4.0 风格命名的 QFE | 使用 UPN 名称登录并增加了启用 Windows NT Server 4.0 风格命名的 QFE | 使用 UPN 名称登录并增加了启用 Windows NT Server 4.0 风格命名的 QFE | 使用 UPN 名称登录并增加了启用 Windows NT Server 4.0 风格命名的 QFE |
共享（用户界面） | 未变化 | 未变化 | 未变化 | 未变化 | 未变化 |
共享（命令提示） | 未变化 | 未变化 | 未变化 | 未变化 | 未变化 |
Microsoft Internet Explorer | 未变化 | 未变化 | 未变化 | 未变化 | 未变化 |
Outlook | 未变化 | 未变化 | 未变化 | 未变化 | 未变化 |
Microsoft Internet Information Server （IIS） | 不支持 | 未变化 | 未变化 | 不支持 | 未变化 |
Exchange Server 5.5 | 不支持 | 未变化 | 未变化 | 不支持 | 不支持 |
Exchange 2000 Server | 不支持 | 不支持 | 未变化 | 不支持 | 不支持 |
Microsoft Exchange Titanium | 不支持 | 不支持 | 未变化 | 不支持 | 未变化 |
受信任的森林中的域 DFS | 不支持 | 不支持 | 不支持 | 不支持 | 未变化 |
SharePoint Team Services from Microsoft 1.0 | 不支持 | 不支持 | 未变化 | 不支持 | 未变化 |
Microsoft SharePoint Portal Server 2001 | 不支持 | 不支持 | 未变化 | 不支持 | 未变化 |
Microsoft SQL Server 7.0 | 不支持 | 未变化 | 未变化 | 不支持 | 不支持 |
SQL Server 2000 | 不支持 | 未变化 | 未变化 | 不支持 | 未变化 |
组策略 | 不支持 | 不支持 | 未变化 | 未变化 | 未变化 |
查找并授权
| Windows 95、Windows 98、Windows Me | Windows NT Server 4.0 | Windows 2000 | Windows XP | Windows Server 2003 | |
对象选取器工具 | 不支持 | 未变化 | 升级到最新的服务补丁并申请最新的 QFE，然后输入 UPN 或者 Windows NT Server 4.0 名称 | 输入 UPN 或者 Windows NT Server 4.0 名称，升级到 SP2，然后浏览 | 未变化 |
共享（用户界面） | 需要更改用户可以被选的域 | 未变化 | 未变化 | 未变化 | 未变化 |
共享（命令提示） | 不支持 | 未变化 | 未变化 | 未变化 | 未变化 |
IIS | 不支持 | 未变化 | 未变化 | 不支持 | 未变化 |
Exchange Server 5.5 | 不支持 | 需要输入名称 | 需要输入名称 | 不支持 | 不支持 |
Exchange 2000 Server | 不支持 | 不支持 | 未变化 | 不支持 | 不支持 |
Exchange Titanium | 不支持 | 不支持 | 未变化 | 不支持 | 未变化 |
SharePoint Team Services from Microsoft 1.0 | 不支持 | 暂缺 | 未变化 | 不支持 | 未变化 |
SharePoint Portal Server 2001 | 不支持 | 暂缺 | 当您升级到最新的服务补丁并应用了最新的 QFE 时，或者当您应用了 SharePoint Portal Server QFE 时，均没有变化 | 不支持 | 未变化 |
SQL Server 7.0 | 不支持 | 未变化 | 未变化 | 不支持 | 不支持 |
SQL Server 2000 | 不支持 | 需要输入名称 | 需要输入名称 | 不支持 | 未变化 |
启用 Windows Server 2003 中的多森林方案
以上章节讨论的 Windows Server 2003 技术，每一种技术都启用了一项在跨越多森林过程中用到的特定的功能。注意这些技术限于信任管理、身份验证以及授权问题。
您必须使用其他技术和工具来解决问题的其他部分，如地址簿的同步、用户迁移、DNS 配置等等。以下部分描述了您如何使用本文论及的每一项技术来实现本文前面论述的跨越多森林方案。以下部分也提到了在解决问题的其他部分中用到的工具。
同一个公司中的多森林
当您希望在同一公司中部署多森林时，您应采取的第一步是确保您可以从一个森林执行到位于另一个森林的域控制器的 DNS 查询。如果森林已经可以使用相同的 DNS 基础结构，那么您就不需要执行额外的工作。如果该森林不使用相同的 DNS 基础结构，您要么合并 DNS 基础结构，或者您可以使用条件转发。获得更多信息，请查看 “多森林需要考虑的事项” 设计指南，地址：http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=71242E3A-EC89-480A-8DF5-2C379A1E560F。
在您配置完 DNS 之后，在 contoso.com 和 hr.contoso.com 森林之间建立一个双向的森林信任。因为 plant.contoso.com does 不包含任何要想获得在另一个森林资源访问所需的用户帐户，信任就是由管理员为其他森林建立的一种办法。在本方案中，您不应该启用 选择性身份验证 选项， 因为在每一个森林都有大量的用户希望能够访问其它森林中的资源，也因为每个森林把其他森林的用户当作验证的用户来对待会使管理员感觉很好。另外，当用户使用 Exchange Server 地址簿来发送电子邮件信息时， contoso.com 森林的用户应该能够查找 hr.contoso.com 森林的用户。通过使用 Microsoft Metadirectory 服务 （MMS） 来同步两个森林的地址簿就可以实现上述功能。有关 MMS 的更多信息，请查看“多森林需要考虑的事项”设计指南，其位置在 Microsoft Web 站点 http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=71242E3A-EC89-480A-8DF5-2C379A1E560F。
基于 plant.contoso.com TopLevelName， hr.contoso.com 森林信任 plant.contoso.com 森林；而基于 contoso.com TopLevelName ，hr.contoso.com 森林也信任 contoso.com 森林，因此 TopLevelName 记录包含了 contoso.com ，也包括 plant.contoso.com ，就产生了命名空间的冲突。为删除冲突，您必须从 contoso.com 森林信任中排除 plant.contoso.com 命名空间。您可以通过在 FTInfo 中设置 TopLevelName 排除记录来给 hr.contoso.com 森林设置信任到 contoso.com。同样的，您必须在 plant.contoso.com 森林建立另一个排除记录来排除从 contoso.com 森林到 hr.contoso.com 命名空间的信任。然而，您不需要建立 contoso.com 中的排除记录，因为 plant.contoso.com 和 hr.contoso.com 命名空间并不重叠。
此外，contoso.com 森林的管理员也不想信任 test.hr.contoso.com 域。该域是 hr.contoso.com 森林中的测试域。因此，管理员可以禁用 test.hr.contoso.com 域的 DomainInfo 记录，而 test.hr.contoso.com 域是受 hr.contoso.com 信任的。当您做此工作时，您需确认由 test.hr.contoso.com 域授予的身份验证不为 contoso.com 接受。注意您可以很轻松地使用森林信任中的 明确拒绝 选项，而不是使用本方案中的 选择性身份验证 选项，因为您希望排除从受信任的森林中的特定域到任何在信任森林的资源的主体的身份验证。注意当您为一个受信任森林中特定的域禁用 DomainInfo 记录时，您也要禁用来自该域中的用户身份验证请求。当您做此工作时，该域中到资源的身份验证并没有被禁用。
不同公司间的多森林
当您部署不同公司间的多森林时，会遇到特别的挑战。不只是信任要穿过防火墙，您还要确保所有的资源得到很好的管理，这样来自其它森林的用户就不会意外地访问到他们不应该访问到的资源。
在本方案中，Fabrikam 和 Contoso 建立了森林信任。每家公司也都启用了 选择性身份验证 选项。当管理员启用 选择性身份验证 选项时，跨信任森林出现的身份验证不会自动运行。管理员必须明确启用跨森林信任的身份验证。 Contoso 森林的管理员再在市场开拓组的文件服务器计算机帐户中设置 DACL ，以便 Fabrikam 森林中市场开拓组的成员能够通过身份验证。之后，管理员给 Web 服务器服务帐户中设置另一个 DACL ，以便拥有“经身份验证的用户 SID” 的用户能够访问该资源。 Contoso 森林的管理员以 Fabrikam 管理员配置 fabrikam.com 相同的方式配置 contoso.com 森林。注意这些森林中可能会有外网森林。
Contoso 和 Fabrikam 的管理员都独立使用 Netdom 工具 （Netdom.exe） 建立了信任。在管理员建立信任之后，他们试图验证信任，这样在此操作过程中的 Netlogon 固定端口和 RPC Endpoint 映射器 端口可以被开放（在每个域的域控制器之间）。管理员可以在验证信任合法之后关闭端口。Contoso 和 Fabrikam 的管理员接下来就可以创建防火墙规则。
| 规则名称 | 端口 | 源 | 目的地 |
Kerberos 身份验证入站 | 88 （UDP， TCPinbound） | 其他公司的子网 | 该公司的域控制器 |
Kerberos 身份验证出站 | 88 （UDP，TCPoutbound） | 该公司的子网 | 其他公司的域控制器 |
入站 DACL 查找 | 88 （UDPinbound）、 389 （TCP，UDPinbound）、135 （TCPinbound）、NTDS固定端口 （TCPinbound）、Netlogon固定端口 （TCPinbound） | 其他公司的子网 | 该公司的域控制器 |
出站 DACL 查找 | 88 （UDPoutbound）、389 （TCP，UDPoutbound）、135 （TCPoutbound）、NTDS固定端口 （TCPoutbound）、Netlogon固定端口 （TCPoutbound） | 该公司的子网 | 其他公司的域控制器 |
防火墙规则启用了公司间身份验证和查找的功能。注意管理员仍然可以为通讯选择一个 Internet 协议安全 （IPSec） 隧道，正如前面表格提到的只需打开 IPSec 端口。大多数 Windows 默认的服务都使用协议包，该协议包都先使用 Kerberos 来身份验证，如果不能正常工作，再使用 NTLM。如果您也需要 NTLM 身份验证，您必须打开相关的端口。这些端口在本文附录 A 中 “端口列表”部分进行了描述。
周边网络方案
在周边网络（也称作 DMZ ，非武装区，遮蔽子网）森林，从周边网络森林到 contoso.com 公司森林单向的信任被建立起来。内部森林用户可以使用其内部森林帐户来获得到周边网络森林资源的访问。在本方案中，不建议双向信任，因为周边网络森林有可能给恶意用户提供攻击点而危及整个公司森林的安全。因此，管理员建立了如下的防火墙规则。
| 规则名称 | 端口 | 源 | 目的地 |
信任的建立 | 88 （UDP, TCPoutbound）、389 （UDP, TCPoutbound）、 445 （TCPoutbound） | 其他公司的子网 | 该公司的域控制器 |
Kerberos 身份验证出站 | 88 （UDP, TCPoutbound） | 该公司的子网 | 周边网络域控制器 |
入站 DACL 查找 | 88 （UDP, TCPinbound）、389 （TCP, UDPinbound）、135 （TCPinbound） NTDS 固定端口 （TCPinbound）、Netlogon 固定端口 （TCPinbound） | 周边网络子网 | 内部域控制器 |
本表中：
| • | 只有在信任是初次建立时，管理员需要应用“信任的建立”规则。该规则使从域内部森林建立的信任在建立信任后即刻实效。 |
| • | “Kerberos 身份验证出站规则” 通常应用在管理员允许内部用户通过周边网络森林的身份验证。 |
| • | “入站 DACL 查找”规则由管理员仅在周边网络中从森林添加全局或通用组中改变域本地组时应用。 |
演练
以下部分提供了您可用于实施联合森林相关步骤的详细信息。
演练建立
本演练中涉及的森林结构在下图中详细列出。
每个域都有一个域控制器，而且域控制器的名称是 CORP-DC-01， NW-DC-01以及 MARKETING-DC-01。CORP-DC-01 和 NW-DC-01 域控制器 集成在各自森林的 Active Directory-集成 DNS 服务器中。
建立森林信任
开始建立森林信任之前，您需要确保所有的域控制器运行 Windows Server 2003 操作系统。为建立森林信任，请使用本章中的方法来执行以下任务：
| • | 准备信任的双方森林
| ||||
| • | 建立 contoso.com 的森林信任 | ||||
| • | 建立 nwtrader.com 的森林信任 |
配置 DNS
本章为您提供了用以建立森林信任，进行配置 DNS 所需的步骤。
情境
Northwind Traders 和 Contoso 公司的管理员都需要通过配置 DNS 建立两个森林的网络连接。每个森林 Active Directory-集成的 DNS 区域都位于其各自的根域。
为配置 DNS：
1. | 使用管理员权限登录到 corp.contoso.com 域。 | ||||||||
2. | 配置 DNS：
| ||||||||
3. | 验证连接：
|
提升所有的域和所有的森林到 Windows Server 2003 功能级别
本章节描述如何提升森林功能级别到建立森林信任所需的 Windows Server 2003。为此，您必须首先提升森林中的每个域的域功能级别到 Windows Server 2003 功能级别。在您提升森林中所有的域到 Windows Server 2003 功能级别后，您可以提升森林到 Windows Server 2003 功能级别。
情境
Northwind Traders 和 Contoso 公司的管理员希望提升其森林到 Windows Server 2003 功能级别来建立森林信任。
为提升所有的域和森林到 Windows Server 2003 功能级别：
在 corp.contoso.com 域的域控制器上：
1. | 使用 “Active Directory 域和信任” MMC 管理单元，设置 corp.contoso.com 域的功能级别到 Windows Server 2003：
| ||||||||||
2. | 使用 “Active Directory 域和信任” MMC 管理单元设置森林功能级别到 Windows Server 2003：
| ||||||||||
3. | 使用 “Active Directory 域和信任” MMC 管理单元提升森林功能级别到 Windows Server 2003：
|
在 nwtraders.com 域的域控制器中：
1. | 使用 “Active Directory 域和信任” MMC 管理单元提升 nwtraders.com 域功能级别到 Windows Server 2003 ：
| ||||||||
2. | 使用 “Active Directory 域和信任” MMC 管理单元提升森林功能级别到 Windows Server 2003：
|
实现跨森林的信任
本章节描述了如何实现森林信任。
启用身份验证和授权 （跨森林的）
Northwind Traders 和 Contoso 公司的管理员都希望启用跨森林的身份验证和授权。两家公司都希望其森林的用户可以无缝的获得到位于其他森林资源的访问，而不用必须输入新的用户和密码。因此，两家公司必须建立跨目录令的双向信任。
为启用跨森林的身份验证和授权：
| • | 验证到 Nwtraders.com 域的连接：
| ||||||||||||||||||||||||||||
| • | 建立森林信任：
| ||||||||||||||||||||||||||||
| • | 创建在 Marketing.contoso.com 域的文件共享，然后指定共享权限：
| ||||||||||||||||||||||||||||
| • | 确认您可以获得到 Marketing-DC-01 域和您创建的文件 SampleText.txt 的访问：
|
添加别名后缀
Contoso.com 森林的管理员希望根据用户电子信箱的名称添加别名后缀。这允许用户使用其电子信箱的名称，比如 user@e-mail.contoso.com 来登录到网络。使用该后缀的用户在其他森林必须能被识别。
遵照以下步骤来添加别名后缀，添加名称后缀到用户的 UPN 名称，然后再启用到别名后缀的路由：
| • | 添加别名后缀到 corp.contoso.com 域：
| ||||||||||||
| • | 在 corp.contoso.com 域中添加别名后缀到用户 UPN ：
| ||||||||||||
| • | 启用别名后缀到 nwtraders 域的路由：
|
排除来自某个信任关系的域
Nwtraders.com 森林的管理员不再希望通过 marketing.contoso.com 子域获得信任关系，因此管理员希望排除来自该信任关系的域。
排除来自某个信任关系的域：
| • | 创建一个在 nwtraders.com 域的文件共享：
| ||||||||||||||||||
| • | 在 nwtraders.com 域中禁用 marketing.contoso.com 的 DomainInfo 记录 ：
|
建立 TopLevelName 排除记录
Contoso.com 森林的管理员希望与 nwtraders.com 森林及其所属的全部命名空间建立信任关系，但 plant.nwtraders.com 除外。注意 plant.nwtraders.com 森林是一个本情境中未使用的假定的森林，因为属于不同的位置，也因为 contoso.com 森林的管理员希望与之建立信任关系。
建立一个 TopLevelName 排除记录：
| • | 使用管理员权限登录到 corp.contoso.com 域控制器。 |
| • | 点击 开始，指向 所有程序，指向 管理工具，再点击 活动目录域和信任。 |
| • | 右击左侧窗格的 corp.contoso.com ，再点击 属性。 |
| • | 点击 信任 标签， 右击 Nwtraders.com （在 该域信任的域（待发信任） 对话框中），再点击 属性。 |
| • | 点击 命名后缀以排除到 nwtraders.com 的路由 标签，点击 添加，输入 *.plant.nwtraders.com，点击 确定，再点击 确定。 |
选择性身份验证选项
由于安全限制， Contoso 公司的管理员决定不允许 Northwind Traders 森林中的任何用户在该森林中进行身份验证。Contoso 公司的管理员希望只允许来自其他森林的企业管理员组的成员进行身份验证，但只限于 marketing.contoso.com 域。
启用 选择性身份验证 选项：
| • | 转到 corp.contoso.com 中的 选择性身份验证 选项，以仅启用来自 nwtraders.com 的选择性身份验证
| ||||||||||||||
| • | 在 marketing.contoso.com 域创建一个新的文件共享并为其分配权限：
| ||||||||||||||
| • | 验证您已经无法从 Nwtraders.com 访问 Marketing.contoso.com ：
| ||||||||||||||
| • | 启用 选择性身份验证 （为 Marketing-DC-01）：
| ||||||||||||||
| • | 确认您可以获得从 nwtraders.com 到 marketing.contoso.com 的访问：
|
配置 ISA Server 2000 以启用跨防火墙的森林信任
本章节描述如何配置 Microsoft Internet Security and Acceleration （ISA） Server 2000 来启用跨防火墙的信任和身份验证 。
建立信任
建议您为来自内部的计算机森林建立信任，因为当您建立信任时，该方法需要从内部防火墙网络到外部的连接。为此， 打开 ISA Server 防火墙客户端允许来自内部域控制器的数据与外部域控制器通过 LDAP （389 UDP 和 TCP）以及 Microsoft SMB （445 TCP）端口进行通讯。您只能在建立森林信任时使用上述功能，因此在您建立完成信任关系后需要关闭 ISA Server 防火墙客户端。您还需要添加另一个规则以允许 Kerberos （88 UDP） 通讯。您必须保持该规则以使身份验证请求能够通过防火墙。在 ISA Server SP1 防火墙客户端上使用该过程：
1. | 点击 开始指向 所有程序指向 Microsoft ISA Server，再点击 ISA 管理。 | ||||||||||
2. | 在控制窗格，点击展开 服务器和阵列，点击以展开服务器，点击以展开 访问策略，点击 协议规则，然后， 在结果窗格，点击 新建协议规则。 | ||||||||||
3. | 输入该协议的名称，如 allow xforest setup，再点击 下一步。 | ||||||||||
4. | 点击 允许，再点击 下一步。 | ||||||||||
5. | 在 添加该规则到列表 对话框，点击 选中的协议，点击以清除 仅显示已选中的协议 复选框，点击以选中 Kerberos-Sec（UDP） 复选框，再点击以选中 LDAP 复选框，再点击 下一步。 | ||||||||||
6. | 在 使用该时间表 对话框，点击 始终，再点击 下一步。 | ||||||||||
7. | 在 应用该规则到请求 对话框，点击 任何请求，点击 下一步，再点击 完成。 | ||||||||||
8. | 为 Microsoft-DS 和 LDAP UDP 新建协议定义（默认没有定义）：
| ||||||||||
9. | 为 Microsoft-DS 添加协议定义：
| ||||||||||
10. | 创建规则后，重新启动防火墙服务以应用该规则：
| ||||||||||
11. | 从内部计算机建立跨森林的信任所应采用的步骤已在本文前面“实施跨森林的信任”部分得到描述。 | ||||||||||
12. | 因为不再需要该信任建立规则，删除这些规则。 | ||||||||||
13. | 在控制台树，点击以展开 服务器和阵列，点击您的服务器，点击 访问策略，再点击 协议规则。 | ||||||||||
14. | 双击 Allow xforest setup， 再点击以清除 启用 复选框。 | ||||||||||
15. | 重新启动防火墙服务以去掉该规则。 |
信任验证及网络登录
如果您希望共享信任验证及网络登录给外部计算机，您必须开放某些端口。在协议规则中，您必须打开 LDAP UDP， Kerberos sec UDP，Any RPC 服务器，DCE 终结点解析出站，以及 Microsoft-DS出站端口。此外，您还必须公开在内部森林域控制器中的 LDAP UDP 和 Any RPC 服务器端口。为此，需要您：
1. | 点击 开始，指向 所有程序，指向 Microsoft ISA Server，再点击 ISA 管理。 | ||||||||||||||
2. | 在控制台树，点击以展开 服务器和阵列，点击以展开您的服务器，点击以展开 访问策略，再点击 协议规则。 | ||||||||||||||
3. | 点击 新建协议规则。 | ||||||||||||||
4. | 输入规则名称（如 allow xforest validation），点击 下一步，点击 允许，再点击 下一步。 | ||||||||||||||
5. | 在 应用该规则到 列表，点击 选中的协议，再点击以清除 仅显示选中的协议 复选框。 | ||||||||||||||
6. | 点击以选中以下全部的复选框：
| ||||||||||||||
7. | 确认您所创建的四个定义（DCE 终结点解析， LDAP TCP 入站， LDAP UDP 入站， 以及 Kerberos UDP 入站）的复选框都已选中，其他的复选框已被清除，再点击 下一步。 | ||||||||||||||
8. | 选择您的时间表，再点击 下一步。 | ||||||||||||||
9. | 要么选择使该规则仅适用于部分特定的客户端，要么适用于全部客户端，点击 下一步，再点击 完成。 | ||||||||||||||
10. | 为 DCE 终结点解析、LDAP TCP 入站、LDAP UDP入站以及 Kerberos UDP入站定义的协议在默认情况下是不提供的，因此您必须自己创建。注意 LDAP UDP入站 和 Kerberos UDP入站都只在下一部分。创建协议定义：
| ||||||||||||||
11. | 为入站发布端口：
|
对象选取器：允许服务管理员建立 DACL
为让对象选取器工作，您必须发布 Any RPC 服务器， LDAP UDP 入站， LDAP TCP 入站， 以及 Kerberos UDP 入站。此时，您可以查找并添加在内部森林里的对象到位于外部森林的 DACL。
分别设置森林内的信任
不推荐使用该方法，而且该方法仅用在您无法创建森林内来自内部服务器的信任时。 这包括在内部域控制器发布端口以允许森林进行连接。您可以使用前文论述的过程（在森林创建信任）在防火墙内端的森林创建信任。为在防火墙外端的森林创建信任， 在内部服务器域控制器上发布以下端口：
| • | Microsoft-DS （端口 445） |
| • | LDAP TCP （端口 389） |
| • | LDAP UDP （端口 389） |
| • | Kerberos-sec UDP （端口 88） |
| • | 如果您使用前面章节论述的步骤，您可以为每一个端口发布一台服务器。 |
注意，由于本地的 Direct Host SMB 服务默认情况下使用防火墙中的端口 445 ，您必须首先禁用该服务。为此，设置或创建如下注册表项，注册表项 DWORD 值为零 （0），再重新启动计算机：
HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\NetBT\Parameters\SMBDeviceEnabled
在此之后， ISA Server 防火墙客户端就可以绑定端口 445 并发送包到内部服务器。
错误信息
当您试图跨越防火墙建立信任时，可能会接收到以下错误信息：
| • | 指定的域不是 Windows 域名。 如果一台域控制器不能定位其他域控制器，您可能收到该错误信息。DNS 的配置可能不合适。 |
| • | 参数非法。 LDAP UDP 端口未被打开。 |
| • | 访问被拒绝。 Kerberos 端口没有打开，或者远程密码不正确。 |
| • | RPC 服务器不可用。 Microsoft-DS 端口未被打开。 |
| • | 无法询问森林功能级别。森林不可操作。 LDAP TCP 端口没有打开。 |
| • | 终结点映射器不包含任何终结点。 NTDS 或者 Netlogon 端口没有打开。 Kerberos 端口没有打开或者远程密码不正确。 |
| • | 未声明的错误。 再次确认端口终结点映射器已打开。 |
删除森林信任
Contoso 公司的管理员不再需要跨森林信任。
在本方案中，您将删除森林信任。为删除森林信任：
1. | 使用管理员权限登录到 corp.contoso.com 域。 |
2. | 点击 开始，指向 所有程序，指向 管理工具，再点击 活动目录域和信任。 |
3. | 右击左侧窗格中的 corp.contoso.com ，再点击 属性。 |
4. | 点击 信任 标签， 右击 nwtraders.com （在 该域信任的域（待发信任） 对话框），再点击 删除。 |
5. | 点击 是，删除从本地域或其他域的信任。 |
6. | 输入 Administrator （在 用户名 对话框，再输入密码（在 密码 对话框）。 |
7. | 点击 是，然后选择删除信任选项。 |
重复步骤4到步骤7，删除引入的信任（在 信任该域的域（引入的信任） 对话框）。
附录 A 端口列表
以下表格列出了您在建立信任前必须打开的端口列表。
| 方案 | 出站端口 | 入站端口 | 从-到 |
建立内部森林两侧的信任 | LDAP （389 UDP 以及 TCP） Microsoft SMB （445 TCP） Kerberos （88 UDP） 终结点解析端口映射器（135 TCP） Netlogon 固定端口 | 内部域域控制器 外部域域控制器 （所有端口） | |
验证从内部森林域控制器到外部森林域控制器的信任 （仅待发信任） | LDAP （389 UDP） Microsoft SMB （445 TCP） 终结点解析端口映射器 （135 TCP） Netlogon 固定端口 | 内部域域控制器 外部域域控制器 （所有端口） | |
外部森林的对象选取器添加内部森林对象到组和 DACL | LDAP （389 UDP 以及 TCP） Windows NT Server 4.0 目录服务固定端口 Netlogon 固定端口 Kerberos （88 UDP） 终结点解析端口映射器 （135 TCP） | 外部服务器 内部域PDC （Kerberos） 外部域域控制器 内部域域控制器 （Netlogon） | |
建立从外部森林到外部森林的信任 | LDAP （389 UDP 以及 TCP） Microsoft SMB （445 TCP） Kerberos （88 UDP） | 外部域域控制器 内部域域控制器 （全部端口） | |
Kerberos 身份验证 （内部森林客户端到外部森林） | Kerberos （88 UDP） | 内部客户端 外部域域控制器 （全部端口） | |
NTLM 身份验证 （内部森林客户端到外部森林） | 终结点解析端口映射器 （135 TCP） Netlogon 固定端口 | 外部域域控制器 内部域域控制器 （全部端口） | |
内部计算机加入到外部域的域 | LDAP （389 UDP 以及 TCP） Microsoft SMB （445 TCP） Kerberos （88 UDP） 终结点解析端口映射器 （135 TCP） Netlogon 固定端口 Windows NT Server 4.0 目录服务固定端口 | 内部客户端 外部域域控制器 （全部端口） |
配置以下表项值以声明运行在固定端口的服务：
1. | LSA（本地安全授权） RPC 端口 （与 NTDS 固定端口相同） 用于 LSA 策略数据库来创建信任和其他访问 TCP/IPPortentry 在 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters 注册表项。 |
2. | Netlogon RPC 端口用于 NTLM，信任隧道 DCTcpipPort 入口在 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters 注册表项。 |
附录 B 白皮书中用到的词汇
以下为本白皮书中用到的词汇：
| • | 外部信任：连接两个处在不同森林中的域的单一信任。外部信任建立从域到其他域的非传递信任。这些信任必须由管理员显式地创建，并由其管理。该信任可以是单向也可以是双向的。 |
| • | 内部信任：连接两个处在同一个森林中的域的单个信任。内部信任建立两个域之间的可传递信任。例如，若域 A 信任域 B 并且域 B 信任域 C， 那么域 A 信任域 C。这些信任是在有新的域被加入到森林时自动创建的，而且是森林正常工作所必须的。该信任通常是双向信任。 |
| • | 森林 信任：连接两个森林根域的单个信任。该森林信任创建了每个森林所有域之间的信任。例如，若森林 A 信任森林 B，那么森林 A 中的所有域通过森林信任而信任森林 B 中的所有域。然而， 该信任是不能跨越森林传递的。例如，若森林 A 信任森林 B 而森林 B 信任森林 C， 那么森林 A 不会自动的信任森林 C。该信任可以是单相或双向的信任。 |
| • | 受信任域对象（TDO）：存在于活动目录中，用以代表两个域或森林之间信任的对象。 |
| • | 森林 TDO：现有的信任定义对象，其中有一位数字用于表示森林信任。 |
| • | 命名空间： 一组相关的名称。该名称可用于代表性的表示另一信息的类型（例如，安全主体），并建立特定的规则用以判定哪些名称属于该命名空间。例如，命名空间可能是“除了 a.contoso.com 或者 b.contoso.com 以外，所有以 contoso.com 结束的名称”。森林管理很多看似相同的命名空间，但用于确定不同类型的对象，如用户主体名称 （UPN）， 服务主体名称 （SPN），以及域名。 |
| • | 顶级名称 （TLN）：用来标识命名空间的名称。例如， corp.fabrikam.com 就是标识包含 corp.fabrikam.com 之下所有名称的命名空间的 TLN，如 server.corp.fabrikam.com，server1.corp.fabrikam.com，server2.corp.fabrikam.com 等等。 |
| • | 顶级名称排除项（TLNEx）： 排除一部分命名空间的记录。例如， fabrikam.com TLN 中的 test.fabrikam.com TLNEx 声明了除 test.fabrikam.com 之下所有名称的 fabrikam.com 之下的命名空间。 |
| • | 森林 信任信息 （FTInfo）： 命名空间 （由其 TLN 标识）的设置由受信任的森林来管理，该设置通过一项注解的字段标识是否每项要求都确实受信任森林信任。 FTInfo 保存在森林 TDO 中，并用于路由到受信任的森林的身份验证和授权请求。 |
| • | 用户主体名称 （UPN）：用户名称的一个变体，看似电子邮件名称，但可用于登录。语法为 user_name@string。 |
| • | 隐式 UPN：隐式 UPN 通常是 user_id@DNS_domain_name.com 的形式。该 UPN 通常与用户帐号相联，即使显式 UPN 并未定义。 |
| • | 显式 UPN： 显式 UPN 通常是 string@any_string 的形式， string 以及 any_string 由管理员显式的定义。 |
| • | UPN 后缀： 包含 UPN 起源命名空间的字符串。 UPN后缀包括了 UPN 中符号（@）右侧的所有字符串。其符号（@）左侧的字符串被认为是用户姓名，即使该字符串还包含一个符号（@）。UPN 后缀可以使扁平或垂直的结构，尽管其通常用于标识扁平结构的命名空间。 |
| • | 服务主体名称（SPN）：用于标识一项和计算机帐号相关服务的多成分的名称。 SPN 具有代表性的用途是请求 Kerberos 服务票证。语法是 service_type/instance_name [：port_number] [/service_name [@domain] ]。例如，host/server.contoso.com， MSSQLSvc/server.contoso.com:1433。 |
| • | SPN 后缀： 指明 SPN 组件起源的命名空间的字符串。SPN 后缀可以由 instance_name 或者 service_name 组件的子字符串组成。可能包含所有的 域 组件，但除了符号（@）。 |
| • | 安全标识符 （SID）： 和每一个安全主体相关的唯一标识符，如 S-1-5-123232343434-544。该 SID 由域标识符和关系标识符 （RID）组成。 |