新建森林信任后访问被拒绝的根本原因是目标林资源acl未显式添加源林用户/组；windows不自动映射或放行，必须手动配置权限、确保dns解析正常，并注意selective authentication等高级限制。
多林信任关系（forest trust）不是“建立就能用”的开关，它只是跨林身份验证的基础设施；真正控制谁能在目标林访问什么资源，靠的是目标林资源上的 acl（访问控制列表），且必须显式添加源林的用户/组——windows 默认不会自动映射或放行。
为什么新建森林信任后还是被拒绝访问？
常见现象是：信任已建好（nltest /trust 显示正常），但源林用户访问目标林的文件共享、Exchange 或 AD 对象时仍提示“访问被拒绝”。根本原因在于：ACL 里没加源林主体。
- Windows 不会把源林用户自动加入目标林的内置组（比如
Domain Users），也不默认授予任何权限 - 目标林资源（如文件夹、OU、邮箱数据库）的
ACL只认本林安全主体，除非你手动添加sourceforest\user@sourceforest.com或sourceforest\Domain Users - 若用 UPN 登录（如
user@sourceforest.com），目标林必须能通过信任链解析该 UPN —— 这要求源林 DNS 后缀已在目标林的trusted domains列表中注册（可通过netdom trust或 ADUC 的“信任”属性页确认）
配置跨林 ACL 的实操要点
在目标林对资源设置权限时，必须让系统能“看到”源林的主体。关键不是改本地策略，而是确保名称解析通、权限对象选得准：
- 在目标林打开资源属性 → “安全”选项卡 → “编辑” → “添加”，输入框里直接键入：
sourceforest\username（SAM 名格式）或username@sourceforest.com（UPN 格式）→ 点击“检查名称”，成功解析才表示信任和 DNS 路由正常 - 避免添加整个
sourceforest\Domain Users组——它在目标林表现为一个外部安全主体（ForeignSecurityPrincipal），但无法嵌套进目标林组，权限继承行为也受限；更可控的做法是建一个目标林本地组（如FG-Access-SourceForest-App1），再把源林用户/组加进去 - 若需对 OU 应用委派控制（如允许源林管理员重置密码），必须用
Active Directory 用户和计算机的“委派控制”向导，并在向导中明确选择源林主体（同样依赖名称解析）
信任方向与 ACL 生效范围的关系
森林信任默认是双向、可传递的，但 ACL 权限不继承信任方向——它只取决于你在哪个林、对哪个资源设了权限：
- 你在目标林 A 的共享文件夹上加了
sourceforestB\user1的读取权限 → user1 能从 B 林访问 A 林该路径 - 但你在 A 林没给
sourceforestC\user2做任何 ACL → 即使 B 和 C 之间也有信任，user2 依然不能访问 A 林资源（信任不自动穿透三层） - 如果目标林启用了
Selective Authentication（在信任属性中勾选），则必须为每个服务主体（SPN）单独授权，例如文件服务器的CIFS/servera.targetforest.com必须显式添加源林用户到该 SPN 的Validated write to service principal name权限，否则 Kerberos 认证失败
最容易被忽略的是：跨林 ACL 生效的前提，是源林用户登录时使用的身份能被目标林 DC 成功解析并生成有效的访问令牌——这不仅依赖信任状态，还受 DNS 后缀搜索顺序、Kerberos realm 配置、以及是否启用 Authentication Enforcement 影响。调不通时先跑一遍 klist get cifs/server.targetforest.com 看票据是否获取成功，比反复检查 GUI 权限更直接。
