Recently, I’ve helped several customers with Kerberos authentication problems with Reporting Services and Analysis Services, so I’ve decided to write this blog post and pull together some useful resources in one place (there are 2 whitepapers in particular that I found invaluable configuring Kerberos authentication, and these can be found in
the references section at
the bottom of this post). In most of these cases,
the problem has manifested itself with
the Login failed for User ‘NT Authority\Anonymous’ (“double-hop”) error. By default, Reporting Services uses Windows Integrated Authentication, which includes
the Kerberos and NTLM protocols for network authentication. Additionally, Windows Integrated Authentication includes
the negotiate security header, which prompts
the client to select Kerberos or NTLM for authentication.
The client can access reports which have
the appropriate permissions by using Kerberos for authentication. Servers that use Kerberos authentication can impersonate those clients and use their security context to access network resources. You can configure Reporting Services to use both Kerberos and NTLM authentication; however this may lead to a failure to authenticate. With negotiate, if Kerberos cannot be used,
the authentication method will default to NTLM. When negotiate is enabled,
the Kerberos protocol is always used except when: Clients/servers that are involved in
the authentication process cannot use Kerberos.
The client does not provide
the information necessary to use Kerberos. An in-depth discussion of Kerberos authentication is beyond
the scope of this post, however when users execute reports that are configured to use Windows Integrated Authentication, their logon credentials are passed from
the report server to
the server hosting
the data source. Delegation needs to be set on
the report server and Service Principle Names (SPNs) set for
the relevant services. When a user processes a report,
the request must go through a Web server on its way to a database server for processing. Kerberos authentication enables
the Web server to request a service ticket from
the domain controller; impersonate
the client when passing
the request to
the database server; and then restrict
the request based on
the user’s permissions. Each time a server is required to pass
the request to another server,
the same process must be used. Kerberos authentication is supported in both native and SharePoint integrated mode, but I’ll focus on native mode for
the purpose of this post (I’ll explain configuring SharePoint integrated mode and Kerberos authentication in a future post). Configuring Kerberos avoids
the authentication failures due to double-hop issues. These double-hop errors occur when a users windows domain credentials can’t be passed to another server to complete
the user’s request. In
the case of my customers, users were executing Reporting Services reports that were configured to query Analysis Services cubes on a separate
machine using Windows Integrated security.
The double-hop issue occurs as NTLM credentials are valid for only one network hop, subsequent hops result in anonymous authentication.
The client attempts to connect to
the report server by making a request from a browser (or some other application), and
the connection process begins with authentication. With NTLM authentication, client credentials are presented to Computer 2. However Computer 2 can’t use
the same credentials to access Computer 3 (so we get
the Anonymous login error). To access Computer 3 it is necessary to configure
the connection string with stored credentials, which is what a number of customers I have worked with have done to workaround
the double-hop authentication error. However, to get
the benefits of Windows Integrated security, a better solution is to enable Kerberos authentication. Again,
the connection process begins with authentication. With Kerberos authentication,
the client and
the server must demonstrate to one another that they are genuine, at which point authentication is successful and a secure client/server session is established. In
the illustration above,
the tiers represent
the following: Client tier (computer 1):
The client computer from which an application makes a request. Middle tier (computer 2):
The Web server or farm where
the client’s request is directed. Both
the SharePoint and Reporting Services server(s) comprise
the middle tier (but we’re only concentrating on native deployments just now). Back end tier (computer 3):
The Database/Analysis Services server/Cluster where
the requested data is stored. In order to enable Kerberos authentication for Reporting Services it’s necessary to configure
the relevant SPNs, configure trust for delegation for server accounts, configure Kerberos with full delegation and configure
the authentication types for Reporting Services. Service Principle Names (SPNs) are unique identifiers for services and identify
the account’s type of service. If an SPN is not configured for a service, a client account will be unable to authenticate to
the servers using Kerberos. You need to be a domain administrator to add an SPN, which can be added using
the SetSPN utility. For Reporting Services in native mode,
the following SPNs need to be registered --SQL Server Service SETSPN -S mssqlsvc/servername:1433 Domain\SQL For named instances, or if
the default instance is running under a different port, then
the specific port number should be used. --Reporting Services Service SETSPN -S http/servername Domain\SSRS SETSPN -S http/servername.domain.com Domain\SSRS
The SPN should be set for
the NETBIOS name of
the server and
the FQDN. If you access
the reports using a host header or DNS alias, then that should also be registered SETSPN -S http/www.reports.com Domain\SSRS --Analysis Services Service SETSPN -S msolapsvc.3/servername Domain\SSAS Next, you need to configure trust for delegation, which refers to enabling a computer to impersonate an authenticated user to services on another computer: Location Description Client 1.
The requesting application must support
the Kerberos authentication protocol. 2.
The user account making
the request must be configured on
the domain controller. Confirm that
the following option is not selected: Account is sensitive and cannot be delegated. Servers 1.
The service accounts must be trusted for delegation on
the domain controller. 2.
The service accounts must have SPNs registered on
the domain controller. If
the service account is a domain user account,
the domain administrator must register
the SPNs. In Active Directory Users and Computers, verify that
the domain user accounts used to access reports have been configured for delegation (the ‘Account is sensitive and cannot be delegated’ option should not be selected): We then need to configure
the Reporting Services service account and computer to use Kerberos with full delegation: We also need to do
the same for
the SQL Server or Analysis Services service accounts and computers (depending on what type of data source you are connecting to in your reports). Finally, and this is
the part that sometimes gets over-looked, we need to configure
the authentication type correctly for reporting services to use Kerberos authentication. This is configured in
the Authentication section of
the RSReportServer.config file on
the report server. <Authentication> <AuthenticationTypes> <RSWindowsNegotiate/> </AuthenticationTypes> <EnableAuthPersistence>true</EnableAuthPersistence> </Authentication> This will enable Kerberos authentication for Internet Explorer. For other browsers, see
the link below.
The report server instance must be restarted for these changes to take effect. Once these changes have been made, all that’s left to do is test to make sure Kerberos authentication is working properly by running a report from report manager that is configured to use Windows Integrated authentication (either connecting to Analysis Services or SQL Server back-end). Resources: Manage Kerberos Authentication Issues in a Reporting Services Environment http://download.microsoft.com/download/B/E/1/BE1AABB3-6ED8-4C3C-AF91-448AB733B1AF/SSRSKerberos.docx Configuring Kerberos Authentication for Microsoft SharePoint 2010 Products http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=23176 How to: Configure Windows Authentication in Reporting Services http://msdn.microsoft.com/en-us/library/cc281253.aspx RSReportServer Configuration File http://msdn.microsoft.com/en-us/library/ms157273.aspx#Authentication Planning for Browser Support http://msdn.microsoft.com/en-us/library/ms156511.aspx
