使用ADFS 3.0与ARR URL Rewrite的MVC应用认证后重定向异常

我完全理解你的 frustration——明明wreply参数传得准确无误，ADFS却还是固执地跳转到私有站点，这种问题确实够磨人的。结合你已经完成的排查动作，咱们再从几个容易被忽略的角度往下深挖：

• 检查ADFS服务器的外部URL配置
  有时候ADFS自身的ExternalUrl配置会直接覆盖wreply的逻辑优先级。你可以在ADFS服务器上运行以下PowerShell命令确认当前设置：

  Get-AdfsProperties | Select-Object ExternalUrl
  

  如果返回的是私有站点地址，赶紧用下面的命令更新为公网端点，之后重启ADFS服务生效：

  Set-AdfsProperties -ExternalUrl "https://your-public-adfs-domain.com/adfs/"
  

• 验证RP信任的重定向URI配置
  你提到已经验证了RP标识符，但重定向URI（Redirect URIs）是独立的关键配置项。打开ADFS管理控制台，找到对应的RP信任，进入「属性」-「终结点」标签，确认公网回调地址已经添加且处于启用状态。如果这个地址不在列表里，ADFS会直接拒绝使用传入的wreply，自动 fallback 到私有地址。

• 排查ARR反向代理的URL重写规则
  ARR的出站重写规则很可能悄悄篡改了ADFS返回的Location响应头。你可以检查ARR的URL重写模块：

  • 有没有误将公网地址替换为私有地址的出站规则？
  • 有没有遗漏将私有地址替换为公网地址的规则？
    另外，如果公网用了HTTPS而内部ADFS是HTTP，务必确保ARR的「反向代理设置」里勾选了「启用SSL卸载」，并且后端服务器地址配置正确。

• 检查Claims Provider Trust的端点配置（若使用第三方IDP）
  如果你的ADFS是和第三方身份提供商做联合认证，那Claims Provider Trust里的Identifier和Endpoint配置也可能影响重定向逻辑。确认第三方IDP的回调地址指向的是ADFS的公网端点，而非私有地址。

• 抓包确认ADFS实际收到的请求细节
  用Fiddler或Wireshark在ADFS服务器上抓包，验证实际到达ADFS的Auth请求中，wreply参数是否和你浏览器里看到的一致。有时候反向代理可能因为编码、规则冲突等问题，悄悄修改或丢失了wreply参数——前端看起来没问题，但后端已经变味了。

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