在报表服务器上配置 Windows 身份验证
默认情况下,Reporting Services 接受指定 Negotiate 或 NTLM 身份验证的请求。 如果部署中包括使用这些安全提供程序的客户端应用程序和浏览器,则可以使用这些默认值,而无需其他配置。 假设你要对 Windows 集成安全性使用不同的安全提供程序,或者如果你要修改默认值并想要还原原始设置。 你可以使用本文中的信息在报表服务器上指定身份验证设置。
若要使用 Windows 集成安全性,则每个需要访问报表服务器的用户都必须拥有有效的 Windows 本地或域用户帐户。 或者,他们必须是 Windows 本地或域组帐户的成员。 对于其他域,只要这些域可信,您也可以包括其中的帐户。 这些帐户必须具有报表服务器计算机的访问权,并且必须随后分配给相应的角色以便获得特定报表服务器操作的访问权。
还必须满足以下要求:
RSReportServer.config 文件必须将
AuthenticationType
设置为RSWindowsNegotiate
、RSWindowsKerberos
或RSWindowsNTLM
。 默认情况下,如果报表服务器服务帐户是 NetworkService 或 LocalSystem,则 RSReportServer.config 文件包含RSWindowsNegotiate
设置;否则使用RSWindowsNTLM
设置。 如果拥有仅使用 Kerberos 身份验证的应用程序,则可以添加RSWindowsKerberos
。重要
当你使用
RSWindowsNegotiate
时,如果将报表服务器服务配置为在域用户帐户下运行,并且没有为该帐户注册服务主体名称 (SPN),则会产生 Kerberos 身份验证错误。 有关详细信息,请参阅本主题中的连接到报表服务器时纠正 Kerberos 身份验证错误。应为 Windows 身份验证配置 ASP.NET。 默认情况下,报表服务器 Web 服务的 Web.config 文件包括
<authentication mode="Windows">
设置。 如果将其更改为<authentication mode="Forms">
,Reporting Services 的 Windows 身份验证将失败。报表服务器 Web 服务的 Web.config 文件必须具有
<identity impersonate= "true" />
。客户端应用程序或浏览器必须支持 Windows 集成安全性。
Web 门户不需要更多配置。
若要更改报表服务器身份验证设置,需要在 RSReportServer.config 文件中编辑 XML 元素和值。 可以复制并粘贴本文中的示例来实现特定的组合。
如果所有客户端计算机和服务器计算机均位于相同的域或某个可信域中,则默认设置将达到最佳效果。 并且,报表服务器部署在公司防火墙后面,用于内部网访问。 可信域和单个域是传递 Windows 凭据所必需的。 如果为服务器启用 Kerberos 版本 5 协议,则可以多次传递凭据。 否则,凭据在过期之前只能传递一次。 有关为多计算机连接配置凭证的详细信息,请参阅指定报表数据源的凭证和连接信息。
以下说明针对本机模式报表服务器。 如果在 SharePoint 集成模式下部署报表服务器,则必须使用指定 Windows 集成安全性的默认身份验证设置。 报表服务器使用默认 Windows 身份验证扩展插件中的内部功能支持 SharePoint 集成模式下的报表服务器。
针对身份验证的扩展保护
自 SQL Server 2008 R2 (10.50.x) 开始,提供了对针对验证的扩展保护的支持。 此 SQL Server 功能支持使用渠道绑定和服务绑定来加强对身份验证的保护。 Reporting Services 功能需要用于支持扩展保护的操作系统。 你可以通过 RSReportServer.config 文件中的特定设置来确定 Reporting Services 配置以进行扩展保护。 你可以通过编辑此文件或使用 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> </Authentication>
第三个 XML 结构指定 Windows 集成安全性中使用的所有安全包:
<AuthenticationTypes> <RSWindowsNegotiate /> <RSWindowsKerberos /> <RSWindowsNTLM /> </AuthenticationTypes>
第四个 XML 结构仅为不支持 Kerberos 的部署指定 NTLM,或解决 Kerberos 身份验证错误:
<AuthenticationTypes> <RSWindowsNTLM /> </AuthenticationTypes>
将其粘贴在
<Authentication>
的现有条目上。不能将
Custom
与RSWindows
类型一起使用。根据需要适当修改扩展保护的设置。 默认情况下,扩展保护处于禁用状态。 如果这些条目不存在,则当前计算机运行的 Reporting Services 版本可能不支持扩展保护。 有关详细信息,请参阅 Reporting Services 针对身份验证的扩展保护
<RSWindowsExtendedProtectionLevel>Allow</RSWindowsExtendedProtectionLevel> <RSWindowsExtendedProtectionScenario>Proxy</RSWindowsExtendedProtectionScenario>
保存文件。
如果配置了扩展部署,请对该部署中的其他报表服务器重复这些步骤。
重新启动报表服务器以清除当前打开的任何会话。
连接到报表服务器时纠正 Kerberos 身份验证错误
在为 Negotiate 或 Kerberos 身份验证配置的报表服务器上,如果出现 Kerberos 身份验证错误,则客户端与报表服务器的连接将失败。 已知在以下情况下会出现 Kerberos 身份验证错误:
报表服务器服务作为 Windows 域用户帐户运行并且您没有为该帐户注册服务主体名称 (SPN)。
报表服务器是使用
RSWindowsNegotiate
设置配置的。浏览器选择它发送给报表服务器的请求的身份验证标头中 NTLM 上的 Kerberos。
如果启用了 Kerberos 日志记录,则可以检测到该错误。 另一错误症状是多次提示你输入凭证,然后你看到一个空的浏览器窗口。
可以通过从配置文件中删除 <RSWindowsNegotiate>
并重新尝试建立连接来确认你遇到了 Kerberos 身份验证错误。
确认遇到该问题之后,可以采用下列方法解决它:
在域用户帐户下为报表服务器服务注册 SPN。 有关详细信息,请参阅为报表服务器注册服务主体名称 (SPN)。
将服务帐户更改为在网络服务等内置帐户下运行。 内置帐户将 HTTP SPN 映射到将计算机联网时定义的 Host SPN。 有关详细信息,请参阅配置服务帐户(报表服务器配置管理器)。
使用 NTLM。 通常,NTLM 将在 Kerberos 身份验证失败时发挥作用。 若要使用 NTLM,从 RSReportServer.config 文件中删除
RSWindowsNegotiate
并验证仅指定了RSWindowsNTLM
。 如果选择此方法,则可以继续将域用户帐户用于报表服务器服务(即使没有为其定义 SPN)。
若要进行汇总,应运行类似于以下示例的命令。 替换为适当的值。
setspn -S HTTP/<SSRS Server FDQN> <SSRS Service Account>
setspn -S HTTP/<host header for Report server web site> <SSRS Service Account>
setspn -S HTTP/<SharePoint Server FDQN> <SharePoint Application Pool Account>
setspn -S HTTP/<host header for SharePoint site> <SharePoint Application Pool Account>
setspn -S HTTP/Dummy <Claims to Windows Taken Service Account>
记录信息
多种日志记录信息源可以帮助解决与 Kerberos 相关的问题。
用户-帐户-控制属性
确定 Reporting Services 服务帐户在 Active Directory 中是否具有足够的属性集。 检查 Reporting Services 服务跟踪日志文件,以找到为 UserAccountControl 属性记录的值。 记录的值为十进制格式。 您需要将十进制值转换为十六进制格式,然后在描述用户-帐户-控制属性的 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
选项,粘贴或键入在日志文件中找到的十进制值,然后选择“十六进制”选项。然后,参阅文章用户-帐户-控制属性以获得服务帐户的属性。
在 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 还可能选择协商 Kerberos 或 NTLM,这取决于您如何配置的 URL、LAN 和代理设置。
报表服务器 URL
如果该 URL 包括完全限定域名,则 Internet Explorer 将选择 NTLM。 如果该 URL 指定本地主机,则 Internet Explorer 选择 NTLM。 如果该 URL 指定计算机的网络名称,则 Internet Explorer 将选择协商,这将会成功或失败,取决于报表服务器服务帐户是否存在 SPN。
客户端上的 LAN 和代理设置
在 Internet Explorer 中设置的 LAN 和代理设置可以确定是否在 Kerberos 上选择 NTLM。 但是,由于各组织的 LAN 和代理设置会有所不同,因此不可能准确确定造成 Kerberos 身份验证错误的设置。 例如,您的组织可能会强制实施将 URL 从 Intranet URL 转换为通过 Internet 连接解析的完全限定域名 URL 的代理设置。 如果将不同的身份验证提供程序用于不同类型的 URL,则你可能会发现原本预计会失败的某些连接竟然成功了。
你可能会遇到你认为由于身份验证失败而导致的连接错误。 如果是这样,你可以尝试 LAN 和代理设置的不同组合来隔离问题。 在 Internet Explorer 中,LAN 和代理设置位于“局域网 (LAN) 设置”对话框中,可以通过选择“Internet 选项”的“连接”选项卡上的“LAN 设置”打开该对话框。
Kerberos 和报表服务器的附加信息
- 有关 Kerberos 和报表服务器的详细信息,请参阅 Deploying a Business Intelligence Solution Using SharePoint, Reporting Services, and PerformancePoint Monitoring Server with Kerberos(通过 Kerberos 部署使用 SharePoint、Reporting Services 和 PerformancePoint Monitoring Server 的商业智能解决方案)。