What is a SPN and How Does the Tool Create Them?

A SPN is the name by which a client uniquely identifies an instance of a service. If you install multiple service instances on computers throughout a domain, each instance must have its own unique SPN. You can’t have duplicate SPNs because this is analogous to having multiple PCs on a network with the same name. Basically, you can’t resolve which computer made a request because multiple computers have the same name. If a machine has multiple services, each must have a unique SPN. In our case SPNs are tied to Service Accounts. There can be multiple service accounts on a machine. Each service account is tied to a service instance on a machine. In other words, a machine can have multiple SPNs via the service accounts. This is accomplished by either using host headers for multiple services, multiple IP addresses, or multiple SPN Service Classes. You can read more detail at: http://support.microsoft.com/?id=929650.

SPN Terminology

• Host: This is the Pre-Windows 2000 Domain Name System (DNS) of the computer

• Port: This is the port number that the service is listening on

Note: If a Host Header is used, it will replace the Host and Port number above.

• ServiceClass: This identifies the general class of service.

Service Classes supported by the tool are (HTTP, MSSQLSvc, MSOLAPSvc.3 and MSOLAPSvc). HTTPS is the same as HTTP from a SPN perspective.

The tool always generates SPNs in pairs (FQDN and Net BIOS). The only reason that the tool wouldn’t generate a pair of SPNs is that one of the SPNs already exists in the domain!

If you are using a Default Installation of a product, you DON’T need to use the port (for example, don’t list port 80 for HTTP as this is the default port).

Defining a SPN / SPN Format

The tool creates SPNs in the following format based on the program setspn.exe. It can be found in the Windows Support Tools for Windows Server 2003 or there is a new version that supports more functionality in Active Directory 2008.

Setspn.exe must be installed on your Domain Controller.

SPN Format

setspn.exe –a <ServiceClass>/<Host : Port> <ServiceAccount>

Note: The –a is for add, –l for list, and –d for delete.

ServiceClass, (Host, Port or Host Header) are defined above.

The tool always generates SPNs in Pairs – host computer account name using the Pre-Windows 2000 Domain Name System (DNS) name and a Fully Qualified Domain Name (FQDN). Both of these entries are required for host-based SPNs.

Since we want to use Constrained Delegation with Windows Integrated Security, we will use a domain user account “Service Account” to create SPNs. The service account will be qualified with the Pre-Windows 2000 Domain Name System as shown in the example below.

Add SPNs Example

Host (Machine Name): PortalMachine

Port: 80

Service Class: HTTP

Service Account: MOSS_Account

FQDN: YourDomain.com

Pre-Windows 2000 Domain Name System: PreDNS

setspn.exe –a HTTP/PortalMachine PreDNS\MOSS_Account

setspn.exe –a HTTP/PortalMachine.YourDomain.com PreDNS\MOSS_Account

Note: port 80 is not shown in the SPN as port 80 is the default port for HTTP.

Enough about SPNs, Get to the Tool Process.

The benefit of using the tool is that it asks for data that you can look up. I’m not going to go over every field for each entry (that will be for later posts); however, I will discuss the basic tool process flow.

Step 0. Before using the tool, make a Drawing showing the data flows from User to Database.

Step 1. Browse Instructions, Go to the Main Tab

Naturally, I have assumed that you have download the Kerberos SPN Generation Setup Tool Beta at FUTURESULTS, LLC and that you have Excel 2007. You must enable Macros in order to use the tool. Browse the instructions for any further understanding of each tab. The Main tab gives you navigation to all of the parts of the spreadsheet (by using links) and gives you visual clues as to errors and completeness of entry. You must complete a section in its entirety in order to see a “Green Light”. You must complete the “Common” section and at least one other “BI Application” section in order to generate SPNs. You also must resolve all errors prior to generating SPNs.

Step 2. Fill out Common Tab

This information can be found in your Domain Controller. Currently the Tool assumes a single domain.

Step 3. Fill out at Least One BI Product

These sections are SSRS2005, SSRS2008, SSAS2008, ProClarity (PAS), PerformancePoint (PPS), and SharePoint (MOSS2007). The information in these sections can be obtained by looking up product configuration information for each product of interest. You must fill out at least one of these application sections. You can fill out all of the application products as well. Need more space? Start another spreadsheet. Each section shows errors and gives you an indication of your data entry progress. Make sure to see the “Green Light” prior to leaving the section. If you decide not to use the section, you must delete any partial entry information.

Step 4. Add Extra Accounts (OtherAccounts Tab)

It generally takes a long time to search every machine and account for duplicate SPNs. In order to speed up this process, use this tab to list machines and service accounts that may contain SPN information and is not listed in the prior steps. THESE ARE THE ONLY ACCOUNTS THAT THE TOOL CHECKS FOR DUPLICATE SPNS. IF YOU HAVE A LARGE NUMBER OF ACCOUNTS OR IF YOU NEED TO CHECK THE ENTIRE DOMAIN OR FOREST FOR DUPLICATE SPNS, I SUGGEST USING DHCHECK.VBS OR IN ACTIVE DIRECTORY 2008, YOU CAN USE THE SETSPN COMMAND WITH A –F OR –X SWITCH.

