Authentication Types in Reporting Services
Reporting Services handles all authentication functions for HTTP requests through either the Windows Authentication extension that is installed with the server or a custom authentication extension that you deploy. The Windows Authentication extension supports multiple authentication types so that you can precisely control which HTTP requests a report server will accept. Authentication types include: RSWindowsNegotiate, RSWindowsKerberos, RSWindowsNTLM, and RSWindowsBasic. Each of these authentication types can each be turned on or off individually. You can enable more than one type if you want the report server to accept requests of multiple types.
Note
In previous versions of Reporting Services, all authentication support was provided by IIS. In this release, IIS is no longer used. Reporting Services handles all authentication requests internally.
Authentication Types
The following table describes the authentication types supported by Reporting Services.
AuthenticationType Name |
HTTP Authentication Layer value |
Used by default |
Description |
|---|---|---|---|
RSWindowsNegotiate |
Negotiate |
Yes |
RSWindowsNegotiate directs the report server to handle authentication requests that specify Negotiate. Negotiate attempts Kerberos authentication first, but falls back to NTLM if Active Directory cannot grant a ticket for the client request to the report server. Negotiate will only fall back to NTLM if the ticket is not available. If the first attempt results in an error rather than a missing ticket, the report server does not make a second attempt. |
RSWindowsNTLM |
NTLM |
Yes |
NTLM authenticates a user through an exchange of private data described as challenge-response. The credentials will not be delegated or impersonated on other requests. Subsequent requests will follow a new challenge-response sequence. Depending on network security settings, a user might be prompted for credentials or the authentication request will be handled transparently. |
RSWindowsKerberos |
Kerberos |
No |
For requests that specify Kerberos authentication, the report server reads permissions on the security token of the user who issued the request. If delegation is enabled in the domain, the token of the user who is requesting a report can also be used on an additional connection to the external data sources that provide data to reports. Before you specify RSWindowsKerberos, be sure that the browser type you are using actually supports it. If you are using Internet Explorer, Kerberos authentication is only supported through Negotiate. Internet Explorer will not formulate an authentication request that specifies Kerberos directly. |
RSWindowsBasic |
Basic |
No |
Basic authentication is defined in the HTTP protocol and can only be used to authenticate HTTP requests to the report server. Credentials are passed in the HTTP request in base64 encoding. If you use Basic authentication, use Secure Sockets Layer (SSL) to encrypt user account information before it is sent across the network. SSL provides an encrypted channel for sending a connection request from the client to the report server over an HTTP TCP/IP connection. For more information, see Using SSL to Encrypt Confidential Data on the Microsoft TechNet Web site. |
Custom |
(Anonymous) |
No |
Anonymous authentication directs the report server to ignore authentication header in an HTTP request. The report server accepts all requests, but call on a custom ASP.NET Forms authentication that you provide to authenticate the user. Specify Custom only if you are deploying a custom authentication module that handles all authentication requests on the report server. You cannot use the Custom authentication type with the default Windows Authentication extension. |
Unsupported Authentication Methods
The following authentication methods and requests are not supported.
Authentication method |
Explanation |
|---|---|
Anonymous |
The report server will not accept unauthenticated requests from an anonymous user, except for those deployments that include a custom authentication extension. Report Builder will accept unauthenticated requests if you enable Report Builder access on a report server that is configured for Basic authentication. For all other cases, anonymous requests are rejected with an HTTP Status 401 Access Denied error before the request reaches ASP.NET. Clients receiving 401 Access Denied must reformulate the request with a valid authentication type. |
Single sign-on technologies (SSO) |
There is no native support for single sign-on technologies in Reporting Services. If you want to use a single sign-on technology, you must create a custom authentication extension. The report server hosting environment does not support ISAPI filters. If the SSO technology you are using is implemented as an ISAPI filter, consider using the ISA Server built-in support for RSASecueID or the RADIUS protocol. Otherwise, you can create an ISA Server ISAPI or an HTTPModule for RS, but it is recommended you use ISA Server directly. |
Passport |
Not supported in SQL Server 2008. |
Digest |
Not supported in SQL Server 2008. |
How to Configure Authentication Settings
Authentication settings are configured for default security when the report server URL is reserved. If you modify these settings incorrectly, the report server will return HTTP 401 Access Denied errors for HTTP requests that cannot be authenticated. Choosing an authentication type requires that you already know how Windows Authentication is supported in your network. At least one authentication type must be specified. Multiple authentication types can be specified for RSWindows. RSWindows authentication types (that is, RSWindowsBasic, RSWindowsNTLM, RSWindowsKerberos, and RSWindowsNegotiate) are mutually exclusive with Custom.
Important
Reporting Services does not validate the settings you specify to determine whether they are correct for your computing environment. It is possible that default security will not work for your installation, or that you will specify configuration settings that are not valid for your security infrastructure. For this reason, it is important that you carefully test your report server deployment in controlled test environment before making it available to your larger organization.
The Report Server Web service and Report Manager always use the same authentication type. You cannot configure different authentication types for the feature areas of the Report Server service. If you have a scale-out deployment, be sure to duplicate all of your changes on all nodes in the deployment. You cannot configure different nodes in the same scale-out to use different authentication types.
Background processing does not accept requests from end-users, however it does authenticate all requests for unattended execution purposes. It always uses Windows Authentication and it authenticates requests using the Report Server service or the unattended execution account if it is configured.
For more information about configuring authentication in Reporting Services, see the following topics:
How to: Configure Windows Authentication in Reporting Services
How to: Configure Basic Authentication in Reporting Services
How to: Configure Custom or Forms Authentication in Reporting Services