Scenario based Kerberos setup with Reporting Service in Sharepoint integration mode.

It’s always been a challenge to setup Kerberos in environments where there would be multiple tiers involved for an application. As the number of tiers increase, there is an increase in the number of hops that would take place. It becomes even more difficult when Enterprise level applications like Reporting Services and SharePoint are integrated together. In this blog we are going to look at the various settings that need to be performed to get Kerberos working in a Reporting Services-SharePoint integrated environment.


Reporting Services:

     Server Name: ReportingServices

Instance Name: Reporting Services is installed as a Default Instance

     URL:  http://ReportingServices/reportserver

     Web identity: xyz\reportingservicessvc



     It had 3 SharePoint Web front ends (WFE):

1.  First WFE:

a.  Server Name: WFE1

b.  Load Balanced

2.  Second WFE:

a.  Server Name: WFE2

b.  Load Balanced

3.  Third WFE:

a.  Server Name: WFE3

b.  Central Administrator Installed


Application Pool Identity: xyz\sharepointsvc

     SharePoint site that is to be configured to use Kerberos:


This is a host header for the website. This has been mapped to the IP address of the website in the DNS.


SQL Server:

     Server Name: sqlserver

     Service Account: xyz\sqlsvc


We need to perform the following steps for configuring Kerberos for the above environment:

1.  Set SPNs for the SharePoint Site, central Administrator site, Reporting Services and SQL Server.

The first step to setup Kerberos is to setup the SPNs for the various components that are involved. If we consider the above environment, we will have to set the following SPNs:


   Setspn –a http/kerberos  xyz\sharepointsvc

   Setspn –a http/  xyz\sharepointsvc


NOTE: Since there is a host header being used for the website, the SPNs needs to be created for the host header.


   Central Administrator:

   Setspn –a http/WFE3  xyz\sharepointsvc

   Setspn –a http/  xyz\sharepointsvc


NOTE: Since there is no host header being used for the central administrator site, the SPNs needs to be created for the computer on which the central administrator is being hosted.


   Reporting Services:

   Setspn –a http/ ReportingServices xyz\reportingservicessvc

   Setspn –a http/  xyz\reportingservicessvc



NOTE: Since there is no host header being used for the report server, the SPNs needs to be created for the computer on which the reporting services is being hosted.


   SQL Server:

   Setspn –a MSSQLSvc/ sqlserver:1433  xyz\sqlsvc

   Setspn –a  MSSQLSvc/  xyz\sqlsvc


NOTE: The port on which the SQL Server is listening needs to be provided along with the server name. For the default instance the port would be 1433.


2.  Setting the Authentication Providers for the Reporting Services website, Central Administrator website and SharePoint website.


We need to change the authentication provider of the websites to “Negotiate, NTLM”. So that the websites would first negotiate with the client on the authentication protocol that needs to be used .i.e. Kerberos or NTLM. To do this we need to open a command Prompt and then we need to go to the path where we have the adminscripts for the websites. By default it would be located at “C:\inetpub\adminscripts”.


We first need to check the authentication provider of the website.


cscript adsutil.vbs get w3svc/<WEB SITE IDENTIFIER>/root/NTAuthenticationProviders


If the above mentioned command does not return any authentication provider, we NEED NOT change the authentication provider. If “NTLM” is returned by the above mentioned command, then we need to execute the below mentioned commands. If “Negotiate, NTLM” is returned, we need not change the authentication provider.


NOTE: We need to check the authentication providers of all the websites before we change them.

The commands that are need to be executed for changing the authentication providers are mentioned below.


Reporting Services:

cscript adsutil.vbs set w3svc/<WEB SITE IDENTIFIER>/root/NTAuthenticationProviders “Negotiate,NTLM”


SharePoint Site: (

cscript adsutil.vbs set w3svc/<WEB SITE IDENTIFIER>/root/NTAuthenticationProviders “Negotiate,NTLM”


Central Administrator:

cscript adsutil.vbs set w3svc/<WEB SITE IDENTIFIER>/root/NTAuthenticationProviders “Negotiate,NTLM”


The Authentication Provider of the SharePoint Site needs to be changed from the Central Administrator. You need to click on Application management -> Security -> Authentication Providers. The Authentication provider needs to be changed to Negotiate, NTLM


3.  The SharePoint, Central Administrator and the Reporting Services websites needs to be configured to use “Integrated Authentication”. This can be done from the IIS. You need to go to the IIS manager and then browse to the website. Right click on the website and select properties. In the properties you need to go to the “Directory Security” Tab and then you need to select “Integrated Authentication”.


4.  For the reporting services, we need to change the authentication mode. It can be changed by going to the central administrator. In central administrator you can change the “Authentication Mode” under “Application Management” -> “Reporting Services” -> “Manage Integration Settings”. The authentication mode needs to be set to “Windows Authentication” and NOT “Trusted Account”. If set to trusted account, it would cause the Kerberos to fail.


5.  Authentication provider of the SharePoint site ( can be changed from the central administrator. You can change the authentication provider from “Authentication Providers” option under “Application Management” -> “Application Security”. Under the “Authentication Providers” Tab, you need to select the “WEB APPLICATION” for which the provider is being changed. In our case, we need to select Once the web application is selected, we need to click on the “ZONE” for which we are modifying the provider. In our case, it’s the default zone. Once the “Edit Authentication” page opens, we need to select the “Authentication Type” as “Windows”, We need to uncheck “Enable Anonymous access” and we need to check “Integrated Windows Authentication” “Negotiate (Kerberos)”. More details about changing the authentication provider can be found at the following location:


6.  All the servers on which we have SharePoint, Reporting Services and SQL Server installed needs to be trusted for delegation



7.  The service accounts need to be trusted for delegation. So in the above environment we need to make sure that the accounts “xyz\sharepointsvc”, “xyz\reportingservicessvc” and “xyz\sqlsvc” should be trusted for delegation.


8.  The service accounts should also be made a part of the following groups:


a.  Act as part of operating system.

b.  Impersonate a client after authentication.


9.  The option “Account is sensitive and not trusted for delegation” should be unchecked for the application pool account and the service account.


10.     Last but not the least, the host header for the website should be an “A- Record” in the DNS and not a CANONICAL NAME. If the host header is a canonical name, it would cause the Kerberos to fail. This is due to the reason that the client would create a SPN based on the resolution of the name according to the A-Record. If the A-Record is not set, the resolution would not happen in a proper way and the SPNs with which the client would go to the domain controller might be wrong and since the SPNs would be wrong and would not be set in the active directory, Kerberos would fail.


PS: All the names and environment discussed above are imaginary and does not exist. 


Gurpreet Singh, SSRS Engineer.


Comments (0)

Skip to main content