默认情况下,Reporting Services 接受指定 Negotiate 或 NTLM 身份验证的请求。 如果部署包括使用这些安全提供程序的客户端应用程序和浏览器,则可以使用默认值而不进行其他配置。 如果要对 Windows 集成安全性使用不同的安全提供程序(例如,如果要直接使用 Kerberos),或者修改了默认值并想要还原原始设置,则可以使用本主题中的信息在报表服务器上指定身份验证设置。
若要使用 Windows 集成安全性,需要访问报表服务器的每个用户必须具有有效的 Windows 本地或域用户帐户,或者是 Windows 本地或域组帐户的成员。 只要这些域受信任,就可以包括来自其他域的帐户。 这些帐户必须有权访问报表服务器计算机,随后还必须被分配到角色,以便能够访问特定的报表服务器操作。
还必须满足以下附加要求:
RSeportServer.config 文件必须将
AuthenticationType设置为RSWindowsNegotiate、RSWindowsKerberos或RSWindowsNTLM。 默认情况下,如果报表服务器服务帐户为 NetworkService 或 LocalSystem,则 RSReportServer.config 文件包括RSWindowsNegotiate该设置;否则,将使用该RSWindowsNTLM设置。 如果应用程序仅使用 Kerberos 身份验证,则可以添加RSWindowsKerberos。重要
如果将报表服务器服务配置为在域用户帐户下运行,并且未为帐户注册服务主体名称(SPN),则使用
RSWindowsNegotiate将导致 Kerberos 身份验证错误。 有关详细信息,请参阅本主题中的 “连接到报表服务器时解决 Kerberos 身份验证错误 ”。必须为 Windows 身份验证配置 ASP.NET。 默认情况下,报表服务器 Web 服务和报表管理器 Web.config 文件包括 <身份验证模式=“Windows”> 设置。 如果将其更改为 <身份验证模式=“Forms”>,则 Reporting Services 的 Windows 身份验证将失败。
报表服务器 Web 服务和报表管理器的 Web.config 文件必须设置为 <身份模拟=“true”/>。
客户端应用程序或浏览器必须支持 Windows 集成安全性。
若要更改报表服务器身份验证设置,请编辑 RSReportServer.config 文件中的 XML 元素和值。 可以复制并粘贴本主题中的示例以实现特定组合。
如果所有客户端和服务器计算机都位于同一域或受信任的域中,并且报表服务器部署在企业防火墙后面的内部网访问中,则默认设置效果最佳。 受信任的域和独立域是传递 Windows 凭据的要求。 如果为服务器启用 Kerberos 版本 5 协议,则可以多次传递凭据。 否则,凭据在过期前只能传递一次。 有关为多个计算机连接配置凭据的详细信息,请参阅 为报表数据源指定凭据和连接信息。
以下说明适用于本机模式报表服务器。 如果报表服务器部署在 SharePoint 集成模式下,则必须使用指定 Windows 集成安全性的默认身份验证设置。 报表服务器使用默认 Windows 身份验证扩展插件中的内部功能来支持 SharePoint 集成模式下的报表服务器。
针对身份验证的扩展保护
从 SQL Server 2008 R2 开始,支持扩展身份验证保护。 此 SQL Server 功能支持使用渠道绑定和服务绑定来加强对身份验证的保护。 Reporting Services 功能需要与支持扩展保护的作系统一起使用。 用于扩展保护的 Reporting Services 配置由 RSReportServer.config 文件中的设置确定。 可以通过编辑文件或使用 WMI API 来更新该文件。 有关详细信息,请参阅 使用 Reporting Services 进行身份验证的扩展保护。
将报表服务器配置为使用 Windows 集成安全性
在文本编辑器中打开 RSReportServer.config。
查找 <
Authentication>。复制以下最符合需求的 XML 结构之一。 可以按任意顺序指定
RSWindowsNegotiate、RSWindowsNTLM和RSWindowsKerberos。 如果要对连接进行身份验证,而不是每个单个请求,则应启用身份验证持久性。 在身份验证持久性下,在连接期间将允许所有需要身份验证的请求。当报表服务器服务帐户为 NetworkService 或 LocalSystem 时,第一个 XML 结构是默认配置:
<Authentication> <AuthenticationTypes> <RSWindowsNegotiate /> </AuthenticationTypes> <EnableAuthPersistence>true</EnableAuthPersistence> </Authentication>当报表服务器服务帐户不是 NetworkService 或 LocalSystem 时,第二个 XML 结构是默认配置:
<Authentication> <AuthenticationTypes> <RSWindowsNTLM /> </AuthenticationTypes> <EnableAuthPersistence>true</EnableAuthPersistence></认证>
第三个 XML 结构指定在 Windows 集成安全性中使用的所有安全包:
<AuthenticationTypes> <RSWindowsNegotiate /> <RSWindowsKerberos /> <RSWindowsNTLM /> </AuthenticationTypes>第四个 XML 结构仅在不支持 Kerberos 的部署中,或者为了解决 Kerberos 身份验证错误而指定 NTLM。
<AuthenticationTypes> <RSWindowsNTLM /> </AuthenticationTypes>将其粘贴到现有条目上 <
Authentication>。请注意,您不能将
Custom与RSWindows类型一起使用。适当修改扩展保护设置。 默认情况下禁用扩展保护。 如果这些条目不存在,则当前计算机可能未运行支持扩展保护的 Reporting Services 版本。 有关详细信息,请参阅 Extended Protection for Authentication with Reporting Services
<RSWindowsExtendedProtectionLevel>Allow</RSWindowsExtendedProtectionLevel> <RSWindowsExtendedProtectionScenario>Proxy</RSWindowsExtendedProtectionScenario>保存文件。
如果配置了横向扩展部署,请对部署中的其他报表服务器重复这些步骤。
重新启动报表服务器以清除当前打开的任何会话。
连接到报表服务器时解决 Kerberos 身份验证错误
在配置为协商或 Kerberos 身份验证的报表服务器上,如果出现 Kerberos 身份验证错误,则与报表服务器的客户端连接将失败。 已知在以下情况下会发生 Kerberos 身份验证错误:
报表服务器服务作为 Windows 域用户帐户运行,并且未为帐户注册服务主体名称(SPN)。
报表服务器配置了
RSWindowsNegotiate设置。浏览器在发送到报表服务器的请求的身份验证标头中,优先选择 Kerberos 而非 NTLM。
如果启用了 Kerberos 日志记录,则可以检测错误。 错误的另一个症状是,系统会多次提示输入凭据,然后看到一个空的浏览器窗口。
可以通过从配置文件中删除 <RSWindowsNegotiate /> 并重新尝试连接来确认遇到 Kerberos 身份验证错误。
确认问题后,可以通过以下方式解决该问题:
在域用户帐户下为报表服务器服务注册 SPN。 有关详细信息,请参阅 为报表服务器注册服务主体名称(SPN)。
更改服务帐户以在内置帐户(如网络服务)下运行。 内置帐户会将 HTTP SPN 映射到主机 SPN,这是在将计算机加入网络时定义的。 有关详细信息,请参阅配置服务帐户(SSRS 配置管理器)。
使用 NTLM。 在 Kerberos 身份验证失败的情况下,NTLM 通常会有效。 若要使用 NTLM,请从 RSReportServer.config 文件中删除
RSWindowsNegotiate并验证是否仅RSWindowsNTLM指定。 如果选择此方法,即使未为其定义 SPN,也可以继续使用报表服务器服务的域用户帐户。
日志记录信息
有多种日志记录信息来源可帮助解决 Kerberos 相关问题。
User-Account-Control 属性
确定 Reporting Services 服务帐户是否在 Active Directory 中设置了足够的属性。 查看 Reporting Services 服务跟踪日志文件,查找为 UserAccountControl 属性记录的值。 记录的值采用十进制形式。 需要将十进制值转换为十六进制形式,然后在描述 User-Account-Control Attribute 的 MSDN 主题中找到该值。
Reporting Services 服务跟踪日志条目将类似如下:
appdomainmanager!DefaultDomain!8f8!01/14/2010-14:42:28:: i INFO: The UserAccountControl value for the service account is 590336将十进制值转换为十六进制形式的一个选项是Microsoft Windows计算器。 Windows 计算器支持多种显示“Dec”选项和“Hex”选项的模式。 选择“Dec”选项,粘贴或键入日志文件中找到的十进制值,然后选择“Hex”选项。
然后,请参阅 “User-Account-Control 属性” 主题,以确定服务帐户的属性。
在 Active Directory 中为 Reporting Services 服务帐户配置的 SPN。
若要在 Reporting Services 服务跟踪日志文件中记录 SPN,可以暂时启用 Reporting Services 扩展保护功能。
通过设置以下内容修改配置文件
rsreportserver.config:<RSWindowsExtendedProtectionLevel>Allow</RSWindowsExtendedProtectionLevel> <RSWindowsExtendedProtectionScenario>Any</RSWindowsExtendedProtectionScenario>重新启动 Reporting Services 服务。
如果不希望继续使用扩展保护,请将配置值设置回默认值并重启 Reporting Services 服务帐户。
<RSWindowsExtendedProtectionLevel>Off</RSWindowsExtendedProtectionLevel>
<RSWindowsExtendedProtectionScenario>Proxy</RSWindowsExtendedProtectionScenario>
有关详细信息,请参阅使用 Reporting Services 进行身份验证的扩展保护
浏览器如何选择使用 Kerberos 协议或 NTLM 协议进行协商认证
当您使用 Internet Explorer 连接到报表服务器时,身份验证标头中会指定使用协商 Kerberos 或 NTLM。 NTLM 被使用而不是 Kerberos 当:
请求将发送到本地报表服务器。
请求将发送到报表服务器计算机的 IP 地址,而不是主机标头或服务器名称。
防火墙软件阻止用于 Kerberos 身份验证的端口。
特定服务器的作系统未启用 Kerberos。
该域包括旧版本的 Windows 客户端和服务器作系统,这些作系统不支持内置于较新版本的作系统中的 Kerberos 身份验证功能。
此外,Internet Explorer 可能会根据您设置的 URL、LAN 和代理设置选择使用 Kerberos 协商或 NTLM。
报表服务器 URL
如果 URL 包含完全限定的域名,Internet Explorer 会选择 NTLM。 如果 URL 指定 localhost,Internet Explorer 将选择 NTLM。 如果 URL 指定计算机的网络名称,Internet Explorer 会选择“协商”,这将成功或失败,具体取决于报表服务器服务帐户是否存在 SPN。
客户端上的 LAN 和代理设置
在 Internet Explorer 中设置的 LAN 和代理设置可以决定是否选择 NTLM 而不是 Kerberos。 但是,由于 LAN 和代理设置因组织而异,因此无法精确确定导致 Kerberos 身份验证错误的确切设置。 例如,您的组织可能会强制设置代理,将内网 URL 转换为通过互联网连接解析的完整域名 URL。 如果将不同的身份验证提供程序用于不同类型的 URL,你可能会发现一些连接成功,而你本以为它们会失败。
如果遇到由于身份验证失败而导致的连接错误,可以尝试不同的 LAN 和代理设置组合来隔离问题。 在 Internet Explorer 中,LAN 和代理设置位于“局域网”(LAN)“设置”对话框中,通过单击 Internet 选项的“连接”选项卡上的 LAN 设置打开。
外部资源
- 有关 Kerberos 和报表服务器的其他信息,请参阅 使用 SharePoint、Reporting Services 和 PerformancePoint Monitoring Server 和 Kerberos 部署商业智能解决方案。
另请参阅
使用报表服务器进行身份验证
授予对本机模式报表服务器的权限
RSReportServer 配置文件
在报表服务器上配置基本身份验证
在报表服务器上配置自定义身份验证或窗体身份验证
Reporting Services 针对验证的扩展保护