Note: This article was originally published in 2006. Some steps, commands, or software versions may have changed. Check the current General documentation for the latest information.

Explanation:

Kerberos Authentication Requires SPNs for Multiple Worker Processes

You can isolate Web sites that are in different worker processes and running under different identities; however, unexpected IIS behavior might occur if you use Integrated Windows authentication. Integrated Windows authentication attempts to use Kerberos authentication, which might not work, depending upon the identity of the worker process. To use Kerberos authentication, a service must register its Service Principal Name (SPN) in the account in the Microsoft Active Directory® directory service under which the service is running. By default, Active Directory registers the NetBIOS name or computer name and allows the Network Service or LocalSystem user accounts to use Kerberos. However, for Kerberos to work with the following configurations, you must first register an SPN:

•If your site is referenced by a Windows Internet Name Service (WINS) or Domain Name System (DNS) name that is different from the computer name of the server running IIS (a Web farm, for example), authentication defaults to NTLM (which is also known as Microsoft Windows NT® Challenge/Response authentication).
•If you configure the worker process for the Web site to run as a domain account, and you did not use a WINS or DNS name, authentication will fail. This is because the SPN can be found, but it is registered for the Network Service and LocalSystem user accounts, not for the domain account under which the worker process is running.

You can use the Setspn.exe command-line tool to register an SPN on the account under which the worker process is running. You must be a domain administrator to set an SPN. The Setspn.exe tool is included in Resource Kit Tools for Windows Server 2003, available on the Windows Server  2003 Deployment Kit companion CD, or on the Web at http://www.microsoft.com/reskit.

obtained from: http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/77cf4a99-9e0e-42be-8c2e-eaa4cb24c200.mspx?mfr=true

RESOLUTION

loadTOCNode(1, ‘resolution’);

If this behavior occurs when the application pool is running under a local account, follow the steps in the “Workaround” section.

To resolve this behavior when the application pool is running under a domain user account, set up an HTTP SPN with the NetBIOS name and the fully qualified domain name (FQDN) of the domain user account that the application pool is running under. To do this, follow these steps on a domain controller:

Important An SPN for a service can only be associated with one account. Therefore, if you use this suggested resolution, any other application pool that is running under a different domain user account cannot be used with Integrated Windows authentication only. 1.Install the Setspn.exe tool. To obtain the Microsoft Windows 2000 version of the tool, visit the following Microsoft Web site:(http://www.microsoft.com/downloads/details.aspx?FamilyID=5fd831fd-ab77-46a3-9cfe-ff01d29e5c46&displaylang=en) (http://www.microsoft.com/downloads/details.aspx?FamilyID=5fd831fd-ab77-46a3-9cfe-ff01d29e5c46&displaylang=en)The Microsoft Windows Server 2003 version of the Setspn.exe command-line tool is available in the Windows Server 2003 Support Tools that are included on your Windows Server 2003 CD. To install the tools, double-click the Suptools.msi file in the Support/Tools folder.
2.Start a command prompt, and then change to the directory where you installed Setspn.exe.
3.At the command prompt, type the following commands. Press ENTER after each command:setspn.exe -a http/IIS_computer’s_NetBIOS_name DomainNameUserName

setspn.exe -a http/IIS_computer’s_FQDN DomainNameUserNameNote UserName is the user account that the application pool is running under.
After you set the SPN for the HTTP service to the domain user account that the application pool is running under, you can successfully connect to the Web site without being prompted for your user credentials.

WORKAROUND

loadTOCNode(1, ‘workaround’);To work around this behavior if you have multiple application pools that run under different domain user accounts, you must force IIS to use NTLM as your authentication mechanism if you want to use Integrated Windows authentication only. To do this, follow these steps on the server that is running IIS:1.Start a command prompt.
2.Locate and then change to the directory that contains the Adsutil.vbs file. By default, this directory is C:InetpubAdminscripts.
3.Type the following command, and then press ENTER:cscript adsutil.vbs set w3svc/NTAuthenticationProviders “NTLM”
4.To verify that the NtAuthenticationProviders metabase property is set to NTLM, type the following command, and then press ENTER:cscript adsutil.vbs get w3svc/NTAuthenticationProviders The following text should be returned:
NTAuthenticationProviders       : (STRING) "NTLM"

obtained from:
http://support.microsoft.com/default.aspx?scid=kb;en-us;871179