Configure Kerberos authentication (MOSS)

Top of Form

• About Kerberos authentication
• Before you begin
• Configure Kerberos authentication for SQL communications
• Configure Internet Explorer to include port numbers in Service Principal Names
• Create Service Principal Names for your Web applications using Kerberos authentication
• Deploy the server farm
• Configure services on servers in your farm
• Create Web applications using Kerberos authentication
• Create a site collection using the Collaboration Portal template in the portal site Web application
• Create a Shared Services Provider for your farm
• Confirm successful access to the Web applications using Kerberos authentication
• Confirm correct Search Indexing functionality
• Confirm correct Search Query functionality
• Configure your SSP infrastructure for Kerberos authentication
• Register new custom-format SPNs for your SSP service account in Active Directory
• Run the Stsadm command-line tool to set the SSP infrastructure to use Kerberos authentication
• Add a new registry key to all of your servers running Office SharePoint Server to enable generation of the new custom-format SPNs
• Confirm Kerberos authentication for root-level shared services access
• Confirm Kerberos authentication for virtual-directory-level shared services access
• Configuration limitations
• Additional resources and troubleshooting guidance

About Kerberos authentication

Kerberos is a secure protocol that supports ticketing authentication. A Kerberos authentication server grants a ticket in response to a client computer authentication request, if the request contains valid user credentials and a valid Service Principal Name (SPN). The client computer then uses the ticket to access network resources. To enable Kerberos authentication, the client and server computers must have a trusted connection to the domain Key Distribution Center (KDC). The KDC distributes shared secret keys to enable encryption. The client and server computers must also be able to access Active Directory directory services. For Active Directory, the forest root domain is the center of Kerberos authentication referrals.

To deploy a server farm running Microsoft Office SharePoint Server 2007 using Kerberos authentication, you must install and configure a variety of applications on your computers. This article describes an example server farm running Office SharePoint Server 2007 and provides guidance for deploying and configuring the farm to use Kerberos authentication to support the following functionality:

• Communication between Office SharePoint Server 2007 and Microsoft SQL Server database software.
• Access to the SharePoint Central Administration Web application.
• Access to other Web applications, including a portal site Web application, a My Site Web application, and an SSP Administration site Web application.
• Access to the shared services for the Office SharePoint Server 2007 Web applications in the Office SharePoint Server 2007 Shared Services Provider (SSP) infrastructure.

Before you begin

This article is intended for administrative-level personnel who have an understanding of the following:

• Windows Server 2003
• Active Directory
• Internet Information Services (IIS) 6.0 (or IIS 7.0)
• Windows SharePoint Services 3.0
• Office SharePoint Server 2007
• Windows Internet Explorer
• Kerberos authentication, as implemented in Active Directory for Windows Server 2003
• Network Load Balancing (NLB) in Windows Server 2003
• Computer accounts in an Active Directory domain
• User accounts in an Active Directory domain
• IIS Web sites and their bindings and authentication settings
• IIS application pool identities for IIS Web sites
• The SharePoint Products and Technologies Configuration Wizard
• Windows SharePoint Services 3.0 and Office SharePoint Server 2007 Web applications
• Central Administration pages
• Service principal names (SPNs) and how to configure them in an Active Directory domain

Important:

To create SPNs in an Active Directory domain, you must have domain administrative-level permissions.

Kerberos authentication for the SSP infrastructure in Office SharePoint Server 2007 requires the installation of the Infrastructure Update for Microsoft Office Servers.

Note:

An SSP is a logical grouping of a common set of services and service data that can be provided to Web applications and their associated Web sites. An SSP infrastructure enables the sharing of services across server farms, Web applications, and site collections. The Office Server Web Services Web site is the SSP infrastructure. The SSP infrastructure exists on any server running Office SharePoint Server 2007 that is deployed using the Complete installation option. Kerberos authentication does not work with the Office Server Web Services Web site unless the Infrastructure Update for Microsoft Office Servers is installed.

This article does not provide an in-depth examination of Kerberos authentication. Kerberos is an industry-standard authentication method that is implemented in Active Directory.

This article does not provide detailed, step-by-step instructions for installing Office SharePoint Server 2007 or using the SharePoint Products and Technologies Configuration Wizard.

This article does not provide detailed, step-by-step instructions for using Central Administration to create Office SharePoint Server 2007 Web applications.

Software version requirements

