跨服务器场景下IIS与SSRS 2016的ReportViewer认证问题

你遇到的是典型的跨服务器身份验证双跳问题——当启用<identity impersonate="true" />时，ASP.NET会尝试将Forms认证的AD用户身份传递到另一台服务器上的ReportServer，但NTLM认证本身不支持跨服务器的身份传递（也就是"双跳"），而Negotiate如果没有正确配置Kerberos的话，会自动降级为NTLM，最终导致身份验证失败抛出错误。

下面是具体的解决步骤，按优先级排序：

1. 配置Kerberos约束委派（推荐方案） #

这是解决跨服务器身份传递的标准方案，步骤如下：

• 确保IIS服务器、ReportServer服务器和域控制器都在同一个Active Directory域中，所有服务器已成功加入域。
• 为IIS应用池的运行账户（如果使用域账户运行）配置约束委派：
  1. 在AD用户和计算机控制台中找到该账户，右键打开属性→切换到"委派"标签页。
  2. 选择"信任此用户用于委派到指定服务"，然后添加ReportServer对应的服务主体名称（SPN）。
• 为ReportServer的运行域账户注册正确的SPN，以域管理员权限打开命令提示符执行：

  setspn -S HTTP/reportserver.yourdomain.com DOMAIN\YourReportServerAccount
  setspn -S HTTP/reportserver DOMAIN\YourReportServerAccount
  

  （替换成你的ReportServer完整域名、NetBIOS名称，以及对应的域运行账户）
• 在IIS的站点认证设置中，启用Windows认证，并调整提供商顺序，将Negotiate放在NTLM前面，确保优先使用Kerberos协议。

2. 显式指定身份调用ReportServer（备选方案） #

如果Kerberos配置暂时无法落地，可以在ASP.NET代码中跳过模拟的Forms用户，改用拥有ReportServer访问权限的域账户直接执行请求：

// 示例：使用有权限的域账户身份执行ReportServer调用
var domain = "YOUR_DOMAIN";
var username = "ReportServerAuthorizedAccount";
var password = "SecurePassword";

using (var identity = new WindowsIdentity($"{domain}\\{username}", password))
{
    WindowsIdentity.RunImpersonated(identity.AccessToken, () =>
    {
        // 在这里编写调用ReportServer的业务代码，比如ReportExecutionService的操作
    });
}

这种方式不需要依赖跨服务器身份传递，适合快速临时解决问题，但要注意凭据的安全存储（比如用Windows凭据管理器或加密配置文件）。

3. 权限检查与日志排查 #

• 确保Forms认证的AD用户在ReportServer的报表管理器中被授予了对应的访问权限（比如"浏览器"或更高权限）。
• 查看ReportServer的日志文件（默认路径：C:\Program Files\Microsoft SQL Server\MSRS13.MSSQLSERVER\Reporting Services\LogFiles），里面会包含具体的错误细节，比如身份验证失败原因、票据获取失败信息，帮助精准定位问题。
• 检查两台服务器之间的防火墙，确保Kerberos协议所需的88端口（UDP和TCP）是开放状态。

4. 验证Kerberos配置有效性 #

在IIS服务器上，打开命令提示符执行klist get HTTP/reportserver.yourdomain.com，如果能成功获取到Kerberos票据，说明配置生效；如果报错，说明SPN或委派配置存在问题，需要重新核对配置细节。

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