propsX1. 跨域访问失败的真实原因：不是网络不通，而是信任不通
先还原一个我遇到过多次的典型现场：公司有两个 Windows Server 域，A 域负责总部办公，B 域是后来收购的分公司独立建的域。两个域之间的网络早就打通了，ping 能通，共享文件服务器的 IP 也能访问，但只要 A 域用户想打开 B 域文件服务器上的共享目录，系统就一直弹“拒绝访问”，怎么输账号密码都没用。不少人第一反应是权限没给，但把 B 域文件服务器本地管理员权限给了 A 域用户，依然报错。这时候才意识到，问题根本不在 NTFS 权限或共享权限，而在于两个域之间没有建立信任关系。
这里需要把底层逻辑说清楚：域（Domain）不是一个纯粹的网络概念，它是一个安全边界。每个域有自己的 Kerberos 密钥分发中心（KDC），有自己的账户数据库。A 域用户持有的 Kerberos 票据，拿到 B 域的文件服务器上去验证时，B 域的域控根本不知道该票据是谁签发的，自然拒绝承认这个身份。就好比你拿着甲公司的工牌去乙公司刷门禁，门禁系统不认识你，就算你物理上能走到门口，也进不去。
所以跨域访问的核心第一步，不是配共享权限，而是先在两个域之间建立信任关系。信任关系解决了“B 域凭什么相信 A 域发的票据”这个身份认证问题。信任建立之后，A 域用户的身份才能在 B 域的域控上被验证，B 域的资源才能基于这个已验证的身份做授权判断。理解了这个顺序，后面所有配置都不会跑偏。
这个实施场景通常出现在三种情况里：同一森林内多个域之间互访（如根域和子域）、同一林下兄弟域互访、以及完全独立的两个森林之间互访。前两种在域架构设计时如果规划得当，信任关系可能默认已有；第三种是实施文档里最常遇到的，也是最容易出错的。以下内容主要围绕独立森林/独立域之间的信任建立来展开，但也适用于森林内信任的排查。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 实施前的三项检查：DNS 解析、时间同步、端口放行
很多跨域信任建到一半失败，或者建完还是无法访问，90% 的原因出在实施前的准备工作没做足。我在实际部署中把准备工作收敛成三项，每项都吃过亏，逐个说明。
2.1 DNS 是跨域信任的地基，条件转发要配双向
Kerberos 身份验证的第一步是让客户端找到对方域的域控，这一步依赖 DNS。A 域的用户要访问 B 域资源，A 域的网络栈会拿着 B 域的域名去 DNS 里查 SRV 记录，如果 A 域的 DNS 服务器不知道 B 域的域控在哪，后面所有动作都免谈。
最常见的做法是配置条件转发器（Conditional Forwarder）。比如 A 域是 corp.example.local，B 域是 sub.example.local，就在 A 域的 DNS 服务器上新增一个条件转发区域 sub.example.local，把请求转发给 B 域的 DNS 服务器 IP；同时在 B 域的 DNS 服务器上加反向条件转发，把 corp.example.local 转发给 A 域 DNS。这里有个细节经常被忽略：条件转发要配双向，只配一边的话，信任向导往往能过，但等真实用户访问时才会发现问题，排障成本一下就上去了。
还要注意一个常见坑：如果两个域用的子域域名有父子关系，比如 corp.example.local 和 sales.example.local 后缀相同，正向查找区域里可能会出现区域重叠，导致转发配置冲突。遇到这种情况，建议先检查两台 DNS 上的区域列表，确认没有把对方的域名建成本地区域，否则本地区域会优先响应但给不出正确记录。
2.2 Kerberos 对时间极其敏感，5 分钟偏差是硬指标
Kerberos 协议里带时间戳校验