跨AD域双跳场景下AWS新客户端SSRS匿名登录失败求助

1. 验证Kerberos约束委派配置 #

双跳场景下，SSRS服务账号必须具备向SQL Server委派凭据的权限，Server 2019对Kerberos的校验更严格，需重点排查：

• 执行setspn -L <SSRS服务账号>命令，确认SSRS和SQL Server的SPN是否正确注册。SQL Server的SPN格式通常为MSSQLSvc/<SQL服务器FQDN>:<端口>或MSSQLSvc/<SQL服务器名>:<端口>，缺失SPN会导致Kerberos身份验证失败， fallback到NTLM，进而引发双跳凭据传递失效。
• 打开AD用户和计算机，找到SSRS服务账号，进入「委派」选项卡，确认选择**「仅信任此用户来委派到指定服务」**，并已添加SQL Server的SPN条目。避免使用「任意服务」的宽松配置，防止权限问题。

2. 排查新客户端的Kerberos运行环境 #

Server 2019默认的Kerberos策略与Server 2012存在差异，需验证客户端侧配置：

• 在新客户端执行klist purge清除缓存的Kerberos票证，重新访问SSRS后，再执行klist查看是否获取到SSRS的服务票证，以及是否生成了委派到SQL Server的票证。若未获取到对应票证，说明Kerberos身份验证未成功触发。
• 检查客户端组策略：
  • 「计算机配置 > 管理模板 > 系统 > Kerberos」：确认未禁用Kerberos相关功能。
  • 「网络安全：LAN管理器身份验证级别」：若旧环境依赖NTLMv1，Server 2019默认的「仅发送NTLMv2响应」可能导致兼容性问题，可临时调整为「发送NTLMv2响应，拒绝LM」测试。
• 确认客户端能正确解析SSRS和SQL Server的FQDN，AWS VPC的DNS需配置为可解析AD域内服务器的域名，Kerberos身份验证依赖FQDN而非IP地址。

3. 检查SSRS身份验证配置 #

确保SSRS启用了支持凭据传递的身份验证方式：

• 打开SSRS配置管理器，进入「身份验证」选项，确认启用**「Windows身份验证」**，并勾选「启用Kerberos身份验证」。
• 编辑RSReportServer.config文件（默认路径：C:\Program Files\Microsoft SQL Server Reporting Services\SSRS\ReportServer），检查<Authentication>节点配置，确保包含<RSWindowsNegotiate>和<RSWindowsKerberos>，示例配置：

  <Authentication>
      <AuthenticationTypes>
          <RSWindowsNegotiate />
          <RSWindowsKerberos />
          <RSWindowsNTLM />
      </AuthenticationTypes>
      <EnableAuthPersistence>true</EnableAuthPersistence>
  </Authentication>
  

• 确认SSRS服务使用域账号运行，本地系统账号无法完成Kerberos委派。

4. 确认AWS VPC网络与AD信任关系 #

即使已开放88端口，仍需排查其他关键端口与信任配置：

• 检查AWS VPC安全组和网络ACL，确保双向开放以下端口：TCP/UDP 88（Kerberos）、TCP/UDP 389（LDAP）、TCP 464（Kerberos密码更新）、TCP 636（LDAPS，若启用）。
• 验证两个AD域的信任关系：确认信任为双向信任，且信任属性中启用了「Kerberos信任」（而非仅NTLM）。可在AD域和信任关系中查看信任的「属性」，确认身份验证方法为「全域性认证」。
• 检查新客户端的域成员身份：执行ipconfig /all确认DNS后缀正确，且客户端已成功加入信任域，未处于脱离域的状态。

5. 验证SQL Server与报表数据源配置 #

虽然本地客户端正常，仍需排除权限配置差异：

• 检查SQL Server登录名，确认NT Authority\Anonymous Logon未被意外拒绝访问（此问题概率较低，可作为兜底排查项）。
• 打开报表服务器，检查报表数据源的身份验证方式，确保选择**「Windows身份验证（集成）」**，而非「凭据存储在报表服务器中」或其他方式，集成身份验证是双跳凭据传递的前提。

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