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

How to: Register a Service Principa...

Community Content

In this section

Statistics Annotations (3)

Click here to expand

Collapse All

Language Filter

SQL Server 2008 Books Online (October 2009)

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.

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

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.
Download and install Windows Server 2003 Service Pack 1 Support Tools from the Download Center.
Log on to the domain controller as domain administrator.
Open a Command Prompt window.
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>
```
Run the command.
Open the RsReportServer.config file and locate the <AuthenticationTypes> section. Add <RSWindowsNegotiate/> as the first entry in this section to enable NTLM.

Tags

: contentbug (x) Add a tag

Community Content

Add new content

Annotations

RS SPN must not include port number

Altg ... Thomas Lee | Edit | Show History

Following this article, we
installed RS , assigned domain user as service account during installation.
created SPNs for reporting services
HTTP/server1.ourdomain.com:80 serviceaccount
HTTP/server1:80 serviceaccount

Even we have chosen to run RS as domain user
setup put <RSWindowsNTLM/> in config file, not <RSWindowsNegotiate/>.

Reporting services was the only web site on this computer, and default port 80 was suggested by RS configuration manager.

After that authorization key in RS config file was changed to <RSWindowsNegotiate/>
and users were unable to see Report Manager - three promts for login/password and blank page.

We have registered a case with Microsoft Premier support ,
and after several days MS support engineer suggested not to use port number :80 in SPN.
We have registered SPN without :80 - that was the solution.

I encourage MS to check, whether this article is thoroughly tested in real world,
or it describes "how it designed to work"

Regards, Vladislavas

Tags

: contentbug (x) rs (x) spn (x) Add a tag

Port number in SPN when using port 80

Arun_NS | Edit | Show History

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.

Incorrect SPN (that we had ):

HTTP/server1.ourdomain.local:80 serviceaccount

Correct SPN:

HTTP/server1.ourdomain.local serviceaccount

Regards,

Arun

Tags

: contentbug (x) spn (x) ssrs (x) Add a tag

Port Number must be omitted in SPN

Jochen Renner | Edit | Show History

This was also the solution for our case.
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.
A network trace had shown that the kerberos authentication failed because of a not resolvable spn record.

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:
"If you only have one domain and are using port 80, you can omit <domainname> and <port> ..."
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.

Regards,
Jochen

Tags

: Add a tag

Flag as ContentBug

Site Feedback

Tasks

Concepts

Other Resources

Help and Information