用户从内部LAN切换至公网时ADFS/DNS异常问题咨询

嘿，我之前处理过不少ADFS对接WAP+云SharePoint的故障，结合你给出的环境信息，给你梳理几个核心排查方向，应该能帮你定位问题：

先明确下你的环境配置，方便后续排查对照：

• 内部域：hobnobs.internal.eu
• 云服务商SharePoint域：cloudsp.eu
• WAP公网DNS记录：login.cloudsp.eu
• WAP发布的Web应用：内外URL均为https://login.cloudsp.eu
• 内部ADFS联合服务名称：login.cloudsp.eu

1. 域名解析与网络连通性 #

这是最基础但最容易忽略的点：

• 内网环境下，login.cloudsp.eu必须解析到WAP的内网IP，如果误解析到公网IP，会出现请求回路或者延迟，直接导致ADFS验证失败。可以用nslookup login.cloudsp.eu在内部机器上测试解析结果。
• 公网环境下，确认login.cloudsp.eu正确指向WAP的公网IP，同样用nslookup测试。
• 在WAP服务器上测试到ADFS服务器的443端口连通性：执行Test-NetConnection <ADFS服务器内网FQDN> -Port 443，确保能正常建立连接。

2. ADFS与WAP的证书匹配 #

ADFS的联合服务名称是login.cloudsp.eu，证书必须完全匹配：

• 检查ADFS服务器的服务通信证书：打开ADFS控制台，进入「服务」→「证书」，确认服务通信证书的主体名（SAN）包含login.cloudsp.eu，且证书未过期、信任链完整。
• WAP服务器的证书：IIS中login.cloudsp.eu站点绑定的证书必须和ADFS的服务通信证书一致（或者至少是同一根CA签发的，且WAP信任ADFS的根证书）。同时，WAP和ADFS建立信任时交换的证书也必须有效。

3. WAP发布规则的细节配置 #

WAP发布ADFS应用时有几个关键配置项：

• 「内部服务器名称」必须填写ADFS服务器的内网FQDN（比如adfs.hobnobs.internal.eu），而不是login.cloudsp.eu——虽然内外URL是这个，但内部要指向真实的ADFS节点。
• 确认发布规则选择了ADFS预身份验证，且WAP已和ADFS建立信任关系（可以通过Get-WebApplicationProxyConfiguration查看信任状态，或者重新运行Install-WebApplicationProxy完成信任配置）。
• 查看WAP的事件日志：路径是「应用程序和服务日志」→「Microsoft」→「Windows」→「WebApplicationProxy」，重点关注ID为1300、1600的错误事件，这些日志会直接给出故障原因。

4. ADFS信赖方信任与声明规则 #

对接云SharePoint的核心是信赖方配置：

• 确认ADFS中已正确添加cloudsp.eu的信赖方信任，信赖方标识符必须和云服务商提供的SharePoint实体ID完全一致（一般是https://<SharePoint站点域名>/trust格式）。
• 检查声明规则是否正确传递了用户身份信息（比如UPN、邮箱地址），云SharePoint需要这些声明来识别用户。可以用Get-AdfsRelyingPartyTrust -Name "<cloudsp信赖方名称>"查看规则配置，或者启用ADFS跟踪日志（路径C:\Windows\ADFS\Trace），查看请求中的声明内容是否符合要求。

5. 客户端侧测试验证 #

有时候问题出在客户端环境：

• 内网机器直接访问https://login.cloudsp.eu/adfs/ls/idpinitiatedsignon.aspx，测试ADFS是否能正常发起身份验证。如果内网能正常登录，说明ADFS本身没问题，问题大概率在WAP或公网路由。
• 公网环境下用隐私模式访问，排除浏览器缓存、Cookie的影响；同时检查客户端是否信任ADFS的根证书，若证书不受信任，会出现SSL报错导致连接失败。

内容的提问来源于stack exchange，提问作者user2745994