Authentication with the report server

SQL Server Reporting Services (SSRS) offers several configurable options for authenticating users and client applications against the report server. By default, the report server uses Windows Integrated authentication and assumes trusted relationships where client and network resources are in the same domain or in a trusted domain. Depending on your network topology and the needs of your organization, you can customize the authentication protocol that is used for Windows Integrated authentication. Or, you can use Basic authentication or a custom forms-based authentication extension that you provide. Each of the authentication types can be turned on or off individually. You can enable more than one authentication type if you want the report server to accept requests of multiple types.

All users or applications who request access to report server content or operations must be authenticated before access is allowed.

Authentication types

All users or applications who request access to report server content or operations must be authenticated using the authentication type configured on the report server before access is allowed. The following table describes the authentication types supported by Reporting Services.

AuthenticationType Name HTTP Authentication Layer value Used by default Description
RSWindowsNegotiate Negotiate Yes Attempts to use Kerberos for Windows Integrated authentication first, but falls back to NTLM if Active Directory can't grant a ticket for the client request to the report server. Negotiate only falls back to NTLM if the ticket isn't available. If the first attempt results in an error rather than a missing ticket, the report server doesn't make a second attempt.
RSWindowsNTLM NTLM Yes Uses NTLM for Windows Integrated authentication.

The credentials aren't delegated or impersonated on other requests. Subsequent requests follow a new challenge-response sequence. Depending on network security settings, a user might be prompted for credentials or the authentication request are handled transparently.
RSWindowsKerberos Kerberos No Uses Kerberos for Windows Integrated authentication. You must configure Kerberos by setting up setup service principal names (SPNs) for your service accounts, which requires domain administrator privileges. You can set up identity delegation with Kerberos. When you do, the token of the user who is requesting a report can also be used on another connection to the external data sources that provide data to reports.

Before you specify RSWindowsKerberos, be sure that the browser type you're using actually supports it. If you're using Microsoft Edge, or Internet Explorer, Kerberos authentication is only supported through Negotiate. Microsoft Edge, or Internet Explorer, doesn't 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 Transport Layer Security (TLS), previously known as Secure Sockets Layer (SSL) to encrypt user account information before the information 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're deploying a custom authentication module that handles all authentication requests on the report server. You can't use the Custom authentication type with the default Windows Authentication extension.

Unsupported authentication methods

The following authentication methods and requests aren't supported.

Authentication method Explanation
Anonymous The report server doesn't accept unauthenticated requests from an anonymous user, except for those deployments that include a custom authentication extension.

Report Builder accepts 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's 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 doesn't support ISAPI filters. If the SSO technology you're 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 you should use ISA Server directly.
Passport Not supported in SQL Server Reporting Services.
Digest Not supported in SQL Server Reporting Services.

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 returns HTTP 401 Access Denied errors for HTTP requests that can't 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 the web portal always use the same authentication type. You can't 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 can't configure different nodes in the same scale-out to use different authentication types.

Background processing doesn't 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 authentication is configured.

In this section

Task Descriptions Links
Configure the Windows Integrated authentication type. Configure Windows authentication on the report server
Configure the Basic authentication type. Configure Basic authentication on the report server
Configure forms authentication or otherwise a Custom authentication type. Configure custom or forms authentication on the report server
Enable the web portal to handle the custom authentication scenario. Configure the web portal to pass custom authentication cookies

Grant permissions on a native mode report server
RsReportServer.config configuration file
Create and manage role assignments
Specify credential and connection information for report data sources
Implement a security extension
Configure TLS connections on a native mode report server
Security extensions overview
Authentication in Reporting Services
Authorization in Reporting Services

More questions? Try asking the Reporting Services forum