The guidance provided in this article, and the testing performed to confirm this guidance, are based on results using systems running Windows Server 2003 and Internet Explorer with the latest updates applied from the Windows Update [ http://go.microsoft.com/fwlink/?LinkID=101614&clcid=0x409 ] site (http://go.microsoft.com/fwlink/?LinkID=101614&clcid=0x409). The following software versions were installed:

• Windows Server 2003 Service Pack 2 (SP2) with the latest updates from the Windows Update [ http://go.microsoft.com/fwlink/?LinkID=101614&clcid=0x409 ] site (http://go.microsoft.com/fwlink/?LinkID=101614&clcid=0x409)
• Windows Internet Explorer 7, version 7.0.5730.11
• The released version of Office SharePoint Server 2007

You should also make sure that your Active Directory domain controllers are running Windows Server 2003 SP2 with the latest updates applied from the Windows Update [ http://go.microsoft.com/fwlink/?LinkID=101614&clcid=0x409 ] site (http://go.microsoft.com/fwlink/?LinkID=101614&clcid=0x409).

Known issues

Kerberos authentication cannot be configured to work with the SSP infrastructure in Office SharePoint Server 2007 unless the Infrastructure Update for Microsoft Office Servers is installed. Therefore, if you do not have the Infrastructure Update for Microsoft Office Servers installed, disregard the guidance in this article for configuring Kerberos authentication for the SSP infrastructure.

Office SharePoint Server 2007 can crawl Web applications configured to use Kerberos authentication if those Web applications are hosted on IIS virtual servers that are bound to default ports (TCP port 80 and Secure Sockets Layer (SSL) port 443). However, Office SharePoint Server 2007 Search cannot crawl Office SharePoint Server 2007 Web applications that are configured to use Kerberos authentication if the Web applications are hosted on IIS virtual servers that are bound to non-default ports (ports other than TCP port 80 and SSL port 443). Currently, Office SharePoint Server 2007 Search can only crawl Office SharePoint Server 2007 Web applications hosted on IIS virtual servers bound to non-default ports that are configured to use either NTLM authentication or Basic authentication.

For end-user access using Kerberos authentication, if you need to deploy Web applications that can only be hosted on IIS virtual servers that are bound to non-default ports, and if you want end-users to get search query results, then:

• The same Web applications must be hosted on other IIS virtual servers on non-default ports.
• The Web applications must be configured to use either NTLM or Basic authentication.
• Search Indexing must crawl the Web applications using NTLM or Basic authentication.

This article provides guidance for:

• Configuring the Central Administration Web application using Kerberos authentication hosted on an IIS virtual server bound to non-default ports.
• Configuring portal and My Site applications, and shared services using Kerberos authentication hosted on IIS virtual servers bound to default ports and with an IIS host header binding.
• Ensuring that Search Indexing successfully crawls Office SharePoint Server 2007 Web applications using Kerberos authentication.
• Ensuring that users accessing Kerberos-authenticated Web applications can successfully get search query results for those Web applications.
• Configuring Kerberos authentication for the SSP infrastructure (if the Infrastructure Update for Microsoft Office Servers is installed).

Additional background

It is important to understand that when you use Kerberos authentication, accurate authentication functionality is dependant in part on the behavior of the client that is attempting to authenticate using Kerberos. In an Office SharePoint Server 2007 farm deployment using Kerberos authentication, Office SharePoint Server 2007 is not the client. Before you deploy a server farm running Office SharePoint Server 2007 using Kerberos authentication, you must understand the behavior of the following clients:

• The browser (in the context of this article, the browser is always Windows Internet Explorer).
• The Microsoft .NET Framework.

The browser is the client used when browsing to a Web page in an Office SharePoint Server 2007 Web application. When Office SharePoint Server 2007 performs tasks such as crawling the local Office SharePoint Server 2007 content sources or making calls to the SSP infrastructure, the .NET Framework is functioning as the client.

For Kerberos authentication to work correctly, you must create SPNs in Active Directory. If the services to which these SPNs correspond are listening on non-default ports, the SPNs should include port numbers. This is to ensure that the SPNs are meaningful. It is also required to prevent the creation of duplicate SPNs.

When a client (Internet Explorer or the .NET Framework) attempts to access a resource using Kerberos authentication, the client must construct an SPN to be used as part of the Kerberos authentication process. If the client does not construct an SPN that matches the SPN that is configured in Active Directory, Kerberos authentication will fail, usually with an “access denied” error.

There are versions of Internet Explorer that do not construct SPNs with port numbers. If you are using Office SharePoint Server 2007 Web applications that are bound to non-default port numbers in IIS, you might have to direct Internet Explorer to include port numbers in the SPNs that it constructs. In a farm running Office SharePoint Server 2007, the Central Administration Web application is hosted, by default, in an IIS virtual server that is bound to a non-default port. Therefore, this article addresses both IIS port-bound and IIS host-header-bound Web sites, and it provides a link to instructions for directing Internet Explorer to include port numbers in SPNs.

In a farm running Office SharePoint Server 2007, by default the .NET Framework does not construct SPNs that contain port numbers. This is the reason why Search cannot crawl Web applications using Kerberos authentication if those Web applications are hosted on IIS virtual servers that are bound to non-default ports. It is also the reason why Kerberos authentication cannot be correctly configured and made to work for the SSP infrastructure unless the Infrastructure Update for Microsoft Office Servers is installed.

Server farm topology

This article targets the following Office SharePoint Server 2007 server farm topology:

• Two computers running Windows Server 2003 that are acting as front-end Web servers, with Windows NLB configured.
• Three computers running Windows Server 2003 that are acting as application servers. One of the application servers hosts the Central Administration Web application. The second application server is running Search Query, and the third application server is running Search Indexing.
• One computer running Windows Server 2003 that is used as the SQL host for the farm running Office SharePoint Server 2007. For the scenario described in this article, you can use either Microsoft SQL Server 2000 SP4 or Microsoft SQL Server 2005 SP2.

This article provides guidance for configuring one SSP in the farm.

Active Directory, computer naming, and NLB conventions

The scenario described in this article uses the following Active Directory, computer-naming, and NLB conventions:

Server role	Domain name
Active Directory	mydomain.net
A front-end Web server running Office SharePoint Server 2007	mossfe1.mydomain.net
A front-end Web server running Office SharePoint Server 2007	mossfe2.mydomain.net
Office SharePoint Server 2007 Central Administration	mossadmin.mydomain.net
Search Indexing running Office SharePoint Server 2007	mosscrawl.mydomain.net
Search Query running Office SharePoint Server 2007	mossquery.mydomain.net
SQL Server host running Office SharePoint Server 2007	mosssql.mydomain.net

An NLB VIP is assigned to mossfe1.mydomain.net and mossfe2.mydomain.net as a result of configuring NLB on these systems. A set of DNS host names that point to this address is registered in your DNS system. For example, if your NLB VIP is 192.168.100.200, you have a set of DNS records that resolve the following DNS names to this IP address (192.168.100.200):

• kerbportal.mydomain.net
• kerbmysite.mydomain.net
• kerbsspadmin.mydomain.net

Active Directory domain account conventions

The example in this article uses the naming conventions listed in the following table for service accounts and application pool identities used in the farm running Office SharePoint Server 2007.

Domain account or application pool identity	Name
Local administrator account On all servers running Office SharePoint Server 2007 (but not on the host computer running SQL Server) For Office SharePoint Server 2007 setup and for the SharePoint Products and Technologies Configuration Wizard run-as user	mydomain\pscexec
Local administrator account on the SQL Server host computer	mydomain\sqladmin
SQL Server service account used to run the SQL Server service on the SQL host	mydomain\mosssqlsvc
Office SharePoint Server 2007 farm administrator account	mydomain\mossfarmadmin This is used as the application pool identity for Central Administration and as the service account for the SharePoint Timer Service.
Office SharePoint Server 2007 application pool identity for the portal site Web application	mydomain\portalpool
Office SharePoint Server 2007 application pool identity for the My Site Web application	mydomain\mysitepool
Office SharePoint Server 2007 application pool identity for the Shared Services Administration Web site	mydomain\sspadminpool
Office SharePoint Server 2007 SSP service account	mydomain\sspsvc
Windows SharePoint Services 3.0 search service account	mydomain\wsssearch
Windows SharePoint Services 3.0 search content access account	mydomain\wsscrawl
Office SharePoint Server 2007 search service account	mydomain\mosssearch
Office SharePoint Server 2007 content access account	mydomain\mosscrawl

Preliminary configuration requirements

Before you install Office SharePoint Server 2007 on the computers in your server farm, make sure you have performed the following procedures:

• All servers used in the farm, including the SQL host, are set up with Windows Server 2003 SP2, including the latest updates applied from the Windows Update [ http://go.microsoft.com/fwlink/?LinkID=101614&clcid=0x409 ] site (http://go.microsoft.com/fwlink/?LinkID=101614&clcid=0x409).
• All servers in the farm have Internet Explorer 7 (and the latest updates for it) installed from the Windows Update [ http://go.microsoft.com/fwlink/?LinkID=101614&clcid=0x409 ] site (http://go.microsoft.com/fwlink/?LinkID=101614&clcid=0x409).
• SQL Server (either SQL Server 2000 SP4 or SQL Server 2005 SP2) is installed and running on the SQL host computer, and the SQL Server service is running as the account, mydomain\sqlsvc. A default instance of SQL Server is installed and is listening on TCP port 1433.
• The SharePoint Products and Technologies Configuration Wizard run-as user has been added:
• As a SQL Login on your SQL host.
• To the SQL Server DBCreators role on your SQL host.
• To the SQL Server Security Administrators role on your SQL host.

Configure Kerberos authentication for SQL communications

Configure Kerberos authentication for SQL communications before installing and configuring Office SharePoint Server 2007 on your servers running Office SharePoint Server 2007. This is necessary because Kerberos authentication for SQL communications has to be configured, and confirmed to be working, before your computers running Office SharePoint Server 2007 can connect to your SQL Server.

The process of configuring Kerberos authentication for any service installed on a host computer running Windows Server 2003 includes creating an SPN for the domain account used to run the service on the host. SPNs are made up of the following parts:

• A Service Name (for example, MSSQLSvc or HTTP)
• A host name (either real or virtual)
• A port number

The following list contains examples of SPNs for a default instance of SQL Server running on a computer named mosssql and listening on port 1433:

• MSSQLSvc/mosssql:1433
• MSSQLSvc/mosssql.mydomain.com:1433

These are the SPNs that you will create for the instance of SQL Server on the SQL host that will be used by the farm described in this article. You should always create SPNs that have both a NetBIOS name and a full DNS name for a host on your network.

There are different methods that you can use to set an SPN for an account in an Active Directory domain. One method is to use the SETSPN.EXE utility that is part of the resource kit tools for Windows Server 2003. Another method is to use the ADSIEDIT.MSC snap-in on your Active Directory domain controller. This article addresses using the ADSIEDIT.MSC snap-in.

There are two core steps for configuring Kerberos authentication for SQL Server:

• Create SPNs for your SQL Server service account.
• Confirm Kerberos authentication is used to connect servers running Office SharePoint Server 2007 to servers running SQL Server.

Create the SPNs for your SQL Server service account

1. Log on to your Active Directory domain controller using the credentials of a user that has domain administrative permissions.
2. In the Run dialog box, type ADSIEDIT.MSC.
3. In the management console dialog box, expand the domain container folder.
4. Expand the container folder containing user accounts, for example CN=Users.
5. Locate the container for the SQL Server Service account, for example CN=mosssqlsvc.
6. Right-click this account, and then click Properties.
7. Scroll down the list of properties in the SQL Server Service account dialog box until you find servicePrincipalName.
8. Select the servicePrincipalName property and click Edit.
9. In the Value to Add field, in the Multi-Valued String Editor dialog box, type the SPN MSSQLSvc/mosssql:1433 and click Add. Next, type the SPN MSSQLSvc/mosssql.mydomain.com:1433 in this field and click Add.
10. Click OK on the Multi-Valued String Editor dialog box, and then click OK on the properties dialog box for the SQL Server service account.

Confirm Kerberos authentication is used to connect servers running Office SharePoint Server 2007 to SQL Server

Install the SQL Client Tools on one of your servers running Office SharePoint Server 2007, and use the tools to connect from your server running Office SharePoint Server 2007 to those running SQL Server. This article does not address the steps for installing the SQL Client Tools on one of your servers running Office SharePoint Server 2007. The confirmation procedures are based on the following assumptions:

• You are using SQL Server 2005 SP2 on your SQL host.
• You have logged on to one of your servers running Office SharePoint Server 2007, using the account mydomain\pscexec, and have installed the SQL 2005 Client Tools on the server running Office SharePoint Server 2007.

1. Run the SQL Server 2005 Management Studio.
2. When the Connect to Server dialog box appears, type the name of the SQL host computer (in this example, the SQL host computer is mosssql), and click Connect to connect to the SQL host computer.
3. To confirm that Kerberos authentication was used for this connection, run the event viewer on the SQL host computer and examine the Security event log. You should see a Success Audit record for a Logon/Logoff category event that is similar to the data shown in the following tables:

Event Type	Success Audit
Event Source	Security
Event Category	Logon/Logoff
Event ID	540
Date	10/31/2007
Time	4:12:24 PM
User	MYDOMAIN\pscexec
Computer	MOSSSQL
Description

4. An example of a successful network logon is depicted in the following table.

User Name	pscexec
Domain	MYDOMAIN
Logon ID	(0x0,0x6F1AC9)
Logon Type	3
Logon Process	Kerberos
Workstation Name
Logon GUID	{36d6fbe0-2cb8-916c-4fee-4b02b0d3f0fb}
Caller User Name
Caller Domain
Caller Logon ID
Caller Process ID
Transited Services
Source Network Address	192.168.100.100
Source Port	2465

Examine the log entry to confirm that:

1. The user name is correct. The mydomain\pscexec account logged on over the network to the SQL host.
2. The logon type is 3. A type 3 logon is a network logon.
3. The logon process and authentication package both use Kerberos authentication. This confirms that your server running Office SharePoint Server 2007 is using Kerberos authentication to communicate with the SQL host.
4. The Source Network Address matches the IP address of the computer from which the connection was made.

If your connection to the SQL host fails with an error message similar to Cannot generate SSPI context, it is likely that there is an issue with the SPN being used for your instance of SQL Server. To troubleshoot and correct this, please refer to the article How to troubleshoot the "Cannot generate SSPI context" error message [ http://go.microsoft.com/fwlink/?LinkId=76621 ] (http://go.microsoft.com/fwlink/?LinkId=76621) from the Microsoft Knowledge Base.

Configure Internet Explorer to include port numbers in Service Principal Names

Many versions of Internet Explorer do not include port numbers in the SPNs that they construct. To determine if you are using a version of Internet Explorer 6 that has this problem, and for steps necessary to correct it, refer to the article Internet Explorer 6 cannot use the Kerberos authentication protocol to connect to a Web site that uses a non-standard port in Windows XP and in Windows Server 2003 [ http://go.microsoft.com/fwlink/?LinkId=99681 ] (http://go.microsoft.com/fwlink/?LinkId=99681) from the Microsoft Knowledge Base. You should very carefully examine the version number of the DLL referenced in this article to determine if the version of Internet Explorer that you are using requires the fix described in the article. If your version of Internet Explorer does not construct an SPN with port numbers, and you are using Office SharePoint Server 2007 Web applications hosted on IIS virtual servers bound to non-default ports, you must apply this fix to be able to go to the Web applications that are using your version of Internet Explorer. Within the context of this article, you must ensure that the version of Internet Explorer you are using includes port numbers in the SPNs that it constructs, because the SPN that you add to your Active Directory for the Central Administration Web application will contain a port number.

Create Service Principal Names for your Web applications using Kerberos authentication

As far as Kerberos authentication is concerned, there is nothing special about IIS-based Office SharePoint Server 2007 Web applications—Kerberos authentication treats them as just another IIS Web site.

This process requires knowledge of the following items:

• The Service Class for the SPN (in the context of this article, for Office SharePoint Server 2007 Web applications, this is always HTTP).
• The URL for all of your Office SharePoint Server 2007 Web applications using Kerberos authentication.
• The host name portion of the SPN (either real or virtual; this article addresses both).
• The port number portion of the SPN (in the scenario described in this article, both IIS port-based and IIS host-header-based Office SharePoint Server 2007 Web applications are used).
• The Windows Active Directory accounts for which your SPNs must be created.

The following table lists the information for the scenario described in this article:

URL	Active Directory account	SPN
http://mossadmin.mydomain.net:10000	mossfarmadmin	HTTP/mossadmin.mydomain.net:10000 HTTP/mossadmin.mydomain.net:10000
http://kerbportal.mydomain.net	portalpool	HTTP/kerbportal.mydomain.net HTTP/kerbportal
http://kerbmysite.mydomain.net	mysitepool	HTTP/kerbmysite.mydomain.net HTTP/kerbmysite
http://kerbsspadmin.mydomain.net/ssp/admin	sspadminpool	HTTP/kerbsspadmin.mydomain.net HTTP/kerbsspadmin

Notes for this table:

• The first URL listed above is for Central Administration, and uses a port number. You don’t have to use port 10000. This is just an example used for consistency throughout this article.
• The next three URLs are for the portal site, My Site, and Shared Services Administration site, respectively.

Use the guidance provided above to create the SPNs you need in Active Directory to support Kerberos authentication for your Office SharePoint Server 2007 Web applications. You need to log on to a domain controller in your environment using an account that has domain administrative permissions. To create the SPNs, you can use either the SETSPN.EXE utility mentioned previously, or you can use the ADSIEDIT.MSC snap-in mentioned previously. If using the ADSIEDIT.MSC snap-in, please refer to the instructions provided earlier in this article for creating the SPNs. Be sure to create the correct SPNs for the correct accounts in Active Directory.

Deploy the server farm

Deploying the server farm includes the following steps:

1. Set up Office SharePoint Server 2007 on all of your servers running Office SharePoint Server 2007.
2. Run the SharePoint Products and Technologies Configuration Wizard and create a new farm. This step includes creating an Office SharePoint Server 2007 Central Administration Web application that will be hosted on an IIS virtual server bound to a non-default port and use Kerberos authentication.
3. Run the SharePoint Products and Technologies Configuration Wizard and join the other servers to the farm.
4. Configure Services on Servers in your farm for:
• Windows SharePoint Services 3.0 Search service
• Office SharePoint Server 2007 Search Indexing
• Office SharePoint Server 2007 Search Query
5. Create Web applications that are used for the portal site, My Site, and the Shared Services Administration site using Kerberos authentication.
6. Create a site collection using the Collaboration Portal template in the portal site Web application.
7. Create a Shared Services Provider for your farm.
8. Confirm successful access to the Web applications using Kerberos authentication.
9. Confirm correct Search Indexing functionality.
10. Confirm correct Search Query functionality.
11. Configure your SSP infrastructure for Kerberos authentication. This is an optional step that requires the installation of the Infrastructure Update for Microsoft Office Servers.
12. Confirm SSP functionality using Kerberos authentication. This is an optional step that requires the installation of the Infrastructure Update for Microsoft Office Servers.

Install Office SharePoint Server 2007 on all of your servers

This is the straightforward process of running Office SharePoint Server 2007 setup to install the Office SharePoint Server 2007 binaries on your servers running Office SharePoint Server 2007. Log on to each of your computers running Office SharePoint Server 2007 using the account mydomain\pscexec. No step-by-step instructions are provided for this. For the scenario described in this article, do a Complete installation of Office SharePoint Server 2007 on all servers that require Office SharePoint Server 2007.

Run the SharePoint Products and Technologies Configuration Wizard and create a new farm

For the scenario described in this article, run the SharePoint Products and Technologies Configuration Wizard from the MOSSADMIN Search Indexing server first, so that MOSSADMIN hosts the Office SharePoint Server 2007 Central Administration Web application.

On the server named MOSSCRAWL, when setup completes, a Setup Complete dialog box appears with a check box selected to run the SharePoint Products and Technologies Configuration Wizard. Leave this check box selected and close the setup dialog box to run the SharePoint Products and Technologies Configuration Wizard.

When running the SharePoint Products and Technologies Configuration Wizard on this computer, direct the Wizard to create a new farm using the following settings:

• Provide the database server name (in this article, it is the server named MOSSSQL).
• Provide a configuration database name (you can use the default, or stipulate a name of your choice).
• Provide the database access (farm administrator) account information. Using the scenario in this article, that account is mydomain\mossfarmadmin.
• Provide the information required for the Office SharePoint Server 2007 Central Administration Web application. Using the scenario in this article, that information is:
• Central Administration Web application port number: 10000
• Authentication Method: Negotiate

When you have provided all the required information, the SharePoint Products and Technologies Configuration Wizard should finish successfully. If it completes successfully, confirm that you can access the Office SharePoint Server 2007 Central Administration Web application home page using Kerberos authentication. To do this, perform the following steps:

1. Log on to a different server running Office SharePoint Server 2007 or another computer in the domain mydomain as mydomain\pscexec. You should not verify correct Kerberos authentication behavior directly on the computer hosting the Office SharePoint Server 2007 Central Administration Web application. This should be done from a separate computer in the domain.
2. Start Internet Explorer on this server and attempt to go to the following URL: http://mossadmin.mydomain.net:10000. The home page of Central Administration should render.
3. To confirm that Kerberos authentication was used to access Central Administration, go back to the computer named MOSSADMIN and run the event viewer and look in the security log. You should see a Success Audit record that looks similar to the following table:

Event Type	Success Audit
Event Source	Security
Event Category	Logon/Logoff
Event ID	540
Date	11/1/2007
Time	2:22:20 PM
User	MYDOMAIN\pscexec
Computer	MOSSADMIN
Description

4. An example of a successful network logon is depicted in the following table.

User Name	pscexec
Domain	MYDOMAIN
Logon ID	(0x0,0x1D339D3)
Logon Type	3
Logon Process	Kerberos
Authentication Package	Kerberos
Workstation Name
Logon GUID	{fad7cb69-21f8-171b-851b-3e0dbf1bdc79}
Caller User Name
Caller Domain
Caller Logon ID
Caller Process ID
Transited Services
Source Network Address	192.168.100.100
Source Port	2505

Examination of this log record shows the same type of information as in the previous log entry:

• Confirm that the user name is correct; it is the mydomain\pscexec account that logged on over the network to the server running Office SharePoint Server 2007 that is hosting Central Administration.
• Confirm that the logon type is 3; a logon type 3 is a network logon.
• Confirm that the logon process and authentication package both use Kerberos authentication. This confirms that Kerberos authentication is being used to access your Central Administration Web application.
• Confirm that the Source Network Address matches the IP address of the computer from which the connection was made.

If the Central Administration home page fails to render and instead an unauthorized error message is displayed, Kerberos authentication is failing. There are usually only two causes for this failure:

• The SPN in Active Directory was not registered for the correct account. It should have been registered for mydomain\mossfarmadmin.
• The SPN in Active Directory does not match the SPN being constructed by Internet Explorer or is otherwise invalid. The most common cause of this is that Internet Explorer is not constructing an SPN containing the correct port number. See the previous section titled Configure Internet Explorer to include port numbers in Service Principal Names to correct this problem. You also might have omitted the port number from the SPN that you registered in Active Directory. Either way, ensure that this is corrected and that Central Administration is working, using Kerberos authentication, before proceeding.

Note:

A diagnostic aid you could use to see what is going on over the network is a network sniffer, such as Microsoft Network Monitor, to take a trace during browsing to Central Administration. After the failure, examine the trace and look for KerberosV5 Protocol packets. Find a packet with an SPN constructed by Internet Explorer. If that SPN does not contain a port number, you need to apply the fix described in the section titled Configure Internet Explorer to include port numbers in Service Principal Names. If the SPN in the trace looks correct, either the SPN in Active Directory is invalid, or it has been registered for the wrong account.

Run the SharePoint Products and Technologies Configuration Wizard and join the other servers to the farm

Now that your farm has been created and you can successfully access Central Administration using Kerberos authentication, you need to run the SharePoint Products and Technologies Configuration Wizard and join the other servers to the farm.

On each of the other four servers running Office SharePoint Server 2007 (mossfe1, mossfe2, mossquery, and mosscrawl), Office SharePoint Server 2007 installation should have completed, and the setup completion dialog box should appear with the SharePoint Products and Technologies Configuration Wizard check box selected. Leave this check box selected and close the setup completion dialog box to run the SharePoint Products and Technologies Configuration Wizard. Perform the procedure to join each of these servers to the farm.

Upon completion of the SharePoint Products and Technologies Configuration Wizard on each server you add to the farm, verify that each of these servers can render Central Administration, which is running on the server, MOSSADMIN. If any of these servers fail to render Central Administration, take the appropriate steps to solve the problem before you proceed.

Configure services on servers in your farm

Configure specific Windows SharePoint Services 3.0 and Office SharePoint Server 2007 services to run on specific servers running Windows SharePoint Services 3.0 and Office SharePoint Server 2007 in the farm, using the accounts indicated in the following sections.

Note:

This section does not provide an in-depth description of the user interface. Only high-level instructions are provided. You should be familiar with Central Administration and how to perform the required steps before you proceed.

Access Central Administration and perform the following steps to configure the services on the servers indicated, using the accounts indicated.

Windows SharePoint Services Search

On the Services on Server page in Central Administration:

1. Select the server MOSSQUERY.
2. In the list of services that appears, close to the middle of the page, locate the Windows SharePoint Services 3.0 Search service, and then click Start in the Action column.
3. On the subsequent page, provide the credentials for the Windows SharePoint Services 3.0 search service account and for the Windows SharePoint Services 3.0 Content Access account. In the scenario in this article, the Windows SharePoint Services 3.0 search service account is mydomain\wsssearch, and the Windows SharePoint Services 3.0 content access account is mydomain\wsscrawl. Type the account names and passwords in the appropriate locations on the page, and then click Start.

Index server

On the Services on Server page in Central Administration:

1. Select the server MOSSCRAWL.
2. In the list of services that appears close to the middle of the page, locate the Office SharePoint Server 2007 Search service, and then click Start in the Action column.

On the subsequent page, check the Use this server for indexing content check box and then provide the credentials for the Office SharePoint Server 2007 search service account. In the scenario in this article, the Office SharePoint Server 2007 search service account is mydomain\mosssearch. Type the account names and passwords in the appropriate locations on the page, and then click Start.

Query server

On the Services on Server page in Central Administration:

1. Select the server MOSSQUERY.
2. In the list of services that appears close to the middle of the page, locate the Office SharePoint Server 2007 Search service, and then click the service name in the Service column.

On the subsequent page, check the Use this server for serving search queries check box and click OK.

Create Web applications using Kerberos authentication

In this section, create Web applications that are used for the portal site, a My Site, and the Shared Services Administration site in your farm.

Note:

This section does not provide an in-depth description of the user interface. Only high-level instructions are provided. You should be familiar with Central Administration and how to perform the required steps before you proceed.

Create the portal site Web application

1. On the Application Management page in Central Administration, click Create or extend Web application.
2. On the subsequent page, click Create a new Web application.
3. On the subsequent page, make sure Create a new IIS Web site is selected.
• In the Description field, type PortalSite.
• In the Port field, type 80.
• In the Host Header field, type kerbportal.mydomain.net.
4. Make sure Negotiate is selected as the authentication provider for this Web application.
5. Create this Web application in the Default zone. Do not modify the zone for this Web application.
6. Make sure Create new application pool is selected.
• In the Application Pool Name field, type PortalAppPool.
• Make sure Configurable is selected. In the User name field, type the account mydomain\portalpool.
7. Click OK.
8. Confirm that the Web application is successfully created.

Note:

If you want to use an SSL connection and bind the Web application to port 443, type 443 in the Port field and select Use SSL on the Create New Web Application page. In addition, you must install an SSL wildcard certificate. When using an IIS host header binding on an IIS Web site configured for SSL, you must use an SSL wildcard certificate. For more information about SSL host headers in IIS, see Configuring SSL Host Headers (IIS 6.0) [ http://go.microsoft.com/fwlink/?LinkId=111285&clcid=0x409 ] (http://go.microsoft.com/fwlink/?LinkId=111285&clcid=0x409).

Create the My Site Web application

1. On the Application Management page in Central Administration, click Create or extend Web application.
2. On the subsequent page, click Create a new Web application.
3. On the subsequent page, make sure Create a new IIS Web site is selected.
• In the Description field, type MySite.
• In the Port field, type 80.
• In the Host Header field, type kerbmysite.mydomain.net.
4. Make sure Negotiate is selected as the authentication provider for this Web application.
5. Create this Web application in the Default zone. Do not modify the zone for this Web application.
6. Make sure Create new application pool is selected.
• In the Application Pool Name field, type MySiteAppPool.
• Make sure Configurable is selected. In the User name field, type the account mydomain\mysitepool.
7. Click OK.
8. Confirm that the Web application is successfully created.

Note:

If you want to use an SSL connection and bind the Web application to port 443, type 443 in the Port field and select Use SSL on the Create New Web Application page. In addition, you must install an SSL wildcard certificate. When using an IIS host header binding on an IIS Web site configured for SSL, you must use an SSL wildcard certificate. For more information about SSL host headers in IIS, see Configuring SSL Host Headers (IIS 6.0) [ http://go.microsoft.com/fwlink/?LinkId=111285&clcid=0x409 ] (http://go.microsoft.com/fwlink/?LinkId=111285&clcid=0x409).

Create the Shared Services Administration site Web application

1. On the Application Management page in Central Administration, click Create or extend Web application.
2. On the subsequent page, click Create a new Web application.
3. On the subsequent page, make sure Create a new IIS Web site is selected.
• In the Description field, type SSPAdminSite.
• In the Port field, type 80.
• In the Host Header field, type kerbsspadminsite.mydomain.net.
4. Make sure Negotiate is selected as the authentication provider for this Web application.
5. Create this Web application in the Default zone. Do not modify the zone for this Web application.
6. Make sure Create new application pool is selected.
• In the Application pool name field, type SSPAdminSiteAppPool.
• Make sure Configurable is selected. In the User name field, type the account mydomain\sspadminpool.
7. Click OK.
8. Confirm that the Web application is successfully created.

Note:

If you want to use an SSL connection and bind the Web application to port 443, type 443 in the Port field and select Use SSL on the Create New Web Application page. In addition, you must install an SSL wildcard certificate. When using an IIS host header binding on an IIS Web site configured for SSL, you must use an SSL wildcard certificate. For more information about SSL host headers in IIS, see Configuring SSL Host Headers (IIS 6.0) [ http://go.microsoft.com/fwlink/?LinkId=111285&clcid=0x409 ] (http://go.microsoft.com/fwlink/?LinkId=111285&clcid=0x409).

Create a site collection using the Collaboration Portal template in the portal site Web application

In this section, you create a site collection on the portal site in the Web application that you created for this purpose.

Note:

This section does not provide an in-depth description of the user interface. Only high-level instructions are provided. You should be familiar with Central Administration and how to perform the required steps before you proceed.

1. On the Application Management page in Central Administration, click Create site collection.
2. On the subsequent page, make sure you select the correct Web application. For the example in this article, select http://kerbportal.mydomain.net.
3. Provide the title and description you want to use for this site collection.
4. Leave the Web site address unchanged.
5. In the Template Selection section under Select a Template, click the Publishing tab and select the Collaboration Portal template.
6. In the Primary Site Collection Administrator section, type mydomain\pscexec.
7. Specify the Secondary Site Collection Administrator you want to use.
8. Click OK.
9. Confirm that the portal site collection is successfully created.

Create a Shared Services Provider for your farm

Create a Shared Services Provider for the farm.

Note:

This section does not provide an in-depth description of the user interface. Only high-level instructions are provided. You should be familiar with Central Administration and how to perform the required steps before you proceed.

1. On the Application Management page in Central Administration, click Create or configure this farm’s shared services.
2. On the subsequent page, click New SSP.
3. On the subsequent page, in the SSP Name section, type SSP1 in the SSP Name field. Then, in the Web application field, select the Web application you created for the Shared Services Administration site Web application. For the example in this article, select the Web application named SSPAdminSite.
• In the MySite section, in the Web application field, select the Web application you created for the My Site Web site. For the example in this article, select the Web application named MySite.
• In the SSP service credentials section, in the User name field, type mydomain\sspsvc.
4. Click OK.
5. Confirm that your farm’s SSP is successfully created.

Confirm successful access to the Web applications using Kerberos authentication

Confirm that Kerberos authentication is working for the recently created Web applications. Start with the portal site.

To do this, perform the following steps:

1. Log on to a server running Office SharePoint Server 2007 rather than either of the two front-end Web servers that are configured for NLB as mydomain\pscexec. You should not verify correct Kerberos authentication behavior directly on one of the computers hosting the load-balanced Web sites using Kerberos authentication. This should be done from a separate computer in the domain.
2. Start Internet Explorer on this other system and attempt to go to the following URL: http://kerbportal.mydomain.net.

The home page of the Kerberos-authenticated portal site should render.

To confirm that Kerberos authentication was used to access the portal site, go to one of the load-balanced front-end Web servers and run the event viewer and look in the security log. You should see a Success Audit record, similar to the following table, on one of the front-end Web servers. Note that you may have to look on both front-end Web servers before you find this, depending on which system handled the load-balanced request.

Event Type	Success Audit
Event Source	Security
Event Category	Logon/Logoff
Event ID	540
Date	11/1/2007
Time	5:08:20 PM
User	MYDOMAIN\pscexec
Computer	mossfe1
Description

An example of a successful network logon is depicted in the following table.

User Name	pscexec
Domain	MYDOMAIN
Logon ID	(0x0,0x1D339D3)
Logon Type	3
Logon Process	Kerberos authentication
Workstation Name
Logon GUID	{fad7cb69-21f8-171b-851b-3e0dbf1bdc79}
Caller User Name
Caller Domain
Caller Logon ID
Caller Process ID
Transited Services
Source Network Address	192.168.100.100
Source Port	2505

Examination of this log record shows the same type of information as in the previous log entry:

• Confirm that the user name is correct; it is the mydomain\pscexec account that logged on over the network to the front-end Web server running Office SharePoint Server 2007 that is hosting the portal site.
• Confirm that the logon type is 3; a logon type 3 is a network logon.
• Confirm that the logon process and authentication package both use Kerberos authentication. This confirms that Kerberos authentication is being used to access your portal site.
• Confirm that the Source Network Address matches the IP address of the computer from which the connection was made.

If the home page of the portal site fails to render, and displays an “unauthorized” error message, then Kerberos authentication is failing. There are usually only a couple of causes for this:

• The SPN in Active Directory was not registered for the correct account. It should have been registered for mydomain\portalpool, for the Web application of the portal site.
• The SPN in Active Directory does not match the SPN being constructed by Internet Explorer or is invalid for another reason. In this case, because you are using IIS host headers without explicit port numbers, the SPN registered in Active Directory differs from the IIS host header specified when you extended the Web application. You need to correct this to get Kerberos authentication working.

Note:

A diagnostic aid you could use to see what is going on over the network is a network sniffer such as Microsoft Network Monitor to take a trace during browsing to Central Administration. After the failure, examine the trace and look for KerberosV5 Protocol packets. You should find a packet with an SPN constructed by Internet Explorer. If that SPN does not contain a port number, then you need to apply the fix described in the section Configure Internet Explorer to include port numbers in Service Principal Names. If the SPN in the trace looks correct, then either the SPN in Active Directory is invalid or the SPN has been registered for the wrong account.

After you have Kerberos authentication working for your portal site, go to your Kerberos-authenticated My Site and the Shared Services Administration site using the following URLs:

• http://kerbmysite.mydomain.net
• http://kerbsspadmin.mydomain.net/ssp/admin

Note:

The first time you access the My Site URL, it will take some time for Office SharePoint Server 2007 to create a My Site for the logged-on user. However, it should succeed, and the My Site page for that user should render.

These should both work correctly. If they don’t, refer to the preceding troubleshooting steps.

Confirm correct Search Indexing functionality

Confirm that Search Indexing is successfully crawling the content hosted on this farm. This is the step you must take prior to confirming the Search Query results for users accessing the sites using Kerberos authentication.

Note:

This section does not provide an in-depth description of the user interface. Only high-level instructions are provided. You should be familiar with Central Administration and how to perform the required steps before you proceed.

1. Access the Shared Services Administration site Web application at http://kerbsspadmin.mydomain.net/ssp/admin.
2. On this page, click Search Settings.
3. On the subsequent page, click Content Sources and Crawl Schedules.
4. On the subsequent page, access the ECB for the Office SharePoint Server Content Sources, and from the drop-down list, select Start Full Crawl.
5. Wait for the crawl to complete. If the crawl fails, you must investigate and correct the failure, and then run a full crawl. If the crawl fails with "access denied" errors, it is either because the crawling account does not have access to the content sources, or because Kerberos authentication has failed. Whatever the cause, this error must be corrected before proceeding to subsequent steps.

You must complete a full crawl of the Kerberos-authenticated Web applications before proceeding.

Confirm correct Search Query functionality

To confirm that Search Query returns results for users accessing the portal site that uses Kerberos authentication:

1. Start Internet Explorer on a system in mydomain.net and go to http://kerbportal.mydomain.net.
2. When the home page of the portal site renders, type a search keyword in the Search field and press ENTER.
3. Confirm that Search Query results are returned. If they are not, confirm that the keyword you have entered is valid in your deployment, that Search Indexing is running correctly, that the Search service is running on your Search Indexing and Search Query servers, and that there are no problems with search propagation from your Search Index server to your Search Query server.

Configure your SSP infrastructure for Kerberos authentication

Note:

This is an optional procedure that requires installation of the Infrastructure Update for Microsoft Office Servers. Without the installation of the Infrastructure Update for Microsoft Office Servers, Kerberos authentication cannot be correctly configured for Office SharePoint Server 2007.

The Infrastructure Update for Microsoft Office Servers includes a new, custom-format SPN for Kerberos authentication for the SSP infrastructure. This custom-format SPN introduces a new Service Class: MSSP. The custom-format SPN is in the following format: MSSP/<host:port>/<SSP name>.

This new custom-format SPN sets a .NET Framework property to direct the .NET Framework to use a specific SPN for a given URI. It is the .NET Framework that is used to make inter-server calls to the Office SharePoint Server 2007 SSP infrastructure Web services.

If you examine the SSP infrastructure on an Office SharePoint Server 2007 application server, you will see that there is a Search shared service at both the root level and the virtual directory level in IIS. There is also an Excel Calculation Services (ECS) shared service at the virtual directory level in IIS. After the SSP infrastructure is configured for Kerberos authentication, Kerberos will be used for accessing shared services at both the root level and the virtual directory level.

You do not need to register SPNs for the root-level Web services. You only need to register SPNs for the virtual-directory-level Web services. This is because when joining a computer to a domain, a HOST-class SPN is automatically registered for the computer account in the domain, and the SPN will work for the root-level Web service. However, you do need to register SPNs corresponding to the virtual directories that actually correlate to the SSPs in your farm.

To successfully configure your SSP infrastructure for Kerberos authentication you must perform the following steps:

1. Register new custom-format SPNs for your SSP service account in Active Directory.
2. Run the Stsadm command-line tool to set the SSP infrastructure to use Kerberos authentication.
3. Add a new registry key to all of your servers running Office SharePoint Server 2007 to enable the generation of new custom-format SPNs.
4. Confirm Kerberos authentication for root-level shared Web service access.
5. Confirm Kerberos authentication for virtual-directory-level shared Web service access.

Note:

In the preceding procedure, steps 4 and 5 pertain to the searchadmin.asmx shared Web service. This Search-related shared Web service is located at both the root level of the SSP infrastructure and at the virtual directory level of the SSP infrastructure. The root-level Search shared service can be thought of as a global Web service that pertains to the configuration of the Office SharePoint Server 2007 Search service settings at the Services on Server level in Office SharePoint Server 2007 Central Administration. The virtual-directory-level Search shared service corresponds to a specific SSP in your farm, and is used when configuring Search settings specific to that SSP on the Shared Services Administration site. When performing the steps to verify Kerberos authentication for root-level shared services access, you will not see the generation or use of the new-format SPNs. You will only see the new-format SPNs when accessing the virtual directory level Web service; however, you need to verify that access to the shared service works at both levels.

Register new custom-format SPNs for your SSP service account in Active Directory

In this article, the SSP service account is mydomain\sspsvc, and the name of the SSP you created is SSP1. The SSP infrastructure exists on all servers in the farm; therefore, SPNs that refer to all servers running Office SharePoint Server 2007 must be created. Because the SSP infrastructure is bound to TCP port 56737 and SSL port 56738, you need SPNs that include both port numbers. Because of this, two SPNs are required for each application server. For the examples used in this article, you need to create 10 SPNs.

Perform the following procedure to create the SPNs for your SSP infrastructure:

1. Log on to your Active Directory domain controller using the credentials of a user that has domain administrative permissions.
2. In the Run dialog box, type ADSIEDIT.MSC.
3. In the Management Console dialog box, expand the domain container folder.
4. Expand the container folder containing user accounts, for example CN=Users.
5. Locate the container for the SSP service account, for example CN=sspsvc.
6. Right-click the SSP service account, and then click Properties.
7. Scroll down the list of properties in the SSP Service account dialog box until you find servicePrincipalName.
8. Select the servicePrincipalName property and click Edit.
9. In the Value to Add field, in the Multi-Valued String Editor dialog box, add the following SPNs:
• MSSP/mossfe1:56737/SSP1
• MSSP/mossfe1:56738/SSP1
• MSSP/mossfe2:56737/SSP1
• MSSP/mossfe2:56738/SSP1
• MSSP/mossadmin:56737/SSP1
• MSSP/mossadmin:56738/SSP1
• MSSP/mosscrawl:56737/SSP1
• MSSP/mosscrawl:56738/SSP1
• MSSP/mossquery:56737/SSP1
• MSSP/mossquery:56738/SSP1

Run the Stsadm command-line tool to set the SSP infrastructure to use Kerberos authentication

To configure your SSP infrastructure to use Kerberos authentication, perform the following procedure:

1. Log on to your Active Directory domain controller using the credentials of a user that has domain administrative permissions.
2. On one of your servers running Office SharePoint Server 2007, open a command prompt.
3. Change to the following directory: %COMMONPROGRAMFILES%\microsoft shared\web server extensions\12\bin.
4. Type the following command: stsadm –o setsharedwebserviceauthn –negotiate, and then press ENTER.

Ensure that this command runs successfully before proceeding.

When you have completed this procedure, the command applies to all of the SSPs that you create in your farm, including SSPs that you create after you have successfully run this command.

Add a new registry key to all of your servers running Office SharePoint Server to enable generation of the new custom-format SPNs

The generation of the new, custom-format SPNs is controlled through the setting of a new registry key introduced with the Infrastructure Update for Microsoft Office Servers. To enable the generation of the new, custom-format SPNs, this registry key must be added to all servers in the farm, and all servers must be restarted.

Perform the following steps to enable the new behavior. On each server in the farm:

1. Log on as a local administrator.
2. Run the Registry Editor, and add the following new registry key: HKLM\Software\Microsoft\Office Server\12.0\KerberosSpnFormat” (REG_DWORD) = 1
3. Restart the server. It is important to be aware that you must restart the server for the new registry key to take effect.

Caution:

Incorrectly editing the registry might severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

Confirm Kerberos authentication for root-level shared services access

To confirm Kerberos authentication for the root-level shared services, perform the following procedure:

1. Log on to the computer that is hosting the Central Administration Web application. If you are using the example in this article, log on to MOSSADMIN.
2. Go to Central Administration at http://mossadmin.mydomain.net:10000
3. On the Central Administration home page, click Operations.
4. On the Operations page, click Services on Server.
5. In the Server section, click the drop-down arrow to display the list of servers in the farm, and then click your Search Query server. If you are using the example in this article, select MOSSQUERY.
6. After the page refreshes, confirm that you are pointing to the correct query server, and in the Service section, click Office SharePoint Server Search.
7. Confirm that the Configure Office SharePoint Server Search Service Settings on server mossquery page is displayed.
8. Perform the following steps to confirm that Kerberos authentication was used to render the page:
• Log on to your Search Query server—using the example in this article, log on to the MOSS machine named MOSSQUERY.
• Run the Windows event viewer.
• Examine the Security event log.
• You should see a log record that is similar to the data shown in the following table:

Event Type	Success Audit
Event Source	Security
Event Category	Logon/Logoff
Event ID	540
Date	5/6/2008
Time	12:12:17 PM
User	MYDOMAIN\pscexec
Computer	MOSSQUERY
Description

An example of a successful network logon is depicted in the following table.

User Name	pscexec
Domain	MYDOMAIN
Logon ID	(0x0,0x7252B10)
Logon Type	3
Logon Process	Kerberos
Authentication Package	Kerberos
Workstation Name
Logon GUID	{a96a9450-3af5-d82e-3bb3-8cd65c8e5c49}
Caller User Name
Caller Domain
Caller Logon ID
Caller Process ID
Transited Services
Source Network Address	192.168.100.100
Source Port	1964
Important:
Repeat this procedure for your Search Indexing server to confirm that the page renders and that there is a security event viewer log record indicating that the Kerberos authentication package was used for accessing the page.

Confirm Kerberos authentication for virtual-directory-level shared services access

This is the final step in configuring and deploying a server farm running Office SharePoint Server 2007 using Kerberos authentication.

To confirm that Kerberos authentication is used for accessing the virtual-directory-level shared services, perform the following procedure:

1. Go to the Shared Services Administration home page.
2. Determine which of your load-balanced front-end Web servers is responding to this request.
3. On the front-end Web server that is responding to the request, run Network Monitor and apply a capture filter to capture KerberosV5 protocol packets. Using Network Monitor 3.2, this capture filter would be protocol.KerberosV5.
4. Start a Network Monitor sniff.
5. On the Shared Services Administration site home page, click Search Settings.
6. Confirm that the Search Settings page is displayed.
7. Stop the sniff and examine captured packets. You should see Kerberos protocol packets with descriptions that are similar to those shown in the following example:

KerberosV5:AS Request Cname: sspadminpool Realm: MYDOMAIN.NET Sname: krbtgt/MYDOMAIN.NET

KerberosV5:AS Response Ticket Realm: MYDOMAIN.NET, Sname: krbtgt/MYDOMAIN.NET

KerberosV5:TGS Request Realm: MYDOMAIN.NET Sname: MSSP/mosscrawl:56738/SSP1

KerberosV5:TGS Response Cname: sspadminpool

The Sname value in the preceding example (MSSP/mosscrawl:56738/SSP1) is the new-format SPN being generated and sent to the Kerberos KDC as a result of the changes included in the Infrastructure Update for Microsoft Office Servers.

Log on to your index server (in the example in this article, the index server is MOSSCRAWL). Run the event viewer and examine the security log. You should see an entry that is similar to the data shown in the following table:

Event Type	Success Audit
Event Source	Security
Event Category	Logon/Logoff
Event ID	540
Date	5/6/2008
Time	1:21:04 PM
User	MYDOMAIN\sspadminpool
Computer	MOSSCRAWL
Description

An example of a successful network logon is depicted in the following table.

User Name	sspadminpool
Domain	MOSSCRAWL
Logon ID	(0x0,0xD84A6)
Logon Type	3
Logon Process	Kerberos
Authentication Package	Kerberos
Workstation Name
Logon GUID	{2f1cccb3-c10d-27e5-9896-0f918e8ad796}
Caller User Name
Caller Domain
Caller Logon ID
Caller Process ID
Transited Services
Source Network Address	192.168.150.100
Source Port	1513

Configuration limitations

There are a few configuration limitations with respect to utilizing Kerberos authentication for the SSP infrastructure using the Infrastructure Update for Microsoft Office Servers:

• The host name portion of the new-format SPNs that are created will be the NetBIOS name of the host running the service, for example: MSSP/kerbtest4:56738/SSP1. This is because the host names are fetched from the Office SharePoint Server 2007 configuration database, and only NetBIOS computer names are stored in the Office SharePoint Server 2007 configuration database. This might be ambiguous in certain scenarios. Currently, the Stsadm command-line tool to rename a server running Office SharePoint Server 2007 cannot be successfully used to rename a server running Office SharePoint Server 2007, so there is no workaround for this issue.
• Do not use SSP names containing extended characters. An SPN with an SSP name containing extended characters cannot be selected as the target for delegation. Therefore, avoid using extended characters in your SSP names.

Additional resources and troubleshooting guidance

Product/technology	Resource
Windows Server 2003	Event ID 10017 error messages are logged in the System log after you install Windows SharePoint Services 3.0 [ http://go.microsoft.com/fwlink/?LinkId=120456&clcid=0x409 ] (http://go.microsoft.com/fwlink/?LinkId=120456&clcid=0x409)
SQL Server	How to make sure that you are using Kerberos authentication when you create a remote connection to an instance of SQL Server 2005 [ http://go.microsoft.com/fwlink/?LinkId=85942&clcid=0x409 ] (http://go.microsoft.com/fwlink/?LinkId=85942&clcid=0x409)
SQL Server	How to troubleshoot the "Cannot generate SSPI context" error message [ http://go.microsoft.com/fwlink/?LinkId=82932&clcid=0x409 ] (http://go.microsoft.com/fwlink/?LinkId=82932&clcid=0x409)
SQL Server	How to configure SQL Server 2005 Analysis Services to use Kerberos authentication [ http://go.microsoft.com/fwlink/?LinkId=120459&clcid=0x409 ] (http://go.microsoft.com/fwlink/?LinkId=120459&clcid=0x409)
.NET Framework	AuthenticationManager.CustomTargetNameDictionary Property [ http://go.microsoft.com/fwlink/?LinkId=120460&clcid=0x409 ] (http://go.microsoft.com/fwlink/?LinkId=120460&clcid=0x409)
Windows Internet Explorer	Internet Explorer 6 cannot use the Kerberos authentication protocol to connect to a Web site that uses a non-standard port in Windows XP and in Windows Server 2003 [ http://go.microsoft.com/fwlink/?LinkId=99681&clcid=0x409 ] (http://go.microsoft.com/fwlink/?LinkId=99681&clcid=0x409)
Windows Internet Explorer	Error message in Internet Explorer when you try to access a Web site that requires Kerberos authentication on a Windows XP-based computer: "HTTP Error 401 - Unauthorized: Access is denied due to invalid credentials" [ http://go.microsoft.com/fwlink/?LinkId=120462&clcid=0x409 ] (http://go.microsoft.com/fwlink/?LinkId=120462&clcid=0x409)
Kerberos authentication	Kerberos Authentication Technical Reference [ http://go.microsoft.com/fwlink/?LinkId=78646&clcid=0x409 ] (http://go.microsoft.com/fwlink/?LinkId=78646&clcid=0x409)
Kerberos authentication	Troubleshooting Kerberos Errors [ http://go.microsoft.com/fwlink/?LinkId=93730&clcid=0x409 ] (http://go.microsoft.com/fwlink/?LinkId=93730&clcid=0x409)
Kerberos authentication	Kerberos Protocol Transition and Constrained Delegation [ http://go.microsoft.com/fwlink/?LinkId=100941&clcid=0x409 ] (http://go.microsoft.com/fwlink/?LinkId=100941&clcid=0x409)
IIS	Configuring SSL Host Headers (IIS 6.0) [ http://go.microsoft.com/fwlink/?LinkId=120463&clcid=0x409 ] (http://go.microsoft.com/fwlink/?LinkId=120463&clcid=0x409)

 

Adding a new registry key

Last Edit 7:50 PM by Aamir Qureshi

What was meant with ... add the following new registry key: HKLM\Software\Microsoft\Office Server\12.0\KerberosSpnFormat” (REG_DWORD) = 1 ... Should KerberosSpnFormat be a DWORD value or a Key? And if that last, what is the DWORD value then?

Adding a new registry key- explaination

In the article where this is referenced, there is a double quote with no matching closing double quote. This may be confusing to you as the reader.

What it means is add a registry key of name KerberosSpnFormat of typeDWORD with a value of 1.

Go to registry path HKLM\Software\Microsoft\Office Server\12.0 and right click 12.0 >> New >> DWORD Value.

For Name type in KerberosSpnFormat and change the value from 0 (default) to 1

Delegation

Do any of the service accounts require delegation authority?

Also, I have Kerberos working on HTTPS sites only. It is not functioning on HTTP only sites. It doesn't even look like it tries Kerberos, it goes straight to NTLM. Any suggestions?

UPDATE: I fixed this problem. I was missing som SPN registraions for the DNS entries associated with the IIS host computer. All seems to be working now.

How to configure and verify SharePoint installation is communicating with SQL using Kerberos.

http://www.agileconcepts.com/Blogs/AQ/Lists/Posts/ViewPost.aspx?ID=4

http://feeds.feedburner.com/~r/AQPosts/~3/490866492/ViewPost.aspx

Wrong server name?

I believe you meant for the user in this scenario to run the SharePoint Wizard from the machine named mossadmin first so that Central Admin would be run from there. If so, change the following line: On the server named MOSSCRAWL, when setup completes, a Setup Complete dialog box appears... to read: On the server named MOSSADMIN, when setup completes, a Setup Complete dialog box appears.