Step 5. Generate SPNs

When you are ready to Generate SPNs, the tool interrogates your Domain Controller and checks for SPNs that already exist based on the accounts entered. Since the tool knows how to generate the SPNs needed and knows which SPNs exist, it should not create a duplicate SPN. In other words if the information entered would generate a duplicate SPN, the tool will not suggest this as a new SPN. You can view the “Unique SPNs Suggested to Add” on the SPNOutput Tab. The advantage of this method is that you can first use the tool to document your existing setup (as it shouldn’t generate any new SPNs if properly setup). Then if you add a new product, you can just add the new product information and generate SPNs again. You can view the new “Unique SPNs Suggested to Add” on the SPNOutput Tab. Only the “Unique SPNs Suggested to Add” will be output in the Export process. This allows you the capability to double check your existing setup and get comfortable with the tool prior to exporting anything to your Domain Controller. You can then incrementally add new products or use the tool for an entirely new setup.

After you have completed Step 5, you output the “Unique SPNs Suggested to Add” into a file. Currently I have made this a .txt file so that it can be emailed to your Domain Administrators for implementation. Once they receive the file, they can copy it to the Domain Controller and change the extension from .txt to .bat. To run the batch file, I suggest piping the output to a file for your review.

Example Export Process:

Export “SPNs to Add” to a file named SPNs2Add.txt

Copy the file to the Domain Controller

Change the name to SPNs2Add.bat

Run the file on the Domain Controller with the following command: SPNs2Add.bat>SPNs2AddOutput.txt

Review the SPNs2AddOutput.txt file. It should list the Registered ServicePrincipalNames (SPNs) for the accounts before and after the change. It will also show if the change was successful –> “Updated object” will be in the file for each SPN 2 Add. The output file basically shows you the before and after snapshot of the service account.

ALWAYS GENERATE THE EXPORT SPNs TO REMOVE (UNDO) FILE AT THE SAME TIME AS THE EXPORT SPNs TO ADD FILE. When you generate the UNDO file at the same time as the Export SPNs to add file it gives you the ability to undo the changes just made to the Domain Controller. Basically follow the same process as the example above with the Undo file for the SPNs you want to remove. This file only contains removal of SPNs that were “Suggested to Add”.

Always review the results of the Output file to make sure it completed successfully. You can also rerun the Tool (Generate SPNs) and make sure that it no longer suggests to add these SPNs. This is a good way to check that everything was updated successfully as well. If you thought of another account that might have a duplicate SPN with an account in the tool, add it to the OtherAccounts tab and run the tool again. It will check for duplicate SPNs. If you need to check the entire Domain or Forest for Duplicate SPNs, I suggest using dhcheck.vbs or in Active Directory 2008, you can use a SetSPN command with a –F or –X switch.

Step 7. Delegation

In my blogs, we use Constrained Delegation. Since SPNs are unique names tied to a service instance, and SPNs are tied to Service Accounts, constrained delegation basically allows the first service account to access a service on a different machine through the second service’s service account. An easy to follow explanation of this can be see at the What Is Delegation blog post.

“Delegation represents the ability of one service to request access to another service on behalf of a user. As a result, delegation is configured on the service account that requests access and not on the user account.”

“A key to correctly configure delegation is to understand what service accounts are being used by the application that attempts to perform the delegation, and what service is being called. For instance, suppose that you have an IIS Web application that attempts to access a Web service on a remote server using delegation. With delegation, the service account of the Web application is used to retrieve a service ticket to access the Web service. As a result the service account of the IIS Web application must be configured for delegation.”

Hey, why was there a Step 0 – Make a drawing showing the dataflow from user to database?

One reason is that this is a great best practice for documentation. It also helps to ensure you have listed all of the potential Services, Service Accounts, SPNs and Delegations that you will need to setup. I use this concept so that I can use the drawing as a cross reference with the tool to ensure that I have entered all of the Delegations that I need. Each connection line on the diagram represents a possible delegation. The boxes typically show services and machines. Service accounts are tied to services on a machine.

The Delegation tab is broken into two sections. The first section is the “Proposed Application Server / Database Server Delegations” section. The information in this section is created by the data entry from the application tabs.

The second section is the “Other Delegations Needed – Application Server / Application Server” section. It is essentially for http delegations between servers. This section is where you make sure that you have all of your application to application (lines between application machines – not databases) are covered. If you need additional delegations between an application server and a database, I propose that you use an additional copy of the spreadsheet tool and do not do that delegation in the this section. While it is possible to do database delegations here, I do not recommend it. If your setup is more complex, it will take multiple spreadsheets to document all of the needed information. Using multiple spreadsheets is fine as long as you complete an entire spreadsheet (including adding the SPNs in the domain and doing the delegations) and then follow the process for each remaining spreadsheet. Make sure to add all of the accounts from each of the spreadsheets into the “OtherAccounts” tab so that you can always check for duplicate SPNs.

Currently the tool does not do the delegation for you. You still have to manually add the delegations in the Domain Controller. This tool helps you validate if the Delegation doesn’t exist or if the Delegation MAY already exist. You have to manually check the delegations in this tab to ensure all of the SPNs exist that are required for each delegation. More on this in a future blog post.