Azure AD SSO无法验证部署在AWS IIS上的.NET应用问题咨询

既然你的应用在本地和自有数据中心都能正常运行，那AWS IIS环境的配置差异大概率是问题根源，我整理了几个高优先级的排查方向：

• 确认Azure AD应用注册的回调URI完全匹配AWS环境
  哪怕你之前配置过所有URI，也再去Azure门户核对一遍：进入应用注册的「身份验证」页面，确保重定向URI包含AWS服务器上应用的完整HTTPS地址（比如https://your-aws-app-domain.com/signin-oidc）。注意要和实际访问地址完全一致，包括是否带www、端口号（如果不是默认443的话），同时检查「前端通道注销URI」和「注销URL」也对应正确。

• 检查IIS的HTTPS证书与TLS配置
  Azure AD对SSL环境要求很严格，AWS上的IIS可能在这里出问题：

  • 打开IIS管理器，找到你的网站，查看「绑定」中的HTTPS条目，确认证书是受信任的（不能是自签证书，除非你把它导入到服务器的「受信任根证书颁发机构」存储）。
  • 进入网站的「SSL设置」，确认启用了TLS 1.2，并禁用TLS 1.0/1.1这些旧版本——Azure AD已经不再支持这些不安全的协议。

• 排查URL重写或反向代理的参数丢失问题
  如果AWS上用了负载均衡、ARR（应用程序请求路由）或者IIS的URL重写模块，很可能导致Azure AD回调的关键参数（比如code、state）被丢弃：

  • 检查重写规则，确保保留了所有查询参数，不要在重写时过滤掉这些SSO必需的内容。
  • 如果用了ARR，在「服务器代理设置」里勾选「启用代理」，同时开启「转发客户端IP地址」和「保留HTTP头」，避免请求被篡改。

• 验证服务器到Azure AD的网络连通性
  AWS的安全组、网络ACL或者服务器防火墙可能拦截了出站请求：

  • 在服务器上打开PowerShell，运行Test-NetConnection login.microsoftonline.com -Port 443，确认能正常连通。如果失败，检查安全组是否允许443端口的出站流量，或者服务器防火墙是否放行该域名。
  • 同样测试graph.microsoft.com的443端口，有些应用会调用Graph API完成后续验证。

• 核对应用配置文件的Azure AD参数
  部署到AWS的应用可能配置文件有误：

  • 打开appsettings.json（ASP.NET Core）或者web.config（ASP.NET Framework），确认ClientId、TenantId和Azure门户里的应用注册完全一致。
  • 检查CallbackPath（比如/signin-oidc）是否和Azure门户里的重定向URI路径部分匹配，Authority地址是否正确（比如https://login.microsoftonline.com/your-tenant-id/v2.0）。

• 查看日志定位具体错误
  以上步骤都排查完还没解决的话，日志是最直接的线索：

  • 在IIS管理器中，找到网站的「日志」，查看Azure AD回调请求的记录，注意状态码（比如400代表参数错误，401代表权限问题，500代表服务器内部错误）和详细错误描述。
  • 打开Windows事件查看器，进入「Windows日志 -> 应用程序」，查找应用抛出的身份验证相关异常；或者查看应用自己生成的日志文件，里面通常会有更具体的错误信息（比如证书验证失败、签名无效等）。

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