Draw a Picture

The first step is to always have a picture of the data flow. How does the user get to the data from the browser? The data in this case is the SQL content information that SharePoint and WSS sites use. With MOSS, there is more than one content database. This diagram is representative of your main portal’s site and content database. If you have read any of the prior blog posts, you will note that this is the same process that we always follow. We will follow through with the normal process described as it is beneficial to understand and document the data flow.

Content Data Source

Application Server – Where MOSS is Installed.

Enter the information for the machine where MOSS is installed. It is assumed that the content databases and MOSS are installed on different machines otherwise you wouldn’t need to do this delegation. You only need to specify the port number in cases where the port number is not the default port (normally port 80 for http) and you chose not to use a host header. In other words, you would specify a port if you enter a url into a browser to get to an instance and the url would contain both the machine name and port number.

DNS Information – Host (A) Name Record / IIS – Host Header

For our example, “MossMachine” will be the machine name where we have MOSS installed. We will create a host header A-Record called “Portal” to make an easy url for the users to enter. The A-Record will correspond to the http port 80. You do not need to specify the port number in the tool when you use a host header. Using port 80 is not a best practice; however, I wanted to show an example of using a host header and the default port.

MOSS Server Information – Authentication Method

Since we want to use Integrated Windows authentication, make sure that the Portal web sites have the authentication method checked as shown below. Notice that there is one root web site (Portal). You will want to do this for other sites of interest (such as “My Sites”, WSS Sites, etc.). You will do this by using additional spreadsheets. The tool can only handle one site at a time. From an authentication perspective, if you are going to use Kerberos Constrained Delegation with Integrated Windows authentication, you will want to have these sites set up like the screen shown below.

Authentication Methods

MOSS Server Information – Service Account

You can find the service account information by using IIS Manager on the MossMachine. In this example, the Portal web site’s application pool is shown below. Check to ensure that the application pool listed is set up like the example below.

Service Account

Relational Database 2008 Instance

Fill in the machine information where the relational database (content databases) reside. In our example, this will be the “sqldb” machine. This machine will have multiple SQL instances running on it. In fact, it could be a SQL Cluster. Just use the Cluster Resource Group Name and the appropriate port number (if needed). In our case the instance is the default (MSSQLSERVER) instance; therefore, we do not need to specify a name or port.

The SQL Server 2008 service account can be found in the SQL Server Configuration Manager on the “sqldb” machine. Make sure to select the “Log On As“ service account that corresponds to this.

SQL Server 2008 “Log On As” Service Account – SQL_Service

Named Database Instance Note:

While the tool supports named instances, I have observed issues with named instances and the cluster manager. Also, named instances are still relatively new as far as Kerberos is concerned. You may observe issues with older applications and ODBC or OLE connection strings / drivers. Active Directory 2003 may need a hotfix to enable named instances as well. We did not used a named instance in this example. This is just a FYI in case you have a named instance. It is safer to use the port number that corresponds to the named instance (even though it shouldn’t matter) and avoid these issues.

MOSS Tab Completed – Relational Data Source

The screen shot below shows the MOSS tab filled out for this example.

Note: While there are multiple service types, the default values (shown in column C) are typically used – SQL Server relational data is assumed in this case.

Messages

Upon completing the steps above, you should have a “Green” traffic light and the message shown above. If the light is yellow, you haven’t completed all of the required information. If you have the green light, you should be able to enter more information on other tabs (if needed) or generate SPNs back on the Main tab. Delegation will be covered in a future post. For now, the Delegation tab will show the default delegation that is suggested.

Multiple Application Pools / Web Sites

In this application, you may have multiple application pools (Portal, My Sites, WSS Sites, etc.) to worry about. It is assumed that each of these web sites will use a unique application pool and have unique url’s (http://portal, http://mysite, etc.). The service accounts may or may not be different. Basically, each of these sites have their own port specified, host header, and individual setup. This is accomplished by using multiple spreadsheets. See the next section for more detail.

Multiple Data Sources or Applications / Multiple Spreadsheets

If you have more than one data source or application pool to set up, then you will have to fill out multiple spreadsheets. This example shows a single site (Portal) but alludes to multiple sites (My Site, WSS, etc.). The process to add the additional sites would be to completely fill out one spreadsheet and then complete the SPN creation process all the way through assigning missing SPNs and delegations into the Domain. After that is completed, then come back and do the same process for each successive site (My Site, WSS, etc.) with additional spreadsheets. The point is to make sure to complete the entire SPN process (including adding new SPNs and delegations into the Domain) prior to starting to apply the information from the next spreadsheet. This will allow the additional spreadsheets to check for duplicate SPNs, etc.

Special Note:

The “Delegation” described is not required for MOSS. There can be a variety of reasons that you would want to have this delegation. These include custom web parts, reports, or dashboards that may access the database. For these reasons, the delegation is optional; however, in most cases I would recommend that you set up this optional “extra” delegation (although not required). For these reasons, the tool treats this delegation as required.

Other MOSS Tips and Tricks

There are too many tips and tricks to list in this article. Listed below is the details from Microsoft on Kerberos Configuration for MOSS 2007.

4 Responses to Kerberos SPN Generation Setup Tool – MOSS 2007

Another very valuable tool that helped me in addition to the spreadsheet with a set of ASP pages put out on IIS.NET. The tool/web site is called DELEGCONFIG. The site will ask you similar questions as the spreadsheet but will also do much more. It displays a report at the end that actually verifies what is correct and incorrect and will help in fixing an incorrect setup that will prevent Kerberos from working correctly.. DelegConfig is used for running reports on delegation to verify it is running from client to IIS and IIS to SQL. http://www.iis.net/community/default.aspx?tabid=34&g=6&i=1887
You will need to setup an ASP website and it will then prompt you for what accounts you want to use, and generate the SPN as well for what you want.

I started using DelegConfig before I made this tool. While it gives you some excellent information, it isn’t as user friendly, nor does it generate the missing SPNs needed like the Kerberos SPN Generation Tool does. They can be used together. Both tools have their place to help you solve delegation issues.