IIS Developer Support Voice column

Kerberos authentication and troubleshooting delegation issues

To customize this column to your needs, we want to invite you to submit your ideas about topics that interest you and issues that you want to see addressed in future Knowledge Base articles and Support Voice columns. You can submit your ideas and feedback using the Ask For It form. There's also a link to the form at the bottom of this column.

My name is Martin Smith, and I am with Microsoft's Microsoft Internet Information Services (IIS) Critical Problem Resolution group. I have been with Microsoft nine years and have been with the IIS team all nine years. I have compiled information from multiple locations on
http://msdn.microsoft.com and
http://www.microsoft.com about Kerberos and how to troubleshoot delegation issues.

IIS 6.0

The following white paper describes how to set up delegation in Microsoft Windows Server 2003. The white paper has specific information for Network Load Balancing (NLB) but includes excellent detail about how to set up a delegated scenario without using NLB. To view this white paper, visit the following Microsoft Web site:

http://technet.microsoft.com/en-us/library/cc757299.aspxNote Use HTTP Service Principal Names (SPNs) especially when you use NLB.

Another popular Kerberos issue recently has been the need to allow for multiple application pools to use the same DNS name. Unfortunately, when you use Kerberos to delegate credentials, you cannot bind the same Service Principal Name (SPN) to different application pools. You cannot do this because of the design of Kerberos. The Kerberos protocol requires multiple shared secrets for the protocol to work correctly. By using the same SPN for different application pools, we eliminate one of these shared secrets. The Active Directory directory service will not support this configuration of the Kerberos protocol because of the security issue.

Configuring the SPNs in this manner causes Kerberos authentication to fail. A possible workaround for this issue would be to use protocol transitioning. The initial authentication between the client and the Server Running IIS would be handled by using the NTLM authentication protocol. Kerberos would handle the authentication between IIS and the backend resource server.

Microsoft Internet Explorer 6 or later

The client browser may experience issues, such as receiving repeated logon prompts for credentials or "401 Access Denied" error messages from the server running IIS. We have found the following two issues that may help resolve these issues:

  • Verify that Enable Integrated Windows Authentication is selected in the browser's properties. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

    299838 Unable to negotiate Kerberos authentication after upgrading to Internet Explorer 6

  • If Internet Explorer Enhanced Security Configuration is enabled in Add/Remove Programs, you must add a site that uses delegation to the
    Trusted sites list. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

    815141 Internet Explorer Enhanced Security Configuration changes the browsing experience

IIS 5.0 and IIS 6.0

After you upgrade from IIS 4.0 to IIS 5.0 or IIS 6.0, delegation may not function correctly, or possibly someone or an application has modified the metabase property NTAuthenticationProviders.
For more information about how to fix this issue, click the following article number to view the article in the Microsoft Knowledge Base:

248350 Kerberos authentication fails after upgrading from IIS 4.0 to IIS 5.0

A particular area of trouble can occur when you set the SPN

Determine the server name

Determine whether you are connecting to the Web site by using the actual NetBIOS name of the server or by using an alias name, such as a DNS name (for example, www.microsoft.com). If you are accessing the Web server by using a name other than the actual name of the server, a new Service Principal Name (SPN) must have been registered by using the Setspn tool from the Windows 2000 Server Resource Kit. Because the Active Directory directory service does not know this service name, the ticket-granting service (TGS) does not give you a ticket to authenticate the user. This behavior forces the client to use the next available authentication method, which is NTLM, to renegotiate. If the Web server is responding to a DNS name of www.microsoft.com but the server is named webserver1.development.microsoft.com, you must register www.microsoft.com in Active Directory on the server that is running running IIS. To do this, you must download the Setspn tool and install it on the server that is running IIS.

If you are using Windows Server 2003 and IIS 6, the Setspn tool for Microsoft Windows Server 2003 is available from the following location:

http://support.microsoft.com/kb/970536To determine whether you are connecting by using the actual name, try to connect to the server by using the actual name of the server instead of the DNS name. If you cannot connect to the server, see the "Verify the computer is trusted for delegation" section.

If you can connect to the server, follow these steps to set an SPN for the DNS name that you are using to connect to the server:

  1. Install the Setspn tool.

  2. On the server running IIS, open a command prompt, and then open the C:\Program Files\Resource Kit folder.

  3. Run the following command to add this new SPN (www.microsoft.com) to the Active Directory for the server:

    Setspn -A HTTP/www.microsoft.com webserver1Note In this command, webserver1 represents the NetBIOS name of the server.

You receive output that is similar to the following:
Registering ServicePrincipalNames for CN=webserver1,OU=Domain Controllers,DC=microsoft,DC=com
Updated object
To view a listing of SPNs on the server to see this new value, type the following command on the server running IIS:

Setspn -L webservername Note that you do not have to register all services. Many service types, such as HTTP, W3SVC, WWW, RPC, CIFS (file access), WINS, and uninterruptible power supply (UPS), will map to a default service type that is named HOST. For example, if your client software uses an SPN of HTTP/webserver1.microsoft.com to create an HTTP connection to the Web server on the webserver1.microsoft.com server, but this SPN is not registered on the server, the Windows 2000 domain controller will automatically map the connection to HOST/webserver1.microsoft.com. This mapping applies only if the Web service is running under the local System account.

Verify that the computer is trusted for delegation

If this server running IIS is a member of the domain but is not a domain controller, the computer must be trusted for delegation for Kerberos to work correctly. To do this, follow these steps:

  1. On the domain controller, click Start, point to Settings, and then click Control Panel.

  2. In Control Panel, open Administrative Tools.

  3. Double-click Active Directory Users and Computers.

  4. Under your domain, click Computers.

  5. In the list, locate the server running IIS, right-click the server name, and then click Properties.

  6. Click the General tab, click to select the
    Trusted for delegation check box, and then click

Note that if multiple Web sites are reached by the same URL but on different ports, delegation will not work. To make this work, you must use different hostnames and different SPNs. When Internet Explorer requests either http://www.mywebsite.com or http://www.mywebsite.com:81, Internet Explorer requests a ticket for SPN HTTP/www.mywebsite.com. Internet Explorer doesn't add the port or the vdir to the SPN request. This behavior is the same for http://www.mywebsite.com/app1 or http://www.mywebsite.com/app2. In this scenario, Internet Explorer will request a ticket for SPN http://www.mywebsite.com from the Key Distribution Center (KDC). Each SPN can be declared only for one identity. Therefore, you would also receive a KRB_DUPLICATE_SPN error message if you try to declare this SPN for each identity.

Delegation and Microsoft ASP.NET

For more information about the configuration for delegating credentials when you use an ASP.NET application, click the following article number to view the article in the Microsoft Knowledge Base:

810572 How to configure an ASP.NET application for a delegation scenario

Impersonation and delegation are two methods for a server to authenticate on the behalf of the client. Deciding which of these methods to use and their implementation can cause some confusion. You must review the difference between these two methods and examine which of these methods you may want use for your application. My recommendation would be to read the following white paper for further details:





305971 Windows 2000 Server prompts domain user for credentials

262177 How to enable Kerberos event logging

326985 How to troubleshoot Kerberos-related issues in IIS

842861 TechNet Support WebCast: Troubleshooting Kerberos authentication with secure Web applications and Microsoft SQL Server

As always, feel free to submit ideas on topics you want addressed in future columns or in the Knowledge Base using the
Ask For It form.

Need more help?

Expand your skills
Explore Training
Get new features first
Join Microsoft Insiders

Was this information helpful?

What affected your experience?

Thank you for your feedback!