Home » Uncategorized » SharePoint 2013 Integrated Mode, Reporting Service Application (Login failed for user)

SharePoint 2013 Integrated Mode, Reporting Service Application (Login failed for user)

Reporting Service application hosted in SharePoint 2013 application server causing endless fail logins when running rendering a report.

I couldn’t find any quick and easy Microsoft documentation or information round setting up Kerberos, so here is my configuration to get this working successfully.

This blog assumes you have already configured your Web Applications and SQL Server service accounts and SharePoint Computer accounts for Kerberos Authentication

Error:

Cannot create a connection to data source ‘DataSource’. —> System.Data.SqlClient.SqlException: Login failed for user ‘NT AUTHORITY\ANONYMOUS LOGON’.

SharePoint Setup:

SharePoint Web Application (that is associated with the Reporting Services Application proxy) is configured to Claims Based Authentication and setup for Windows Authentication / Negotiate as the authentication provider.

Reporting Service Application

Specified a service identity account (SPSSRSAppPool) for host the Reporting Service Application IIS processes.

Configure Kerberos for Reporting service account for constrained delegation

  1. On your domain controller run, setspn -a http/ domainname\SPSSRSAppPool
  2. Delegation tab in AD for SPSSRSAppPool account (Trust this user delegation to specified services only)
  3. Use any authentication protocol
  4. Specify all your service accounts running under your Web applications, every site should be setup with HTTP SPNs (if not then register them using setspn and configure your sites for Kerberos authentication)
  5. Specify your SQL Server MSSQLSvc SPNS for your SharePoint database server (if not then register them using setspn and configure your SharePoint database server)

Claims to Windows Token Services (SharePoint Service is started)

Specified a service identity account (SPC2WTS) to run the Claims services on every farm server except Web Apps and SQL Server.

Setup the server security for the Claims account under the local security policy on each farm server (except Web Apps, SQL Server)

  1. Membership in the local Administrators Group on all farm servers (except Web Apps, SQL Server)
  2. Grant the rights to impersonate a client after authentication
  3. Logon as a service
  4. Act as a part of the operating system

Configure Kerberos for Claims service account for constrained delegation

  1. On your domain controller run, setspn -a http/ domainname\spc2wts
  2. Delegation tab in AD for SPC2WTS Account (Trust this user delegation to specified services only)
  3. Use any authentication protocol
  4. Specify all your service accounts running under your Web applications, every site should be setup with HTTP SPNs (if not then register them using setspn and configure your sites for Kerberos authentication)
  5. Specify your SQL Server MSSQLSvc SPNS for your SharePoint database server (if not then register them using setspn and configure your SharePoint database server)

Configure Reporting Service Application to Kerberos Authentication:

Modify the RSReporting.config and add RSWindowsNegotiate for the Authentication Provider.

RSReporting file is located under the Application farm server or which ever server you Installed the SSRS service on.

  1. C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\WebServices\Reporting (SharePoint 2013)
  2. C:\Program Files\Common Files\microsoft shared\Web Server Extensions\14\WebServices\Reporting (SharePoint 2010)

Make sure your Authentication section in your RSReporting.config file looks like this:

<Authentication>
<AuthenticationTypes>
<RSWindowsNegotiate/>
</AuthenticationTypes>
<EnableAuthPersistence>true</EnableAuthPersistence>
</Authentication>

Perform IISRESETS or Reboot.


3 Comments

  1. Vladimir says:

    Thanks Chris, this guide worked great for me.
    Followed exact instructions and after changing SSRS service account to use constrained delegation, the anonymous logon error went away and I was able to successfully render the reports.

  2. I am having lots of trouble getting this to work. Do we really need two accounts, one for the application pool and another one for c2wts?

    • I recommend you do have separate accounts. Generally it’s best to have designated service accounts when configuring the platform services, otherwise your farm security might be subjected to unexpected issues, however you can use a single farm account that covers the aspect of every permission for every farm services. It’s an all round ugly approach and don’t recommend it.

Leave a comment