How to: Register a Service Principal Name (SPN) for a Report Server

If you are deploying Reporting Services in a network that uses the Kerberos protocol for mutual authentication, you must create a Service Principal Name (SPN) for the Report Server service if you configure it to run as a domain user account. Additionally, when you configure a domain user as the service account, the report server must be configured to use NTLM authentication.

About SPNs

An SPN is a unique identifier for a service on a network that uses Kerberos authentication. It consists of a service class, a host name, and a port. On a network that uses Kerberos authentication, an SPN for the server must be registered under either a built-in computer account (such as NetworkService or LocalSystem) or user account. SPNs are registered for built-in accounts automatically. However, when you run a service under a domain user account, you must manually register the SPN for the account you want to use.

To create an SPN, you can use the SetSPN command line utility. For more information, see Setspn Overview on the Microsoft Windows Server TechCenter.

You must be a domain administrator to run the utility on the domain controller.

Syntax

The command syntax for using SetSPN utility to create an SPN for the report server resembles the following:

Setspn -a http/<computername>.<domainname>:<port> <domain-user-account>

SetSPN is available with Windows Server 2003 Service Pack 1 support tool pack, which you must download separately. The -a argument is used to register a service principal name with a particular account.

HTTP is the service class. The Report Server Web service runs in HTTP.SYS. A by-product of creating an SPN for HTTP is that all Web applications on the same computer that run in HTTP.SYS (including applications hosted in IIS) will be granted tickets based on the domain user account. If those services run under a different account, the authentication requests will fail. To avoid this problem, be sure to configure all HTTP applications to run under the same account, or consider creating host headers for each application and then creating separate SPNs for each host header. When you configure host headers, DNS changes are required regardless of the Reporting Services configuration.

The values that you specify for <computername>, <domainname>, and <port> identify the unique network address of the computer that hosts the report server. This can be a local host name or a fully qualified domain name (FQDN). If you only have one domain and are using port 80, you can omit <domainname> and <port> from your command line. <domain-user-account> is the user account under which the Report Server service runs and for which the SPN must be registered.

Register an SPN for Domain User Account

To register an SPN for a Report Server service running as a domain user

  1. Install Reporting Services and configure the Report Server service to run as a domain user account. Note that users will not be able to connect to the report server until you complete the following steps.

  2. Download and install Windows Server 2003 Service Pack 1 Support Tools from the Download Center.

  3. Log on to the domain controller as domain administrator.

  4. Open a Command Prompt window.

  5. Copy the following command, replacing placeholder values with actual values that are valid for your network:

    Setspn -a http/<computer-name>.<domain-name>:<port> <domain-user-account>

  6. Run the command.

  7. Open the RsReportServer.config file and locate the <AuthenticationTypes> section. Add <RSWindowsNegotiate/> as the first entry in this section to enable NTLM.
See Also

Tasks

How to: Configure a Service Account for Reporting Services

Concepts

Configuring the Report Server Service Account
Reporting Services Configuration How-to Topics
Considerations for Installing Reporting Services
Planning for Services, Accounts, and Connections
Tags : contentbug


Community Content

The Hog Dog
Use RSWIndowsNegotiate NOT RSWindowsNTLM When RS and DB are on different Hosts
<p>This article is confusing because the first paragraph seems to conflict with later section "To register an SPN for a Report Server service running as a domain user". The first paragraph says one has to use NTLM. While the latter section says to use RSWindowsNegotiate.<br /><br />This caused a couple hours of frustration and "could not connect to the data source" errors in the report viewer control.<br /><br />If one uses a domain user account for the report server service, and the db server is on a different host from the report server host, the only way I could get it to work was to only have RSWindowsNegotiate. This is confusing because there is another RS authentication type named RSWindowsNTLM. RSWindowsNTLM did NOT work. Only RSWindowsNegotiate did.<br /><br />Hope this helps others bumping up against the same "could not connect to the data source" errors...</p>

Jochen Renner
Port Number must be omitted in SPN
<p>This was also the solution for our case.<br />Our Reporting Infrastructure (for SCOM 2007) has a SQL Server with the Data Warehouse DB and another SQL Server (different Host) with a Reporting Services Instance. In a double hop scenario, where a 3rd system would deploy or run reports we could not use kerberos authentication.<br />A network trace had shown that the kerberos authentication failed because of a not resolvable spn record.<br /><br />Additionally we have multiple domains in our ad forest with report-admins belonging to multiple domains beside the domain hosting the server systems. In this article there is a part where it is mentioned that we have to use the port in the SPN if there a multiple domains:<br />"If you only have one domain and are using port 80, you can omit &lt;domainname&gt; and &lt;port&gt; ..." <br />For our scenario, though having mutliple domains, this is not true. We can use Reporting with users belonging to different domains in one forest without the ports in the SPNs.<br /><br />Regards,<br />Jochen</p>
Tags : ssrs 2008 spn

Arun_NS
Port number in SPN when using port 80
<span> <div> <div>If the SSRS listens in port 80, the article mentions that the port can be omitted but it MUST be omitted for the SPN to work - atleast this was the case in our instance.</div> <div> <br /> </div> <div>Incorrect SPN (that we had ):</div> <div>HTTP/server1.ourdomain.local:80 serviceaccount</div> <div> <br /> </div> <div>Correct SPN:</div> <div>HTTP/server1.ourdomain.local serviceaccount<br /></div> <div> <br /> </div> <div>Regards,</div> <div>Arun</div> </div> </span>

Thomas Lee
RS SPN must not include port number
<p>Following this article, we<br />installed RS , assigned domain user as service account during installation.<br />created SPNs for reporting services<br />HTTP/server1.ourdomain.com:80 serviceaccount<br />HTTP/server1:80 serviceaccount<br /><br />Even we have chosen to run RS as domain user<br />setup put &lt;RSWindowsNTLM/&gt; in config file, not &lt;RSWindowsNegotiate/&gt;.<br /></p> <p>Reporting services was the only web site on this computer, and default port 80 was suggested by RS configuration manager.</p> <p>After that authorization key in RS config file was changed to &lt;RSWindowsNegotiate/&gt;<br />and users were unable to see Report Manager - three promts for login/password and blank page.<br /><br />We have registered a case with Microsoft Premier support ,<br />and after several days MS support engineer suggested not to use port number :80 in SPN.<br />We have registered SPN without :80 - that was the solution.<br /><br />I encourage MS to check, whether this article is thoroughly tested in real world, <br />or it describes "how it designed to work"<br /><br />Regards, Vladislavas<br /><br /><br /><br /></p>
Tags : contentbug rs spn

Page view tracker