信任关系如何作用于 Active Directory 中的林
Active Directory 域服务 (AD DS) 通过域和林信任关系提供跨多个域或林的安全性。 跨信任进行身份验证之前，Windows 必须首先检查用户、计算机或服务请求的域与请求帐户的域之间是否存在信任关系。
为检查这种信任关系，Windows 安全系统将计算接收请求的服务器的域控制器 (DC) 和请求帐户的域中的 DC 之间的信任路径。
AD DS 和 Windows 分布式安全模型提供的访问控制机制为域和林信任的操作提供了环境。 要使这些信任能够正常发挥作用，每项资源或每台计算机都必须对其所在域中的 DC 具有直接信任路径。
Net Logon 服务使用经过身份验证的远程过程调用 (RPC) 与受信任的域颁发机构的连接来实现此信任路径。 安全通道还通过域间信任关系扩展到其他 AD DS 域。 此安全通道用于获取和验证安全信息，包括用户和组的安全标识符 (SID)。
注意
域服务支持多个林信任方向，包括双向信任和可以是传入或传出的单向信任。
有关信任如何应用于域服务的概述，请参阅林概念和功能。
若要开始在域服务中使用信任，请创建使用林信任的托管域。
信任关系流
信任间的安全通信流决定信任的弹性。 你如何创建或配置信任，决定这种通信在林中或林间扩展的范围。
信任之间的通信流取决于信任的方向。 信任可以是单向或双向的，可以是可传递或不可传递的。
下图显示，默认情况下，树 1 和树 2 中的所有域之间具有可传递的信任关系。 因此，在资源处分配适当的权限时，树 1 中的用户可以访问树 2 所含域中的资源，且树 1 中的用户可以访问树 2 中的资源 。
单向和双向信任
允许访问资源的信任关系可以是单向或双向的。
单向信任是在两个域之间创建的单向身份验证路径。 在域 A 和域 B 的一种单向信任中，域 A 中的用户可以访问域 B 中的资源。 但是，域 B 中的用户无法访问域 A 中的资源。
某些单向信任可以是不可传递的，也可以是可传递的，具体取决于所创建的信任类型。
在双向信任中，域 A 信任域 B，域 B 也信任域 A。 此配置表示两个域之间可以相互传递身份验证请求。 某些双向信任关系可以是不可传递的，也可以是可传递的，具体取决于所创建的信任类型。
本地 AD DS 林中的所有域信任都是双向可传递信任。 创建新的子域时，将在新子域和父域之间自动创建双向可传递信任。
可传递和不可传递信任
传递性决定可否将信任扩展到构成该信任的两个域之外。
- 可以使用可传递信任扩展与其他域的信任关系。
- 可以使用不可传递信任拒绝与其他域的信任关系。
每次在林中创建新域时，都会在新域及其父域之间自动创建双向可传递信任关系。 如果将子域添加到新域，则信任路径将向上流经域层次结构，扩展在该新域及其父域之间创建的初始信任路径。 传递信任关系形成时会在域树中向上流动，在域树中的所有域之间创建可传递信任。
身份验证请求沿这些信任路径传递，因此来自林中任何域的帐户都可以通过该林中其他任何域的身份验证。 通过单一登录过程，具有适当权限的帐户可以访问林中任何域中的资源。
林信任
林信任可以帮助管理分段 AD DS 基础结构，并支持访问多个林中的资源和其他对象。 林信任适用于服务提供商、正在进行合并或收购的公司、协作业务 Extranet 和寻求管理自治解决方案的公司。
使用林信任，可以链接两个不同的林，形成单向或双向可传递信任关系。 使用林信任，管理员可以将通过单个信任关系连接两个 AD DS 林，以便提供跨林的无缝身份验证和授权体验。
只能在一个林中的林根域和另一个林中的林根域之间创建林信任。 只能在两个林之间创建林信任，不能将其隐式扩展到第三个林。 此行为意味着，如果在林 1 和林 2 之间创建了林信任，又在林 2 和林 3 之间创建了另一个林信任，林 1 与林 3 之间不存在隐式信任。
下图显示了一个组织中三个 AD DS 林之间两个单独的林信任关系。
此示例配置提供以下访问权限：
- 林 2 中的用户可以访问林 1 或林 3 所含任何域中的资源
- 林 3 中的用户可以访问林 2 所含任何域中的资源
- 林 1 中的用户可以访问林 2 所含任何域中的资源
此配置不允许林 1 中的用户访问林 3 中的资源，反之亦然。 若要允许林 1 和林 3 中的用户共享资源，则必须在这两个林之间创建双向可传递信任。
如果在两个林之间创建单向林信任，则受信任林的成员可以利用信任林中的资源。 但是，信任只单向有效。
例如，在林 1（受信任林）与林 2（信任林）之间创建单向林信任时：
- 林 1 的成员可以访问林 2 中的资源。
- 林 2 的成员不能使用同一信任访问林 1 中的资源。
重要
Microsoft Entra 域服务支持多个方向的林信任。
林信任要求
需要确认你拥有正确的域名系统 (DNS) 基础结构，然后才能创建林信任。 仅当以下 DNS 配置之一可用时，才能创建林信任：
有一个根 DNS 服务器是两个林 DNS 命名空间的根 DNS 服务器 - 根区域包含每个 DNS 命名空间的委派，所有 DNS 服务器的根提示都包括根 DNS 服务器。
如果没有共享的根 DNS 服务器，并且每个林 DNS 命名空间中的根 DNS 服务器使用 DNS 条件转发器，让每个 DNS 命名空间路由对其他命名空间中名称的查询。
重要
任何具有信任的 Microsoft Entra 域服务林都必须使用此 DNS 配置。 Microsoft Entra 域服务不支持承载除林 DNS 命名空间之外的 DNS 命名空间。 条件转发器是正确的配置。
如果没有共享的根 DNS 服务器，并且每个林 DNS 命名空间中的根 DNS 服务器使用 DNS 辅助区域，让每个 DNS 命名空间路由对其他命名空间中名称的查询。
若要在 AD DS 中创建林信任，你必须是（林根域中的）“域管理员”组或 Active Directory 中的“企业管理员”组的成员。 为每个信任分配一个密码，这两个林中的管理员都必须知道该密码。 两个林中的“企业管理员”成员可以同时在这两个林中创建信任，在这种情况下，会自动为这两个林生成并写入随机加密的密码。
托管域林支持多达五个到本地林的单向出站林信任。 Microsoft Entra 域服务的出站林信任在 Microsoft Entra 管理中心创建。 传入林信任必须由具有以前在本地 Active Directory 中记录的特权的用户配置。
信任进程和交互
许多域间和林间事务依赖于域信任或林信任来完成各种任务。 本部分介绍跨信任访问资源并评估身份验证引用时发生的过程和交互。
身份验证引用处理概述
当身份验证请求被引用到域时，该域中的域控制器必须确定与请求来自的域之间是否存在信任关系。 在对用户进行身份验证以允许其访问域中的资源之前，还必须确定信任的方向以及信任是否可传递。 根据所使用的身份验证协议，在受信任域之间发生的身份验证过程会有所不同。 Kerberos V5 和 NTLM 协议会以不同方式处理向域进行身份验证的引用
Kerberos V5 引用处理
Kerberos V5 身份验证协议依赖于域控制器上的 Net Logon 服务来获取客户端身份验证和授权信息。 Kerberos 协议连接到在线密钥发行中心 (KDC) 和 Active Directory 帐户存储以获取会话票证。
Kerberos 协议还使用信任，以实现跨领域票证授予服务 (TGS)，并在受保护的通道中验证特权属性证书 (PAC)。 Kerberos 协议仅对非 Windows 品牌的操作系统 Kerberos 领域（如 MIT Kerberos 领域）执行跨领域身份验证，无需与 Net Logon 服务交互。
如果客户端使用 Kerberos V5 进行身份验证，它会请求从帐户域中域控制器到目标域中服务器的票证。 Kerberos KDC 充当客户端和服务器之间的受信任中介，并提供一个会话密钥，使双方彼此进行身份验证。 如果目标域不同于当前域，KDC 将遵循逻辑进程来确定是否可以引用身份验证请求：
被请求的服务器所在的域是否直接信任当前域？
- 如果是，则向客户端发送对被请求域的引用。
- 如果不是，则转到下一步骤。
当前域与信任路径上的下一个域之间是否存在可传递信任关系？
- 如果是，则向客户端发送对信任路径上的下一个域的引用。
- 如果不是，则向客户端发送拒绝登录消息。
NTLM 引用处理
NTLM 身份验证协议依赖于域控制器上的 Net Logon 服务来获取客户端身份验证和授权信息。 此协议对不使用 Kerberos 身份验证的客户端进行身份验证。 NTLM 使用信任在域之间传递身份验证请求。
如果客户端使用 NTLM 进行身份验证，则会直接从客户端向目标域中的资源服务器发送初始身份验证请求。 此服务器会创建质询待客户端响应。 然后，服务器将用户的响应发送到其计算机帐户域中的域控制器。 此域控制器会检查用户帐户是否在其安全帐户数据库中。
如果数据库中不存在该帐户，则域控制器将使用以下逻辑决定是执行直通身份验证、转发请求还是拒绝请求：
当前域与用户的域是否具有直接信任关系？
- 如果是，则域控制器会将客户端的凭据发送到用户域中的域控制器，以进行直通身份验证。
- 如果不是，则转到下一步骤。
当前域与用户的域是否具有可传递信任关系？
- 如果是，则将身份验证请求继续传递到信任路径中的下一个域。 此域控制器将重复“检查用户的凭据是否在其安全帐户数据库中”这一过程。
- 如果不是，则向客户端发送拒绝登录消息。
对于通过林信任实现身份验证的请求的基于 Kerberos 的处理
当两个林通过林信任连接时，可以在林间路由使用 Kerberos V5 或 NTLM 协议发出的身份验证请求，以提供对这两个林中资源的访问权限。
第一次建立林信任时，每个林都会收集其伙伴林中的所有受信任命名空间，并将信息存储在受信任的域对象中。 受信任的命名空间包括在另一个林中使用的域树名称、用户主体名称 (UPN) 后缀、服务主体名称 (SPN) 后缀和安全 ID (SID) 命名空间。 会将 TDO 对象复制到全局目录。
注意
不支持信任的备用 UPN 后缀。 如果本地域使用与域服务相同的 UPN 后缀，则登录必须使用 sAMAccountName。
必须先将资源计算机的服务主体名称 (SPN) 解析为另一个林中的位置，身份验证协议才能遵循林信任路径。 SPN 可以是下列名称之一：
- 主机的 DNS 名称。
- 域的 DNS 名称。
- 服务连接点对象的可分辨名称。
当一个林中的工作站尝试访问另一个林中资源计算机上的数据时，Kerberos 身份验证过程会联系域控制器，以获取资源计算机 SPN 的服务票证。 一旦域控制器查询全局目录并确定该 SPN 与域控制器不在同一个林中，域控制器会将对其父域的引用发送回工作站。 此时，工作站会查询该父域以获取服务票证，并沿引用链继续前进，直到到达资源所在的域。
以下关系图和步骤详细描述了运行 Windows 的计算机尝试访问另一个林中的计算机时使用的 Kerberos 身份验证过程。
User1 使用来自 europe.tailspintoys.com 域的凭据登录到 Workstation1 。 然后，该用户尝试访问 usa.wingtiptoys.com 林中 FileServer1 上的共享资源。
Workstation1 联系其域 ChildDC1 中域控制器上的 Kerberos KDC，并为 FileServer1 SPN 请求服务票证。
ChildDC1 在其域数据库中找不到该 SPN，并查询全局目录以了解 tailspintoys.com 林中是否有任何域包含此 SPN。 由于全局目录仅限于其自己的林，因此未找到该 SPN。
然后，全局目录将检查其数据库，查找与其林建立的任何林信任的相关信息。 如果找到，它会将林信任受信任的域对象 (TDO) 中列出的名称后缀与目标 SPN 的后缀进行比较，以查找匹配项。 找到匹配项后，全局目录会反过来向 ChildDC1 提供路由提示。
路由提示有助于向目标林进行直接身份验证请求。 仅当所有传统身份验证通道（例如本地域控制器和全局目录）都找不到 SPN 时才使用提示。
ChildDC1 反过来向 Workstation1 发送对其父域的引用。
Workstation1 联系 ForestRootDC1（其父域）中的域控制器，以获取对 wingtiptoys.com 林的林根域中域控制器 (ForestRootDC2) 的引用。
Workstation1 联系 wingtiptoys.com 林中的 ForestRootDC2，以获取用于所请求服务的服务票证。
ForestRootDC2 联系其全局目录以查找 SPN，全局目录找到该 SPN 的匹配项并将其发送回 ForestRootDC2。
然后，ForestRootDC2 将对 usa.wingtiptoys.com 的引用发送回 Workstation1。
Workstation1 联系 ChildDC2 上的 KDC，并协商 User1 的票证，以获得对 FileServer1 的访问权限。
Workstation1 拥有服务票证后，它会将该服务票证发送到 FileServer1，后者会读取 User1 的安全凭据，并相应地构造一个访问令牌。
受信任的域对象
组织内的每个域或林信任均由存储在其域中的“系统”容器中的受信任域对象 (TDO) 表示。
TDO 内容
TDO 中包含的信息取决于 TDO 是由域信任还是林信任创建的。
创建域信任时，DNS 域名、域 SID、信任类型、信任传递性和互惠域名等属性将表示在 TDO 中。 林信任 TDO 还存储其他属性，用于标识来自伙伴林的所有受信任的命名空间。 这些属性包括域树名称、用户主体名称 (UPN) 后缀、服务主体名称 (SPN) 后缀和安全 ID (SID) 命名空间。
因为信任以 TDO 的形式存储在 Active Directory 中，所以林中的所有域都将了解整个林中存在的信任关系。 类似地，当两个或更多林通过林信任联接在一起时，每个林中的林根域都将了解受信任的林中所有域之间的信任关系。
TDO 密码更改
信任关系中的两个域共享一个密码，该密码存储在 Active Directory 中的 TDO 对象内。 作为帐户维护过程的一部分，信任域控制器每 30 天会更改一次存储在 TDO 中的密码。 由于所有双向信任实际上都是两个相反方向的单向信任，因此该过程对于双向信任会发生两次。
信任具有信任和受信任端。 在受信任端，任何可写域控制器都可用于此过程。 在信任端，由 PDC 模拟器执行密码更改。
为更改密码，域控制器将完成以下过程：
信任域中的主域控制器 (PDC) 仿真器创建新密码。 受信任域中的域控制器永远不会启动密码更改。 始终由信任域 PDC 仿真器启动。
信任域中的 PDC 仿真器将 TDO 对象的 OldPassword 字段设置为当前 NewPassword 字段。
信任域中的 PDC 仿真器将 TDO 对象的 NewPassword 字段设置为新密码。 保留以前密码的副本，以便在受信任的域中的域控制器无法接收更改时，或者在使用新信任密码发出请求之前未复制更改时，可以还原到旧密码。
信任域中的 PDC 仿真器对受信任的域中的域控制器进行远程调用，要求它将信任帐户的密码设置为新密码。
受信任的域中的域控制器将信任密码更改为新密码。
在信任的双方，将更新复制到域中的其他域控制器。 在信任域中，更改将触发紧急复制受信任的域对象。
现在，这两个域控制器上都已更改密码。 正常复制将 TDO 对象分发到域中的其他域控制器。 但是，信任域中的域控制器可能会更改密码而未成功更新受信任的域中的域控制器。 出现这种情况的原因可能是，无法建立处理密码更改所需的安全通道。 还可能是受信任的域中的域控制器在过程中的某个时间点不可用，因而无法接收更新的密码。
为处理密码更改未成功传递的情况，在使用新密码成功完成身份验证（设置安全通道）之前，信任域中的域控制器不会更改新密码。 此行为是将旧密码和新密码同时保存在信任域的 TDO 对象中的原因。
直到使用密码的身份验证成功，密码更改才算完成。 可通过受保护的通道使用已存储的旧密码，直到受信任的域中的域控制器收到新密码，从而实现不间断服务。
如果使用新密码进行的身份验证由于密码无效而失败，则信任域控制器会尝试使用旧密码进行身份验证。 如果它通过旧密码成功完成身份验证，它将在 15 分钟内继续密码更改过程。
信任密码更新需要在 30 天内复制到信任双方的域控制器。 如果在 30 天后更改了信任密码，并且域控制器只拥有 N-2 密码，则它不能在信任端使用信任，也不能在受信任端创建安全通道。
信任使用的网络端口
因为必须跨各种网络边界部署信任，所以信任可能必须跨越一个或多个防火墙。 如果是这种情况，可以将信任流量隧道传输过防火墙，或在防火墙中打开特定端口以允许流量通过。
重要
Active Directory 域服务不支持将 Active Directory RPC 流量限制于特定端口。
请参阅 Microsoft 支持文章如何为 Active Directory 域和信任配置防火墙的“Windows Server 2008 及更高版本”部分，了解林信任所需的端口。
支持服务和工具
为支持信任和身份验证，使用了一些额外的功能和管理工具。
Net Logon
Net Logon 服务维护从基于 Windows 的计算机到 DC 的安全通道。 以下信任相关过程中使用也会用到该服务：
信任设置和管理 - Net Logon 有助于维护信任密码、收集信任信息，以及通过与 LSA 进程和 TDO 交互来验证信任。
对于林信任，信任信息包括林信任信息 (FTInfo) 记录，其中包含受信任的林声明要管理的命名空间集，使用指示每个声明是否受信任林信任的字段进行批注。
身份验证 - 通过受保护的通道向域控制器提供用户凭据，并返回用户的域 SID 和用户权限。
域控制器位置 - 帮助在域中或域间查找或定位域控制器。
直通验证 - 由 Net Logon 处理其他域中用户的凭据。 当信任域需要验证用户的身份时，它会将用户的凭据通过 Net Logon 传递到受信任的域进行验证。
特权属性证书 (PAC) 验证 - 当使用 Kerberos 协议进行身份验证的服务器需要验证服务票证中的 PAC 时，它会通过安全通道将该 PAC 发送到其域控制器以进行验证。
本地安全机构
本地安全机构 (LSA) 是一个受保护的子系统，用于维护有关系统上本地安全的各方面的信息。 LSA 提供用于在名称和标识符之间进行转换的各种服务，统称本地安全策略。
LSA 安全子系统在内核模式和用户模式下提供服务，用于验证对对象的访问权限、检查用户权限以及生成审核消息。 LSA 负责检查受信任或不受信任的域中的服务提供的所有会话票证的有效性。
管理工具
管理员可以使用 Active Directory 域和信任、Netdom 和 Nltest 来公开、创建、删除或修改信任。
- Active Directory 域和信任是一个 Microsoft 管理控制台 (MMC)，用于管理域信任、域和林功能级别以及用户主体名称后缀。
- Netdom 和 Nltest 命令行工具可用于查找、显示、创建和管理信任。 这些工具直接与域控制器上的 LSA 机构通信。
后续步骤
若要开始使用林信任创建托管域，请参阅创建和配置域服务托管域。 随后可以创建到本地域的出站林信任。