****
*
*
*
*







*
*
                                      
*
*
Windows Server



    

Troubleshooting Kerberos Delegation    

*
*

*
*

Troubleshooting Kerberos Delegation


Categories:


Tags:


Apr
21

Troubleshooting Kerberos Delegation

 

 

Latest Hotfixes

 

An error code is returned when a Kerberos client requests a TGT against a Windows Server 2008-based domain controller: "KERB5KDC_ERR_C_PRINICPAL_UNKNOWN"

View products that this article applies to.

Article ID: 951191 Last Review: May 21, 2008

 

When the Kerberos ticket expires for a Kerberos-authenticated SMB connection that is created to a Windows Server 2003-based server,

The oplock on a file cannot be broken in a timely manner

Article ID: 943459 Last Review: February 4, 2008

 

Event ID 1000 is logged when you configure Kerberos authentication between front-end and back-end servers that are running Exchange Server 2003

Article ID: 909094 Last Review: May 13, 2008

 

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/tkerbdel.mspx

Troubleshooting Kerberos Delegation

This white paper explains how to troubleshoot delegation issues that can arise in Kerberos authentication scenarios. The white paper summarizes required infrastructure and describes examples of Windows® authentication scenarios. The central discussion is organized around four troubleshooting checklists: one each for Active Directory® directory service, client application, middle tier, and back-end. The appendices detail diagnostic tools and give examples of how to resolve problems in typical IIS to SQL delegation scenarios.

 

Introduction

This white paper discusses various methods to troubleshoot delegation issues. Because a common use of Kerberos delegation is with Internet Information Services (IIS) and SQL Server, this white paper details examples of IIS/SQL delegation scenarios in Appendix B.

This white paper presumes that you know how Kerberos authentication works. For more information about the Kerberos protocol and operations, see:

Microsoft Windows Server 2003 Technical Reference at http://go.microsoft.com/fwlink/?LinkId=21711

“Basic Overview of Kerberos User Authentication Protocol in Windows 2000” in the Microsoft Knowledge Base athttp://go.microsoft.com/fwlink/?LinkId=24922

 

Infrastructure Requirements

Problems with Kerberos authentication can often involve technologies on which the Kerberos SSP depends, or can stem from easy-to-correct oversights in the configuration of Kerberos settings. This section reviews dependencies and summarizes how each dependency relates to troubleshooting Kerberos authentication.

Operating System

Kerberos authentication relies on client functionality that is built in to the Microsoft® Windows Server™ 2003 operating system, the Microsoft Windows® XP operating system, and the Microsoft Windows® 2000 operating system. If a client, domain controller, or target server is running an earlier operating system, it cannot natively use Kerberos authentication.

TCP/IP Network Connectivity

For Kerberos authentication to occur, there must be TCP/IP network connectivity between the client, the domain controller, and the target server.

If you use a firewall, be sure that the Kerberos ports are enabled on the network. For more information about common ports that domain controllers use, see “A List of the Windows Server Domain Controller Default Ports” in the Microsoft Knowledge Base athttp://go.microsoft.com/fwlink/?LinkId=22894.

  Note
A user who can log on with cached credentials might not be aware of a connectivity issue.

Domain Name System

The client uses the fully qualified domain name (FQDN) to access the domain controller.

DNS must be functioning for the client to obtain the FQDN.

For best results, do not use Hosts files with DNS.

For more information about DNS, see “Process for Deploying DNS” in the Microsoft Windows Server 2003 Deployment Kit athttp://go.microsoft.com/fwlink/?LinkId=23041.

Active Directory Domain

Kerberos authentication is not supported in earlier operating systems such as the Microsoft® Windows NT® 4.0 operating system. You must be using user and computer accounts in the Active Directory® directory service to use Kerberos authentication. Local accounts and Windows NT domain accounts cannot be used for Kerberos authentication.

Time Service

For Kerberos authentication to function properly, it is vital that the time on computers on a network be synchronized — that is, that all domains and forests in a network use the same time source. An Active Directory domain controller will act as an authoritative source of time for its domain, which guarantees that an entire domain will have the same time. For more information, see “Windows Time Service Technical Reference” on Microsoft TechNet at http://go.microsoft.com/fwlink/?LinkId=25393.

Service Principal Names

Service Principal Names (SPNs) are unique identifiers for services running on servers. Every service that will use Kerberos authentication needs to have an SPN set for it so that clients can identify the service on the network. If an SPN is not set for a service, then clients will have no way of locating that service. Without properly set SPNs, Kerberos authentication is not possible.

If an SPN has not been correctly set and a client attempts to obtain a service ticket, a common result is a KDC_ERR_C_PRINCIPAL_UNKNOWN or a KDC_ERR_S_PRINCIPAL_UNKNOWN error. Furthermore, there are many other errors for which the cause might be a missing or an incorrectly set SPN.

In general, an SPN can be set at the time of service account creation or when installing a service on a new computer. The SPN identifies details such as which computer the service is running on, which account the service is running under, and which port the service runs on. Thus, setting an SPN on a service account is almost the security equivalent of creating that account. A service account that is created for a service without an SPN set will not be issued a service ticket encrypted with its service key in a 2003 functional level domain. Instead, user-to-user mode will be Windows Server used. For more information about user-to-user authentication, see How the Kerberos Version 5 Authentication Protocol Works in the 2003 Technical Reference at Windows Server http://go.microsoft.com/fwlink/?LinkID=27175, and search for "The User-to-User Authentication Process."

The built-in SPNs that are recognized for computer accounts are listed in Table 1. These SPNs are recognized for computer accounts if the computer has a HOST SPN. Unless they are explicitly placed on objects, a HOST SPN can substitute for any of the listed SPNs.

Table 1   Built-in SPNs Recognized for Computer Accounts

SPN

 

 

 

alerter

http

policyagent

scm

appmgmt

ias

protectedstorage

seclogon

browser

iisad

rasman

snmp

cifs

min

remoteaccess

spooler

cisvc

messenger

replicator

tapisrv

clipsrv

msiserver

rpc

time

dcom

mcsvc

rpclocator

trksvr

dhcp

netdde

rpcss

trkwks

dmserver

netddedsm

rsvp

ups

dns

netlogon

samss

w3svc

dnscache

netman

scardsvr

wins

eventlog

nmagent

scesrv

www

eventsystem

oakley

schedule

 

fax

plugplay

 

 

An SPN is registered in Active Directory under a user account as an attribute called Service-Principal-Name. The SPN is assigned to the account under which the service the SPN identifies is running. Any service can look up the SPN for another service. When a service wants to authenticate to another service, it uses that service’s SPN to differentiate it from all of the other services running on that computer.

SPNs are critical to constrained delegation. When you set up a domain computer or user account for delegation, one step of the process is to list the SPNs of services on other computers that the computer is allowed to delegate to. This list forms a type of ACL. The services running on the other computers are identified by the SPNs that are issued to those services.

Permissions required to set SPNs

To write any SPN on a given computer account, the Write ServicePrincipalName permission is required, which is not granted by default to the person who created the account. The creator has the Validated write to Service Principal Name permission.

To write an SPN on a user account, the Write Public Information permission grants the security principal the ability to create arbitrary SPNs.

Table .1   Default Active Directory Permissions Affecting Creation of SPNs

Security Principal

Computer Account Object

User Account Object

Account Creator

Validated write to Service Principal Name

Write Public Information

SELF

Validated write to Service Principal Name

None

Account Operators

Write servicePrincipalName

Validated write to Service Principal Name

Write Public Information

Administrators

Write servicePrincipalName

Validated write to Service Principal Name

Write Public Information

Authenticated Users

None

None

Therefore, machine accounts can write validated SPNs, but not arbitrary SPNs.

Requirements for setting an SPN

Multiple services can run simultaneously under the same account. Therefore, for each SPN that is set, you need these four unique pieces of information:

The type of service, formally called a service class. This enables you to differentiate between multiple services running under the same account.

The account under which the service is running.

The computer on which the service is running, including any aliases that point to that computer.

The port on which the service is running.

These four pieces of information uniquely identify any service running on a network and can be used to mutually authenticate to any service.

An SPN itself consists of three pieces of information, ServiceClass/Host:Port, where:

ServiceClass is the service class of the SPN.

Host is the name of the computer to which the SPN belongs.

Port is the port that the service the SPN is registered to runs on.

For more information about how to use the Setspn utility to manipulate Service Principal Names for accounts, see Setspn in Appendix A: Diagnostic Tools.

 

Windows Authentication Scenarios

Many different authentication scenarios are possible with Windows operating systems. Kerberos authentication features delegation, which enables impersonation of user identity across multiple servers. Constrained delegation was introduced in Windows Server 2003.

This paper focuses on troubleshooting Kerberos delegation issues. Understanding how Kerberos authentication operates with constrained delegation and protocol transition can help you decide configuration choices you might need to make to solve a problem.

Delegation provides a different method for authentication than the challenge-response method provided by NTLM. The following sections illustrate NTLM authentication, Kerberos authentication with NTLM authentication, and three different delegation scenarios involving Kerberos authentication.

NTLM Authentication

clip_image001

Figure 1   NTLM Challenge-Response

Earlier versions of Windows operating systems use NTLM to validate credentials. In the NTLM protocol, the client sends the user name to the server; the server generates and sends a challenge to the client; the client encrypts that challenge using the user’s password; and the client sends a response to the server. The challenge-response mechanism varies depending on whether the account is a local user account or a domain user account.

Local user account. The server will look into its Security Accounts Manager (SAM). If the server computes a similar result, it validates the user’s response, constructs an access token, and establishes a session for the user.

Domain user account. The server forwards the challenge, along with client’s response, to the domain controller. The domain controller validates the response and sends the client’s group information to the server computer. With that information, the server constructs an access token and establishes a session for the user.

clip_image002

Figure 2   Authentication to Back-end Servers with NTLM

Access as null user

NTLM requires the client to have the user’s password whenever it has to connect to a remote server, but the password is never transmitted to the server. The drawback of this is that the front-end server cannot access back-end servers with the user’s identity, because the front-end server does not have the user’s password.

Thus, whenever the front-end server attempts to connect to back-end servers on the user’s behalf, it will connect as a null user. (See Figure 2.) Null user also occurs when a process running under the System account tries to access remote resources using the NTLM protocol. Thus, if you encounter an error message that says Access denied for null user, you can assume that the connection is using NTLM.

In NTLM authentication, after the user authenticates to the front-end server, there is no way for the user’s credentials to be preserved if the front-end server needs to access a service that is running on a back-end server. The back-end server receives an authentication request from the account of the front-end server, but the back-end server:

Cannot determine who the user is.

Cannot differentiate between two users’ identities to determine which made requests to the front-end server.

Cannot provide different access controls to resources based on a user’s identity.

Kerberos Authentication with NTLM Authentication or Single Account Mapping

clip_image003

Figure 3   Kerberos and NTLM Hybrid Authentication

Kerberos authentication can enhance security because auditing and accountability can be established. However, the front-end server potentially has the added load of authenticating thousands of unique users under heavy traffic. With NTLM, on the other hand, after initial authentication to the front-end server, no further user authentications are required, only authentications of computer accounts. The authentication scenario illustrated in Figure 3 combines NTLM and Kerberos authentication. The user’s identity is passed to another computer to allow for tracking and logging, but the last hop is done under the computer account to lighten the load on the front-end server. However, this is not recommended for the same reason given above in the null user situation — that is, the back-end server cannot verify the identity of the user requesting the service.

A similar scenario is if the front-end server were configured to use a single account to access the back-end server. The same result would occur, even if Kerberos authentication were used in both hops.

Because the user’s identity is not used to access the back-end server in either of the two scenarios described, neither scenario is recommended.

Kerberos Authentication

Delegation is possible only with the Kerberos protocol. Thus, all parties involved in delegation scenarios must use the Kerberos protocol. There are three delegation scenarios illustrated in this section:

Kerberos authentication

Kerberos authentication using constrained delegation

Kerberos authentication using constrained delegation with protocol transition

Kerberos authentication

clip_image004

Figure 4   Basic Kerberos Delegation

With Kerberos authentication, when the user authenticates to the front-end server, the server transitions from running under its own service account to running under the user’s account. The front-end server can then impersonate the user and access any resources that the user is authorized to access. Furthermore, the back-end server can verify that the user is the entity who is requesting access.

Delegation enables the user’s credentials to be passed from one server to another and for the user’s identity to be preserved as services are requested from one computer to another. Thus, the front-end server illustrated in Figure 4 could be replaced by multiple middle tier servers, but the user would still need to be impersonated in communications with the back-end server.

  Note
All middle tier servers must be trusted for delegation.

Kerberos authentication using constrained delegation

In Windows Server 2003, constrained delegation provides a way for domain administrators to limit which network resources an account trusted for delegation can access.

In Windows 2000, on the other hand, there is no support In Windows for limiting delegation. After an account is trusted for delegation, that service can access any network resource using the user’s identity. This can be dangerous if that particular service is compromised by a malicious user.

  Note
Constrained delegation is possible only if the domain is 2003 domain functional level. In the case of a client raised to Windows Server to front-end server to back-end server scenario shown in Figure 5, the front-end server must be configured to use delegation with only the back-end server.

clip_image005

Figure 5   Constrained Delegation

In order to limit the resources that services can access on behalf of a user, you can configure constrained delegation by listing services to which an account can present delegated credentials. This list is in the form of SPNs that the user is allowed to delegate to. In constrained delegation, the Web service’s account only receives permission to delegate to the back-end server’s SPN.

clip_image006

Figure 6   Compromised Web Service

With constrained delegation in place, if a malicious user compromises the Web service’s account, the malicious user only has access to the back-end server. (See Figure 6.)

For more information about SPNs, see Service Principal Names earlier in this white paper.

For more information about constrained delegation, see “Kerberos Protocol Transition and Constrained Delegation” on Microsoft TechNet athttp://go.microsoft.com/fwlink/?LinkId=18156.

 

Kerberos authentication using constrained delegation with protocol transition

In Windows Server 2003, protocol transition enables delegation to occur even if initial authentication uses another SSP instead of the Kerberos SSP— for example, NTLM or Schannel.

clip_image007

Figure 7   SSL to Kerberos Protocol Transition

Because it is unrealistic to perform Kerberos authentication over the Internet, a method such as Secure Socket Layers (SSL) might be used by a front-end server. However, after the front-end server verifies the user’s identity, the front-end server can perform a protocol transition and subsequently use all Kerberos authentication features within the corporate network. Thus, developers do not have to rely on a single authentication protocol for the entire authentication process.

For more information about protocol transition and constrained delegation, see “Kerberos Protocol Transition and Constrained Delegation” on Microsoft TechNet at http://go.microsoft.com/fwlink/?LinkId=18156.

 

Configuring Kerberos Delegation

Kerberos delegation requires Kerberos authentication. Therefore, be sure that infrastructure requirements for Kerberos authentication are met before you troubleshoot delegation. For more information, see Infrastructure Requirements earlier in this white paper.

clip_image008

Figure 8   Fundamental Requirements for Kerberos Delegation

Requirements for Delegation

A domain user for the application must not have the Account is sensitive and cannot be delegated selected option.

SPNs must be registered for the services on the middle tier servers. The service’s SPN must be registered by a domain administrator if the service account is a domain user account. If the service account uses the computer’s account, then the process can register by itself or the local administrator can register it by using Setspn. For more information about Setspn, see Setspn in Appendix A: Diagnostic Tools.

Middle tier service accounts must be trusted for delegation.

An SPN must be registered for the service on the back-end server.

If using constrained delegation, then middle tier services and back-end services must be in the same domain.

 

Diagnosing Delegation Problems: Four Checklists

The following sections can help you diagnose problems that can occur in the client-to-middle tier -to-back-end delegation scenario. Moreover, the following sections can help you address difficulties commonly encountered when setting up this scenario.

The sections describe the various kinds of problems that might arise, discuss possible reasons behind those problems, and outline steps to resolve the problems. The discussion is presented as a sequence of checklists, each containing a Task column and a Process column. In most cases, the Process column summarizes what you need to do to accomplish the task. The details of the process, however, are illustrated in the section below the checklist itself.

Checklist 1 — Active Directory. SPNs and accounts properly configured.

Checklist 2 — Client Application. Application properly configured and using Kerberos authentication.

Checklist 3 — Middle Tier. Services configured for delegation and using Kerberos authentication.

Checklist 4 — Back-end. Services configured for Kerberos authentication.

In some organizations, the administrator who will configure the accounts might not be the same person who will troubleshoot delegation issues. Therefore, Active Directory tasks have been collected into one checklist.

The other three checklists are organized by role in the scenario and include the account configuration information relevant to the role:

Client. The application from which the user is making the request.

Middle tier. The services in between that will make requests on the behalf of the user.

Back-end. The final services that the middle tier services communicate with when impersonating the user.

For the purpose of the checklists, only one checklist will apply to each system or service participating in delegation. That is, no matter how complex your environment, use the client checklist for all clients, the back-end checklist for all back-end services, and the middle tier checklist for everything in between.

Figure 9 illustrates elements that can be involved in delegation scenarios.

clip_image009

Figure 9   Client-to-Middle Tier-to-Back-end Delegation Scenario

In the example above, the client has the client role; middle tier server 1 has the middle tier role; the back-end servers 1 through n have the back-end role; the middle tier servers 2 through n in between have both middle tier and back-end roles. For the purpose of these checklists, treat middle tier server n as a middle tier server because the tasks required for back-end services are a subset of those for middle tier services.

Troubleshooting Tactics

Some error messages might help you diagnose where the problem could have occurred, but sometimes they might not. For more information about troubleshooting Kerberos errors, see the Troubleshooting Kerberos Errors white paper at http://go.microsoft.com/fwlink/?LinkID=27176.

As you troubleshoot, be sure that you use the Kerberos protocol to authenticate to each service. Note, however, that you might need to use different applications in troubleshooting each service. For example:

If the server is running SQL Server, then the client application can be Query Analyzer, osql.exe, or a VB Script using ADO.

If the server is running IIS, then the client application can be Internet Explorer.

In a typical use of delegation, a user authenticates to a server running IIS, which accesses a SQL database, either directly or by way of a Web service. With delegation, the user who has permission to access data in the SQL database can be impersonated by the middle tier service. In this kind of situation, constrained delegation is often used so that the user can only access certain services running on the computer.

Checklist 1 — Active Directory

Active Directory: SPNs and Accounts Properly Configured

Task

Process

Date Completed/By Whom

From a command prompt

 

 

Verify that SPNs are registered for the middle tier services.

Verify that SPNs are registered for the back-end services.

1.

At a command prompt, type:

setspn –L Account

where Account is the name of the account under which the service is running.

2.

Verify that these two SPNs for the service account are present:

One for ServiceClass/Host:Port

One for ServiceClass/FQDN

For more detailed instructions, see Verify SPNs for Middle Tier Service Accounts.

For examples, see Appendix B.

 

From Active Directory Users and Computers

 

 

If using constrained delegation:

Verify domain functional level is set to Windows Server 2003.

For more detailed instructions, see Verify Domain Functional Level.

 

For the user account:

Verify that the Account is sensitive and cannot be delegated option is not selected.

1.

Right-click the user account, and then click Properties.

2.

Click the Account tab.

3.

In the Account options box, confirm that Account is sensitive and cannot be delegated is not selected.

For more detailed instructions, see Verify Account Options.

 

Verify that delegation is configured for middle tier services.

If middle tier service is using the computer account:

Right-click the computer account, and then click Properties.

If the account is in a Windows 2000 functional level domain, verify that the Account is trusted for delegation option is selected.

If the account is in a Windows Server 2003 functional level domain, configure options on the Delegationtab.

If middle tier service is using a domain user account:

Right-click the service account, and then click Properties.

If the service account is in a Windows 2000 functional level domain, the Account is trusted for delegation option on the Accounttab should be selected.

If the computer account is in a Windows Server 2003 functional level domain, configure options on the Delegation tab.

For more detailed instructions, see Verify Delegation for Middle Tier Service Accounts.

For examples, see Appendix B.

 

If you are using Group Policy to configure, verify that middle tier services have either of these two privileges:

Act as part of the operating system

Impersonate a client after authentication

1.

Open the domain security policy by clicking Start, Programs,Administrative Tools, and thenDomain Security Policy.

2.

Click Local Policies, and then clickUser Rights Assignment.

For more detailed instructions, see Verify Middle Tier Service Privileges.

 

 

clip_image010

Figure 10   Active Directory Accounts Configuration

The following tasks have general configuration instructions. You can find examples of what specifically needs to be set in common scenarios in Appendix B.

Verify SPNs for Middle Tier Service Accounts

Verify that an SPN is registered for each middle tier service account in the scenario. If the middle tier service is running as the Local System or the network service, you do not need to set any SPNs manually. Consequently, you do not need to verify that SPNs have been set correctly because every SPN will have been automatically set.

Verify that SPNs have been set for service accounts

At a command prompt, type:

setspn –L Account 

where Account is the name of the service account.

There should be at least two SPNs listed, because the following two SPNs for the service account must be present for delegation to properly function:

ServiceClass/Host:Port, where ServiceClass is the appropriate service class, Host is the name of the host computer, and Port is the port the service is running on.

ServiceClass/FQDN, where FQDN is the fully qualified domain name of the host computer.

Resolution

If there are no SPNs listed or if there is an SPN missing, then add the appropriate SPN using the setspn –A command. If there are duplicate SPNs listed, then use the Setspn utility to rename or delete the duplicate SPNs. You can use Ldifde to query the global catalog to ensure there are no duplicate SPNs.

For examples, see Appendix B.

Verify SPNs for Back-end Service Accounts

Verify that an SPN is registered for each back-end service account in the scenario. If the back-end service is running as the Local System or the network service, you do not need to set any SPNs manually. Consequently, you do not need to verify that SPNs have been set correctly because every SPN will have been automatically set.

If the back-end service is using a domain user account, then verify that an SPN has been set for service account.

For examples, see Appendix B.

 

Verify Domain Functional Level

If you are configuring constrained delegation, you need to verify that the domain controller is operating at Windows Server 2003 functional level. (Note: This step is required only for constrained delegation.)

clip_image011

Figure 11   Windows Server 2003 Domain Functional Level

  Important
Windows 2000 does not support constrained delegation. Because unconstrained delegation will diminish security, avoid using delegation in Windows 2000 environments.

 

To verify the functional level of your domain controller

1.

Open Active Directory Users and Computers.

2.

Right-click DomainName, and then click Properties.

3.

Verify that Windows Server 2003 is listed under Domain functional level.

 

Verify User Account Options

Verify that the Account is sensitive and cannot be delegated option is not selected for the user accounts.

To verify that the Account is sensitive and cannot be delegated option is not selected:

1.

Open Active Directory Users and Computers.

2.

Right-click UserAccount, and then click Properties.

3.

Click the Account tab.

clip_image012

Figure 12   User Account Options

4.

In the Account options box, confirm that Account is sensitive and cannot be delegated is not selected.

 

Verify Delegation for Middle Tier Service Accounts

Verify that each middle tier service account in the scenario is trusted for delegation. If a middle tier service account is not trusted for delegation, then you will receive errors such as:

Logon failed for null user

Logon failed for NT AUTHORITY\ANONYMOUS user

Even though the Kerberos protocol can be used between the client and a middle tier service and between the middle tier service and a back-end service, if a middle tier service is not trusted for delegation, then the middle tier service will not have a client’s TGT. Thus, authentication falls back to NTLM. Because the middle tier service does not have network credentials (that is, the user’s password), it goes out as null user.

For examples, see Appendix B.

Service runs under the computer account

If the service runs under the computer account, then you will need to configure the computer account of the server for delegation.

 

To verify that the middle tier server computer account is trusted for delegation

1.

Open Active Directory Users and Computers.

2.

Find the computer account for the middle tier server.

3.

Right-click the account, and then click Properties.

If the computer account is in a Windows 2000 functional level domain, the Trust computer for delegation option on the Generaltab should be selected. (See Figure 13.)

clip_image013

Figure 13   Functional Level Windows 2000 Domain Computer Account Trusted for Delegation

 

If the computer account is in a Windows Server 2003 functional level domain, click the Delegation tab.

clip_image014

Figure 14   Windows Server 2003 Functional Level Domain Computer Account Not Trusted for Delegation

On the Delegation tab, if Do not trust this computer for delegation is selected, then select one of the two Trust options:

1.

To configure the account to use unconstrained delegation, select Trust this computer for delegation to any service (Kerberos only). This option is not recommended.

2.

To configure the account to use constrained delegation, select Trust this computer for delegation to specified services only. Configure protocol transition by selecting one of the following two options:

To configure the account to use constrained delegation without protocol transition, select Use Kerberos only.

To configure the account to use constrained delegation with protocol transition, select Use any authentication protocol.

  Note
When using constrained delegation, confirm that the appropriate SPNs are in the Services to which this account can present delegated credentials list. Recall that an SPN itself consists of three pieces of information, ServiceClass/Host:Port, where:

ServiceClass is the service class of the SPN.

Host is the computer to which the SPN belongs.

Port is the port that the service the SPN is registered to runs on.

If the service runs under a domain user account

If the service runs under a domain user account, then you will need to configure the service account for delegation.

 

To verify that the middle tier service account is trusted for delegation

1.

Open Active Directory Users and Computers.

2.

Locate the service account you are configuring, right-click the account, and then click Properties.

If the computer account is in a Windows 2000 functional level domain, click the Account tab.

clip_image015

Figure 15   Service Account Trusted for Delegation

In the Account options box, confirm that Account is trusted for delegation is selected.

If the service account is in a Windows Server 2003 functional level domain, click the Delegation tab.

clip_image016

Figure 16   Service Account Without Protocol Transition

On the Delegation tab, select one of the two Trust options:

1.

To configure the account to use unconstrained delegation, select Trust this user for delegation to any service (Kerberos only). This option is not recommended.

2.

To configure the account to use constrained delegation, select Trust this user for delegation to specified services only. Configure protocol transition by selecting one of the following two options:

To configure the account to use constrained delegation without protocol transition, select Use Kerberos Only. (See Figure 16.)

To configure the account to use constrained delegation with protocol transition, select Use any authentication protocol.

  Note
When using constrained delegation, confirm that the appropriate SPNs are in the Services to which this account can present delegated credentials list. These should be the SPNs of back-end services. Recall that an SPN itself consists of three pieces of information, ServiceClass/Host:Port, where:

ServiceClass is the service class of the SPN.

Host is the computer to which the SPN belongs.

Port is the port that the service the SPN is registered to runs on.

 

Verify Middle Tier Service Privileges

Because the ability to act as another user is a primary component of delegation, a process cannot delegate if it does not possess the necessary privilege. Therefore, verify that each middle tier service in the delegation scenario has either of these two privileges:

Act as part of the operating system (available in Windows 2000 or Windows Server 2003)

Impersonate a client after authentication (added in Windows Server 2003)

Both of these privileges give an account the ability to act as another user. The Impersonate a client after authentication privilege is similar to the Act as part of the operating system privilege except that it is not as far-reaching. That is, it will only allow a process to impersonate after authentication, whereas Act as part of the operating system privilege allows a process to impersonate before authentication.

The Local System account is assigned Act as part of the operating system privilege by default. Thus, if the middle tier service is running as Local System, you do not need to modify user right assignments in the security policy. For all other accounts, you will need to configure the Act as part of the operating system or the Impersonate a client after authentication privilege. If you are configuring these privileges with Group Policy, you need to verify at the domain controller that the policy is configured correctly. If you configure using local security policy, the procedure is covered in Checklist 3 — Middle Tier.

When protocol transition is being used, the middle tier service often does not have information about the identity of the incoming user — that is, the incoming user might have authenticated with a protocol that did not provide so complete a set of credentials as Kerberos authentication would have. Therefore, you will need to assign the Act as part of the operating system privilege to those middle tier services.

For example, although a middle tier service that is running IIS might grant the incoming user the permission to view a Web page, it has not formally authenticated the user. Therefore, the middle tier service that is running IIS must have the Act as part of the operating system privilege in order to impersonate this user when it requests either a Web service or a back-end server.

Thus, you should configure the first middle tier service with Act as part of the operating system. However, because Impersonate a client after authentication privilege is not as far-reaching, you should configure any middle tier services that will be accessed after the initial authentication with Impersonate a client after authentication (if you are using Windows Server 2003).

 

To verify that service accounts have appropriate privileges

1.

Open the domain security policy by clicking Start, Programs, Administrative Tools, and then Domain Security Policy.

  Note
Follow the instructions in Step 1 if Group Policy is enforced by the domain controller. If policy is enforced by the local computer, then you must open local security policy on the local computer. For local security policy instructions, see Checklist 3 — Middle Tier.

2.

Click Local Policies, and then click User Rights Assignment.

For example, Figure 17 shows that Tailspintoys\iisservice has the Impersonate a client after authentication privilege assigned.

clip_image017

Figure 17   User Rights Assignment in Default Domain Security Settings

To set Impersonate a client after authentication privilege on service accounts

1.

Open the domain security policy by clicking Start, Programs, Administrative Tools, and then Domain Security Policy. (See note in the procedure immediately above.)

2.

Click Local Policies, then User Rights Assignment, and then click Impersonate a client after authentication.

3.

Add any accounts that will need to delegate credentials (for example, the IIS account).

4.

Because the change was made in domain security policy on the domain controller, then, at a command prompt, run gpupdate /forceon the client computers to propagate the policy change immediately.

Checklist 2 — Client Application

Client Application: Configured for and Using Kerberos Authentication

Task

Process

Date Completed/By Whom

From Active Directory Users and Computers:

Verify that the Account is sensitive and cannot be delegated option Is not selected for the account. (Note: You already completed this task if you completed the Active Directory checklist.)

1.

Right-click the user account, and then click Properties.

2.

Click the Account tab.

3.

In the Account options box, confirm that Account is sensitive and cannot be delegated is not selected.

For more detailed instructions, see Verify User Account Options.

 

Verify that name resolution is functioning correctly.

1.

Use ping to verify that you can resolve the FQDN of the middle tier server and the back-end server.

2.

Verify client’s local Hosts file does not have short name for the middle tier server or the back-end server.

3.

Ensure that you use the FQDN of the server for the connection if the client and server are in two different domains.

For more detailed instructions, see Verify Name Resolution.

 

Verify that the client application is configured for the Kerberos protocol.

For detailed instructions, see Verify Application Configured for Kerberos Protocol.

For examples, see Appendix B.

 

Verify that the client is using Kerberos authentication to authenticate to the service.

You can verify by:

Checking the security log on the middle tier server for NTLM failure audits.

Using Kerberos Tray to purge the tickets before connecting to the server and then observing the tickets to find a ticket to connect to the server.

Using Network Monitor to observe the traffic from the client to your domain controller on Kerberos port 88.

For more detailed instructions, see Verify Client Is Using Kerberos Authentication.

 

clip_image018

Figure 18   Kerberos Client Application

Verify User Account Options

Verify that the Account is sensitive and cannot be delegated option is not selected for the user account. Note: If you are completing the checklists in sequence, you completed this task in the Active Directory checklist.

To verify that the Account is sensitive and cannot be delegated option is not selected

1.

Open Active Directory Users and Computers.

2.

Right-click UserAccount, and then click Properties.

3.

Click the Account tab.

clip_image012[1]

Figure 19   User Account Options

4.

In the Account options box, confirm that Account is sensitive and cannot be delegated is not selected.

 

Verify Name Resolution

Verify that name resolution is functioning correctly. Kerberos authentication requires that each computer is able to resolve the DNS name of the next computer it communicates with, whether that computer is located in the middle tier or on the back-end.

Verify, using ping, that you can resolve:

From the client, the FQDN of the middle tier server.

From the middle tier server(s), the FQDN of the back-end server(s).

Ping generally returns the FQDN of the server along with the IP address. Be sure that the client’s local Hosts file does not have the short name for the middle tier server or the back-end server.

If the client and server are in two different domains, use the FQDN of the server for the connection. If you use the NetBIOS name, then the client computer might resolve a local domain principal. This might cause the authentication attempt to fail because the client found the incorrect SPNs of the server on the local domain and presented it to the remote domain target.

You can verify the following issues from the command line using Net view.

To test the HOST/ServerName SPN and verify resolution to the correct NetBIOS SPN, from a command prompt, type:

net view \\NetBIOSName

  Note
If the name resolved is for a locally named principal SPN not the remote target required then authentication will fail. This is common when a stale or abandoned object exists for the local domain. Name resolution via NetBIOS and FQDN will resolve to the correct remote target, but the SPN lookup resolves to local principal.

To verify the HOST/FQDN SPN, which should be unique in the forest, from a command prompt, type:

net view \\FQDN

If Net view fails with NTLM, then authentication is probably not the issue. To test NTLM, from a command prompt, type:

net view \\IPAddress

For example, if you were resolving to a local domain principal with NetBIOS, Net view would give you the following results:

net view \\NetBIOSName would fail with access denied because the SPN lookup resolved to the wrong local principal and Kerberos authentication failed.

net view \\FQDN would complete successfully because the SPN lookup resolved to the correct remote principal and Kerberos authentication succeeded.

net view \\IPAddress would complete successfully because it is using NTLM.

 

Verify Application Configured for Kerberos Protocol

Verify that the client application supports Kerberos authentication.

  Note
Internet Explorer versions 5.5 and above support Kerberos authentication.

Verify that the client application is configured for the Kerberos protocol. This will vary based on the client application in use.

For examples, see Appendix B.

 

Verify Client Is Using Kerberos Authentication

To verify that the client is using Kerberos authentication to authenticate to the service, connect to the server using the client application under a domain user account. (Kerberos authentication works only with domain user accounts, not for local computer user accounts.)

Although you can connect successfully, the connection might have happened on NTLM. Therefore, verify that the Kerberos authentication package is being used by:

Checking the security log on the middle tier server for NTLM success audits. For more information about enabling audits and using the security log, see Security Event Log in Appendix A: Diagnostic Tools.

Using Kerberos Tray to purge the tickets before connecting to the server, and then observing the tickets to find a ticket to connect to the server. For more information, see Kerberos Tray in Appendix A: Diagnostic Tools.

Using Network Monitor to observe the traffic from the client to your domain controller on Kerberos port 88. If you have a Kerberos parser, you can easily view the traffic and find out the error message from the traffic. Furthermore, a large traffic flow from the domain controller to the client indicates a successful Kerberos connection. For more information, see Network Monitor in Appendix A: Diagnostic Tools.

For more information about troubleshooting Kerberos authentication using auditing, debug output, and network traces, see the Troubleshooting Kerberos Errors white paper at http://go.microsoft.com/fwlink/?LinkID=27176.

 

If the connection is established using the Kerberos protocol, then be sure that the user has permissions to access the server. If the user does not have permissions, you might receive errors such as User domain\UserName does not have permissions to view resource or Access Denied for domain\UserName.

If the connection established using:

Kerberos protocol, go to Checklist 3 — Middle Tier to continue diagnosing the problem.

NTLM, then two possible reasons could be:

1.

The system attempts authentication using the Kerberos protocol but returns an Account not in database error or related error message. As a result, the system attempts to authenticate using NTLM. Windows Server 2003, Windows 2000 use an algorithm called Negotiate (SPNEGO) XP, and Windows to negotiate which authentication protocol is used. Although the Kerberos protocol is the default, if the default fails, Negotiate will try NTLM. For more information about troubleshooting Kerberos errors, see the Troubleshooting Kerberos Errors white paper at http://go.microsoft.com/fwlink/?LinkID=27176.

2.

A call to Negotiate returns NTLM as the only protocol available.

If you find that NTLM authentication is still being used, or that Kerberos authentication is not being attempted in a situation where Kerberos authentication should be used, contact Product Support Services for help in diagnosing the problem.

 

Checklist 3 — Middle Tier

If a middle tier service is using NTLM to authenticate to the next service, you typically receive errors such as:

Logon failed for null user

Logon failed for NT AUTHORITY\ANONYMOUS user

If you have verified that each computer uses the Kerberos protocol, a likely cause of the authentication problem is that the middle tier services are not properly configured for delegation. In this case, you typically receive errors such as:

Logon failed for UserName

Middle Tier: Services Configured to Impersonate User

Task

Process

Date Completed/By Whom

Verify that the middle tier services and servers support the Kerberos protocol.

 

 

From a command prompt:

Verify that SPNs are registered for middle tier services.

1.

At a command prompt, type:

setspn –L Account 

where Account is the name of the account under which the service is running.

2.

Verify that these two SPNs for the service account are present:

One for ServiceClass/Host:Port

One for ServiceClass/FQDN

For more detailed instructions, see Verify SPNs for Middle Tier.

For examples, see Appendix B.

 

From Active Directory Users and Computers:

Verify that delegation is configured for middle tier services. (Note: If you are completing the checklists in sequence, you completed this task in the Active Directory checklist.)

If middle tier service is using the computer account:

Right-click the computer account and then click Properties.

If the account is in a Windows 2000 functional level domain, verify that the Account is trusted for delegation option is selected.

If the account is in a Windows Server 2003 functional level domain, configure options on theDelegation tab.

If middle tier service is using a domain user account:

Right-click the service account, and then click Properties.

If the service account is in a Windows 2000 functional level domain, verify that the Account is trusted for delegationoption on the Account tab is selected.

If the service  account is in a Windows Server 2003 functional level domain, configure options on the Delegation tab.

For more detailed instructions, see Verify Delegation for Middle Tier Service Accounts.

For examples, see Appendix B.

 

From Domain Security Policy Group Policy (completed if Active Directory Checklist completed) or Local Security Policy:

Verify that middle tier services have either of these two privileges:

Act as part of the operating system

Impersonate a client after authentication

Click Local Policies, and then clickUser Rights Assignment.

For more detailed instructions, see Verify Middle Tier Service Privileges.

 

Verify that the user is authorized to access the required resources on the middle tier server.

 

 

Verify middle tier service is configured for impersonation.

For examples, see Appendix B.

 

Verify that the middle tier service impersonates the user before connecting to the next server.

For more information, see Verify Middle Tier Service Impersonates User.

 

clip_image019

Figure 20   Middle Tier Services Support Kerberos Protocol

Verify Middle Tier Supports Kerberos Protocol

Verify that the each middle tier service or server supports the Kerberos protocol.

Verify SPNs for Middle Tier

Verify that an SPN is registered for each middle tier service account. (Note: If you are completing all the checklists in sequence, then you completed this task in the Active Directory checklist.)

If the middle tier service is running as the Local System or the network service, you do not need to set any SPNs manually. Consequently, you do not need to verify that SPNs have been set correctly because every SPN will have been automatically set.

Verify that SPNs have been set for service accounts

At a command prompt, type:

 setspn –L Account

where Account is the name of the service account.

There should be at least two SPNs listed, because the following two SPNs for the service account must be present for delegation to properly function:

ServiceClass/Host:Port, where ServiceClass is the appropriate service class, Host is the name of the host computer, and Port is the port the service is running on.

ServiceClass/FQDN, where FQDN is the fully qualified domain name of the host computer.

Resolution

If there are no SPNs listed or if there is an SPN missing, then add the appropriate SPN using the setspn –A command.

If there are duplicate SPNs listed, then rename or delete the duplicate SPNs using the Setspn utility. You can use Ldifde to query the global catalog to ensure there are no duplicate SPNs.

For examples of common scenarios, see Appendix B.

Verify Domain Functional Level

If you are configuring constrained delegation, you need to verify that the domain controller is operating at Windows Server 2003 functional level. (This step is required only for constrained delegation.)

Note: If you are completing all the checklists in sequence, then you completed this task in the Active Directory checklist.

clip_image011[1]

Figure 21   Windows Server 2003 Domain Functional Level

  Important
Windows 2000 does not support constrained delegation. Because unconstrained delegation will diminish security, avoid using delegation in Windows 2000 environments

 

To verify the functional level of your domain controller

1.

Open Active Directory Users and Computers.

2.

Right-click DomainName, and then click Properties.

3.

Verify that Windows Server 2003 is listed under Domain functional level.

 

Verify Delegation for Middle Tier Service Accounts

Note: If you are completing all the checklists in sequence, then you completed this task in the Active Directory checklist.

Verify that each middle tier service account in the scenario is trusted for delegation. If the middle tier service account is not trusted for delegation, then you will receive errors such as:

Logon failed for null user

Logon failed for NT AUTHORITY\ANONYMOUS user

Even though the Kerberos protocol can be used between the client and middle tier service and between the middle tier service and the back-end service, if the middle tier service is not trusted for delegation, then middle tier service will not have a client’s TGT. Thus, the authentication falls back to NTLM. Because the middle tier service does not have network credentials (that is, the user’s password) it goes out as null user.

For examples, see Appendix B.

If the service runs under the computer account

If the service runs under the computer account, then you will need to configure the computer account of the server for delegation.

 

To verify that the middle tier server computer account is trusted for delegation

1.

Open Active Directory Users and Computers.

2.

Find the computer account for the middle tier server.

3.

Right-click the account, and then click Properties.

If the computer account is in a Windows 2000 functional level domain, the Trust computer for delegation option on the Generaltab should be selected. (See Figure 22.)

clip_image013[1]

Figure 22   Functional Level Windows 2000 Domain Computer Account Trusted for Delegation

 

If the computer account is in a Windows Server 2003 functional level domain, click the Delegation tab.

clip_image014[1]

Figure 23   Windows Server 2003 Functional Level Domain Computer Account Not Trusted for Delegation

 

On the Delegation tab, if Do not trust this computer for delegation is selected, then select one of the two Trust options:

1.

To configure the account to use unconstrained delegation, select Trust this computer for delegation to any service (Kerberos only). This option is not recommended.

2.

To configure the account to use constrained delegation, select Trust this computer for delegation to specified services only. Configure protocol transition by selecting one of the following two options:

To configure the account to use constrained delegation without protocol transition, select Use Kerberos Only.

To configure the account to use constrained delegation with protocol transition, select Use any authentication protocol.

  Note
When using constrained delegation, confirm that the appropriate SPNs are in the Services to which this account can present delegated credentials list. These should be the SPNs of back-end services. Recall that an SPN itself consists of three pieces of information, ServiceClass/Host:Port, where:

ServiceClass is the service class of the SPN.

Host is the computer to which the SPN belongs.

Port is the port that the service the SPN is registered to runs on.

Service runs under a domain user account

If the service runs under a domain user account, then you will need to configure the service account for delegation.

 

To verify that the middle tier service account is trusted for delegation

1.

Open Active Directory Users and Computers.

2.

Locate the service account you are configuring, right-click the account, and then click Properties.

If you are configuring an account in a Windows 2000 functional level domain, click the Account tab.

clip_image015[1]

Figure 24   Service Account Trusted for Delegation

In the Account options box, confirm that Account is trusted for delegation is selected.

If the service account is in a Windows Server 2003 functional level domain, click the Delegation tab.

clip_image016[1]

Figure 25   Service Account Without Protocol Transition

 

On the Delegation tab, select one of the two Trust options:

1.

To configure the account to use unconstrained delegation, select Trust this user for delegation to any service (Kerberos only). This option is not recommended.

2.

To configure the account to use constrained delegation, select Trust this user for delegation to specified services only. Configure protocol transition by selecting one of the following two options:

To configure the account to use constrained delegation without protocol transition, select Use Kerberos Only. (See Figure 25.)

To configure the account to use constrained delegation with protocol transition, select Use any authentication protocol.

  Note
When using constrained delegation, confirm that the appropriate SPNs are in the Services to which this account can present delegated credentials list. These should be the SPNs of the back-end services. Recall that an SPN itself consists of three pieces of information, ServiceClass/Host:Port, where:

ServiceClass is the service class of the SPN.

Host is the computer to which the SPN belongs.

Port is the port that the service the SPN is registered to runs on.

 

Verify Middle Tier Service Privileges

Note: If you configure using domain security policy, the procedure is covered in Checklist 1 — Active Directory.

Because the ability to act as another user is a primary component of delegation, a process cannot delegate if it does not possess the necessary privilege. Therefore, verify that each middle tier service in the delegation scenario has either of these two privileges:

Act as part of the operating system (available in Windows 2000 or Windows Server 2003)

Impersonate a client after authentication (added in Windows Server 2003)

Both of these privileges give an account the ability to act as another user. The Impersonate a client after authentication privilege is similar to the Act as part of the operating system privilege except that it is not as far-reaching. That is, it will only allow a process to impersonate after authentication, whereas Act as part of the operating system privilege allows a process to impersonate before authentication.

If you are configuring these privileges with Group Policy, you need to verify at the domain controller that the policy is configured correctly.

The Local System account is assigned Act as part of the operating system privilege by default. Thus, if the middle tier service is running as Local System, you do not need to modify user right assignments in the security policy. For all other accounts, you will need to configure the Act as part of the operating system or the Impersonate a client after authentication privilege.

When protocol transition is being used, the middle tier service often does not have information about the identity of the incoming user — that is, the incoming user might have authenticated with a protocol that did not provide so complete a set of credentials as Kerberos authentication would have. Therefore, you will need to assign the Act as part of the operating system privilege to those middle tier services.

For example, although a middle tier service that is running IIS might grant the incoming user the permission to view a Web page, it has not formally authenticated the user. Therefore, the middle tier service that is running IIS must have the Act as part of the operating system privilege in order to impersonate this user when it requests either a Web service or a back-end server.

Thus, you should configure the first middle tier service for the Act as part of the operating system user right setting. However, because Impersonate a client after authentication is not as far-reaching, for any additional middle tier services that will be accessed after the initial authentication, you should assign Impersonate a client after authentication (if using Windows Server 2003).

To verify that the service accounts have appropriate privileges

1.

Open local security policy by clicking Start, Programs, Administrative Tools, and then Local Security Policy.

  Note
Follow the instructions in step 1 if policy is not enforced by the domain controller. If the policy is enforced by the domain controller, then you must open the domain security policy or Group Policy instead.

2.

Click Local Policies, and then click User Rights Assignment.

For example, Figure 26 shows that Administrators and SERVICE have Impersonate a client after authentication configured.

clip_image020

Figure 26   User Rights Assignment in Local Security Settings

 

To set Impersonate a client after authentication on the service account

1.

Open the domain security policy by clicking Start, Programs, Administrative Tools, and then Local Security Policy.

  Note
Follow the instructions in step 1 if policy is not enforced by the domain controller. If the policy is enforced by the domain controller, then you must open the domain security policy or Group Policy instead.

2.

Click Local Policies, then User Rights Assignment, and then click Impersonate a client after authentication.

3.

Add any accounts that will need to delegate credentials (such as the IIS account).

 

Verify User Authorization

Verify that the user is authorized to access the required resources on the middle tier server.

 

Verify Middle Tier Service Configuration

Verify that each middle tier service in the scenario is configured for impersonation. Depending on the service, there might be settings or metadata that you must configure in order for the middle tier service to use the Kerberos protocol.

  Note
IIS can be configured to use both Negotiate and NTLM. For more information, see “HOW TO: Configure IIS to Support Both Kerberos and NTLM Authentication” in the Microsoft Knowledge Base at
 http://go.microsoft.com/fwlink/?LinkId=24925.

For examples, see Appendix B.

 

Verify Middle Tier Service Impersonates User

Verify that the middle tier service impersonates the user before connecting to the next service. For example, an ASP.NET application or a COM+ application can run under domain\UserName instead of impersonating the actual user and can connect to the back-end server underdomain\UserName. This can result in errors such as:

Logon failed for domain\UserName 

Access denied for domain\UserName.

 

Checklist 4 — Back-end

 

Back-end: Services Configured for Kerberos Authentication

Task

Process

Date Completed/By Whom

From a command prompt:

Verify that the SPN is registered for the service account of the back-end service. (Note: If you are completing the checklists in sequence, you completed this task in the Active Directory checklist.)

1.

At a command prompt, type:

setspn –L Account

where Account is the name of the account under which the service is running.

2.

Verify that the following two SPNs for the service account are present:

One for ServiceClass/Host: Port

One for ServiceClass/FQDN

For more detailed instructions, see Verify SPNs for Back-end Service Accounts.

For examples, see Appendix B.

 

Verify that the user is authorized to access the required resources on the back-end server.

 

 

clip_image021

Figure 27   Back-end Server

 

Verify SPNs for Back-end Service Accounts

Verify that an SPN is registered for each back-end service account in the scenario. (If you are using the checklists in sequence, you completed this task in the Active Directory checklist.)

If the back-end service is running as the Local System or the network service, you do not need to set any SPNs manually. Consequently, you do not need to verify that SPNs have been set correctly because every SPN will have been automatically set.

Verify that an SPN has been set for the service account

At a command prompt, type:

setspn –L Account

where Account is the name of the account under which the back-end service is running.

Verify that two SPNs for the back-end service account that are required for delegation to properly function are present:

One for ServiceClass/Host:Port, where ServiceClass is the appropriate service class, Host is the name of the host computer, and Port is the port the service is running on.

One for ServiceClass/FQDN, where FQDN is the fully qualified domain name of the host computer.

Resolution

If there are no SPNs listed or if there is an SPN missing, then add the appropriate SPN using the setspn –A command. The above two SPNs are needed for the middle tier service to properly use delegated credentials with the back-end service.

If there are duplicate SPNs listed, then use the Setspn utility to rename or delete the duplicate SPNs. You can use Ldifde to query the global catalog to ensure there are no duplicate SPNs.

For examples, see Appendix B.

Verify that the user is authorized to access the back-end server’s resources

For example, with SQL Server, be sure the user is authorized to access the SQL database. If the user is not authorized, you might receive errors such as:

Logon failed for UserName

Access denied for UserName

  Note
The back-end service account does not need to have delegation set up because it will not be authenticating or delegating credentials to any other service.

 

 

Summary

This white paper discusses various methods to troubleshoot Kerberos delegation issues. The previous sections detail commonly made mistakes in setting up these scenarios and how to resolve them.

Because a very common use of Kerberos delegation is a delegation scenario with IIS and SQL, Appendix B explains the IIS/SQL delegation scenario in more detail.

 

 

Appendix A: Diagnostic Tools

Some tools that you use to diagnose Kerberos errors — for example, Event Viewer and Network Monitor — are the same you would use for other network-related or authentication issues. More specific tools — such as Kerberos List and Kerberos Tray — can be used for detailed Kerberos-specific information. Information about troubleshooting tools is provided in this section.

 

Event Viewer

Event Viewer is included in Windows Server 2003, Windows 2000. The system log XP, and Windows and the security log will contain Kerberos error codes and other events related to authentication. For more information about troubleshooting with Event Viewer, see “HOW TO: Diagnose System Problems with Event Viewer in Windows Server 2003” in the Microsoft Knowledge Base at http://go.microsoft.com/fwlink/?LinkId=23046.

 

Security Event Log

The security event log contains information that can explain whether Kerberos authentication was at fault or if perhaps some other authentication protocol was responsible. The details of a specific logon/logoff event for a user will show what authentication protocol was used.

Although Kerberos authentication is preferred, the system might revert to NTLM if errors or failures occur. This reversion can cause further problems, because the user will not have obtained any Kerberos tickets and might not be able to access Kerberos-aware services or might not have the functionality of single sign-on across the entire network.

 

NTLM or Kerberos Protocol

How do you know if you are logging on with NTLM or Kerberos protocol? All account logons that occur from computers running Windows Server 2000 should occur using the Kerberos 2003 or Windows protocol (or Negotiate, which could imply that the Kerberos protocol was used). To catch these events, you need to enable auditing of successful account logon events for user authentication and logon events for computer authentication.

The Logon Type field might help determine which event is applicable by type of logon attempted. Possible values in the Logon Type field are listed in Table 2.

 

Table 2   Logon Type

2

Interactive (interactively logged on)

3

Network (accessed system via network)

4

Batch (started as a batch job)

5

Service (a Windows service started by service controller)

6

Proxy (proxy logon; not used in Windows 2000) NT or Windows

7

Unlock (unlock workstation)

8

NetworkCleartext (network logon with plaintext credentials)

9

NewCredentials (used by RunAs when the /netonly option is used)

If the security log shows that NTLM was used and there are authentication-related issues present, you will need to investigate by using some of the tools outlined in this section.

Enabling failure audits

By default, Windows Server 2003 will only log success audits. Often, the default might hinder your finding authentication problems because many failed authentication attempts do not even show up in the log. Enabling failure audits will show if any authentications are failing, and thus might provide additional information about the source of the error.

 

To enable failure audits

1.

Open local security policy by clicking Start, Programs, Administrative Tools, and then Local Security Policy.

  Note
This procedure assumes that Audit policy is not enforced by the domain controller. If it is, then you must open domain security policy or applicable Group Policy on the domain controller.

2.

Click Local Policies, and then Audit Policy.

3.

Right-click Audit account logon events.

4.

Select Define these policy settings.

5.

Under Audit these attempts: be sure that both Success and Failure are selected.

6.

Click OK.

7.

Repeat steps 3-6 for Audit logon events to record both success and failures.

8.

If the change was made in domain security policy on the domain controller, at a command prompt, run gpupdate /force on the client computers to propagate the policy change.

 

Klist.exe: Kerberos List

Kerberos List is a command-line tool that you can use to view and delete Kerberos tickets granted to the current logon session. To use Kerberos List to view tickets, you must run the tool on a computer that is a member of a Kerberos realm.

When Kerberos List is run from a client, it shows the:

Ticket-granting ticket (TGT) to a Kerberos Key Distribution Center (KDC) in Windows.

Ticket-granting ticket (TGT) to Ksserver on UNIX.

 

How to install Kerberos List

Kerberos List is supported for Windows Server 2003, Windows 2000. XP, and Windows

You can download Klist.exe and other “Windows Server 2003 Resource Kit Tools” from the Microsoft Download Center athttp://go.microsoft.com/fwlink/?LinkID=16544.

 

How to Use Kerberos List

Kerberos List is a command-line tool that uses the following syntax:

klist [tickets |     tgt | purge] [-?]

To run Kerberos List:

1.

Click Start, click All Programs, click Accessories, and then click Command Prompt.

2.

In the command prompt window, type:

klist.exe parameter 

and then press ENTER.

 

Kerberos List Parameters

 
Tickets

Lists the current cached tickets of services to which you have authenticated since logging on. Tickets can be used to verify that a Kerberos ticket has been issued to the user. After an authentication request, several tickets should appear. This command will also show detailed information about the tickets obtained including the servers for which they were issued, the validity period, and ticket options.

Tickets display the following attributes of all cached tickets:

Option

Description

End Time

Time at which the ticket becomes invalid. After a ticket is past this time, it cannot be used to authenticate to a service.

KerbTicket Encryption Type

Encryption type used to encrypt the Kerberos ticket.

Renew Time

Maximum lifetime of a renewable ticket (see TicketFlags in the following table). To continue using this ticket, you must renew it before reaching the established End Time and before the expiration date established in RenewUntil.

Server

Server and domain for the ticket.

tgt

Lists the initial Kerberos ticket-granting ticket (TGT). Tgt displays the following attributes of the currently cached ticket:

Option

Description

AltTargetDomainName

Name supplied to InitializeSecurityContext that generated this ticket, typically an SPN.

DomainName

Domain name of the service.

End Time

Time when the ticket becomes invalid. When a ticket is past the end time, it cannot be used to authenticate to a service.

FullServiceName

Canonical name of the account principal for the service.

KeyExpirationTime

Expiration time from the KDC reply.

RenewUntil

Maximum lifetime of a renewable ticket (see TicketFlags). To continue using a ticket, you must renew it. Tickets must be renewed before the expiration time set in End Time and in RenewUntil.

ServiceName

A TGT is a ticket for the Key Distribution Center (KDC) service. The service name for a TGT is krbtgt.

StartTime

Time when the ticket becomes valid.

TargetDomainName

For a cross-realm ticket, this is the realm, rather than the issuing  realm, in which the ticket is valid.

TargetName

Service name for which the ticket was requested. This is the name of a servicePrincipalNameproperty on an account in the directory.

TicketFlags

Kerberos ticket flags set on the current ticket in hexadecimal. Kerberos Tray displays these flags on the Flags tab.

TimeSkew

The reported time difference between the client computer and the server computer for a ticket.

purge

Deletes all Kerberos tickets held by the user. Purge destroys all tickets that you have cached, so use this with caution. It might stop you from being able to authenticate to resources. If this happens you must log off, and then log on again.

-?

Displays command-line help.

Kerbtray.exe: Kerberos Tray

Kerberos Tray is a graphical user interface tool that displays ticket information for a computer running Microsoft’s implementation of the Kerberos version 5 authentication protocol. Kerberos Tray is supported for Windows Server 2003, Windows XP, and Windows 2000.

You can view and purge the ticket cache by using the Kerberos Tray tool icon located in the notification area of the desktop. By positioning the cursor over the icon, you can view the time left until the initial ticket-granting ticket (TGT) expires. The icon also changes in the hour before the Local Security Authority (LSA) renews the ticket.

How to install Kerberos Tray

Kerberos Tray is included in the Windows Server 2003 Resource Kit and the Windows 2000 Resource Kit.

You can download Kerbtray.exe and other “Windows Server 2003 Resource Kit Tools” from the Microsoft Download Center athttp://go.microsoft.com/fwlink/?LinkID=16544.

How to use Kerberos Tray

1.

To run Kerberos Tray, double-click the Kerbtray file. The Kerbtray icon appears in the notification area.

2.

To open the main Kerbtray window after Kerberos Tray is running, double-click its icon in the notification area. Information about all the tickets for the current user will be displayed. Ticket options for each ticket are displayed on the Flags tab.

3.

To purge tickets, right-click the Kerbtray icon in the notification area and click Purge Tickets.

Ldifde

You can use Ldifde to create, modify, and delete directory objects on computers running Windows Server 2003 or Windows XP Professional. You can also use Ldifde to extend the schema, export Active Directory user and group information to other applications or services, and populate Active Directory with data from other directory services.

Ldifde.exe is present on domain controllers but can be copied and used on client computers running Windows XP and Windows Server 2003.

Ldifde provides a method to quickly extract and display certain SPNs in a forest or domain. This is useful when:

There are multiple objects in the forest with the same HOST/NetBIOSname SPN that might be causing Kerberos authentication failures.

There are multiple (thus, invalid) MSSQL SPNs registered on accounts.

Syntax

ldifde [-i] [-f FileName] [-s ServerName] [-c String1 String2] [-v] [-j Path] [-t PortNumber] [-d BaseDN] [-r LDAPFilter] [-p Scope] [-l LDAPAttributeList] [-o LDAPAttributeList] [-g] [-m] [-n] [-k] [-a UserDistinguishedName Password] [-b UserName Domain Password] [-?]

Parameters

-i

Specifies import mode. If not specified, the default mode is export.

-f FileName

Identifies the import or export file name.

-s ServerName

Specifies the domain controller to perform the import or export operation. By default, Ldifde will run on the domain controller on which Ldifde is installed.

-c String1 String2

Replaces all occurrences of String1 with String2. This is generally used when importing data from one domain to another and the distinguished name of the export domain (String1) needs to be replaced with that of the import domain (String2).

-v

Sets verbose mode.

-j Path

Sets the log file location. The default is the current path.

-t PortNumber

Specifies an LDAP port number. The default LDAP port is 389. The global catalog port is 3268.

-d BaseDN

Sets the distinguished name of the search base for data export.

-r LDAPFilter

Creates an LDAP search filter for data export. For example, to export all users with a particular surname, you can use the following filter:

-r (and(objectClass=User)(sn=Surname))

-p Scope

Sets the search scope. Search scope options are Base, OneLevel, or SubTree.

-l LDAPAttributeList

Sets the list of attributes to return in the results of an export query. If this parameter is omitted, all attributes are returned.

-o LDAPAttributeList

Sets the list of attributes to omit from the results of an export query. This is typically used when exporting objects from Active Directory and then importing them into another LDAP-compliant directory. If attributes are not supported by another directory, you can omit the attributes from the result set using this option.

-g

Omits paged searches.

-m

Omits attributes that only apply to Active Directory objects. (For example, the Object-Guid, Object-Sid, Pwd-Last-Set and SAM-Account-Type attributes.)

-n

Omits export of binary values.

-k

Ignores errors during the import operation and continues processing. The following is a complete list of ignored errors:

Object is already a member of the group

Object class violation (meaning the specified object class does not exist), if the object being imported has no other attributes

Object already exists

Constraint violation

Attribute or value already exists

No such object

-a UserDistinguishedName Password

Sets the command to run using the supplied UserDistinguishedName and Password. By default, the command will run using the credentials of the user currently logged on to the network.

-b UserName Domain Password

Sets the command to run using the supplied UserName Domain Password. By default, the command will run using the credentials of the user currently logged on to the network.

-?

Displays the command menu.

Example

SQL Server was initially installed using the computer account to start the service (thus getting the needed SPNs). At a later date, a domain account was configured to start the service and now you have authentication problems. This could be because of having the MSSQL SPN registered on multiple objects. The following command will generate a list of objects that have MSSQL SPNs registered in the forest:

LDIFDE –f filename.txt –t 3268 –d “DC=forest,DC=Root,DC=com –l serviceprincipalname –r ”(serviceprincipalname=MSSQLSvc/*)” –p subtree

In this example, the parameters behave as follows:

-f filename.txt

Writes output to specified file.

-t 3268

Optional, specifies global catalog port.

-d “DC=forest,DC=Root,DC=com

Uses the desired forest or domain distinguished name for the search starting point.

-l serviceprincipalname

Limits the output to Service Principal Name.

-r ”(serviceprincipalname=MSSQLSvc/*)”

Specifies the SQL service as the SPN to find.

-p subtree

Sets the search scope to subtree.

Network Monitor

You can use the Network Monitor utility to obtain more detailed information than event logs might provide by capturing a network trace and then inspecting the actual Kerberos packets being sent across the network.

  Note
For complete information about Network Monitor, see “Network Monitor” on Microsoft TechNet at
 http://go.microsoft.com/fwlink/?LinkId=23049. For best practices and procedures associated with Network Monitor, please see “Checklist: Monitoring network traffic on your local computer” on Microsoft TechNet at http://go.microsoft.com/fwlink/?linkid=23047.

The full version of Network Monitor is included with Microsoft Systems Management Server (SMS). A limited version of the tool is included with Windows 2000, Windows XP, and the Windows Server 2003 family. It is also available from Microsoft Product Support Services.

How to install Network Monitor on Windows Server 2003

1.

Open the Windows Components Wizard.

2.

In the Windows Components Wizard, click Management and Monitoring Tools, and then click Details.

3.

In Subcomponents of Management and Monitoring Tools, select the Network Monitor Tools check box, and then click OK.

4.

If you are prompted for additional files, insert the installation CD for your operating system, or type a path to the location of the files on the network.

  Notes

To perform this procedure, you must be a member of the Administrators group on the local computer, or you must have been delegated the appropriate authority. If the computer is joined to a domain, members of the Domain Admins group might be able to perform this procedure.

To open the Windows Components Wizard, click Start, click Control Panel, click Add or Remove Programs, and then clickAdd/Remove Windows Components.

Certain Windows components require configuration before they can be used. If you installed one or more of these components but did not configure them, when you click Add/Remove Windows Components, a list of components that need to be configured is displayed. To start the Windows Components Wizard, click Components.

This procedure automatically installs the Network Monitor driver.

 

How to install Network Monitor on Windows XP

 

Network Monitor is included with the Windows XP Support Tools.

1.

Insert the Windows XP CD-ROM in the drive.

2.

Double-click My Computer, right-click the CD-ROM drive, and then click Explore.

3.

Go to Support\Tools, and then double-click Setup.exe.

4.

When the Windows Support Wizard starts, click Next.

5.

Click I agree on the End User License Agreement.

6.

Type your name and organization, and then click Next.

7.

Click either the Typical or Complete installation type, and then click Next.

8.

Verify the installation location, and then click Install.

 

How to Install Network Monitor on Windows 2000

1.

Click Start, point to Settings, and then click Control Panel.

2.

Double-click Add or Remove Programs.

3.

Click Add/Remove Windows Components.

4.

Click Management and Monitoring Tools, and then click Details.

5.

Click to select the Network Monitor Tools check box, and then click OK.

6.

Click Next.

  Important
Network monitoring on Windows XP is done with the Netcap.exe tool. This tool only allows the capture of network traffic. The capture cannot be viewed with the same tool. You must use the full version 2000 or the Windows Server of Network Monitor on Windows 2003 family to view the captured data.

 

How to capture network traffic with Windows XP

If you are using the version of Netcap.exe provided in the Windows XP Support Tools, use the following procedure:

1.

Click Start, click All Programs, click Accessories, and then click Command Prompt.

2.

In the command prompt window, type:

Netcap.exe /c:path 

where path is the full path to the directory and file name where you want to store this network trace, and then press ENTER.

3.

After the error has been reproduced, type:

Netcap.exe /remove

and then press ENTER. This will stop the network capture.

The procedure for capturing network traffic with Windows  2000 The procedure for capturing network traffic with Windows and Windows Server 2003 is different than the Windows XP procedure. Use the following procedure on these operating systems:

 

How to capture network traffic with Windows and the Windows Server 2003 family

1.

Click Start, click Control Panel, click Performance and Maintenance, click Administrative Tools, and then double-clickNetwork Monitor.

2.

Click the Start button to begin capturing network traffic.

3.

Reproduce the error.

4.

Click the Stop button to stop capturing network traffic.

5.

In the capture statistics information on the right-hand side, verify that no packets were lost because of the buffer overflowing. If any packets were lost, increase the buffer size in the Buffer Settings dialog box on the Capture menu and perform the capture again.

For more information, see “To capture network frames” on Microsoft TechNet at http://go.microsoft.com/fwlink/?LinkId=23052.

 

How to filter Kerberos-specific network traffic

You can filter out packets from all protocols except the Kerberos protocol. To apply a filter to only show Kerberos protocol-related network traffic, perform the following steps in Network Monitor:

1.

Click Capture, and then click Display captured data.

2.

Click the Funnel button and then double-click Protocol == ANY.

3.

Click Disable all.

Select Kerberos from the list, and then click Enable. Click OK, and then click OK again. After you perform this procedure, the only packets that should appear are Kerberos packets.

 

If no packets appear after applying the filter

 

Possible causes are:

The Kerberos tickets have either already been issued or have been cached. You can use Kerberos List to show all the tickets currently issued on the computer. You can also use Kerberos List to purge all tickets.

The Kerberos authentication protocol is not even being attempted. The associated logon event in the security log should indicate which protocol was used to authenticate the user. If NTLM is listed, then Kerberos authentication was not even attempted. If NTLM fallback is occurring at logon or when requesting a network resource, the event logs might contain useful information. For more information, see the Troubleshooting Kerberos Errors white paper at http://go.microsoft.com/fwlink/?LinkID=27176.

The Network Monitor buffer overflowed. On high-traffic networks, this can be easily happen if the tool is configured with the default buffer size.

 

Analyzing the Captured Kerberos Traffic

After you have captured some Kerberos packets, the problem can be diagnosed by determining how the captured data differs from a successful authentication. In most cases, the diagnosis will involve following the packet exchange and looking for a KRB_ERROR packet somewhere in the captured data. However, in some cases, especially if everything appears normal, more in-depth analysis is required. Several examples of captured network data — demonstrating a successful logon and showing common failures — are provided in Appendix C. The captured data is annotated to help explain each frame’s overall impact on the success or failure of the authentication attempt.

For more information, see:

“How to View HTTP Data Frames Using Network Monitor” in the Microsoft Knowledge Base at http://go.microsoft.com/fwlink/?LinkId=23055.

“Frequently Asked Questions About Network Monitor” in the Microsoft Knowledge Base at http://go.microsoft.com/fwlink/?LinkId=23056.

 

Setspn

The Setspn utility sets SPNs. Because SPNs are security-sensitive, you can only set SPNs for user objects if you have domain administrator privileges.

 

How to install Setspn

The Setspn utility is included in the Windows Server 2003 Support Tools.

 

How to Use Setspn

To add an SPN, you can type the following at a command prompt:

setspn –A ServiceClass/Host:Port AccountName

To delete an SPN, you can type the following at a command prompt:

setspn –D ServiceClass/Host:Port AccountName

To view the SPNs that are registered for an account, you can type the following at a command prompt:

setspn –L AccountName

To reset the default SPN registrations for the host names for an account, you can type the following at a command prompt:

setspn –R AccountName

The following section discusses the parameters listed above.

ServiceClass. There are many different types of SPNs, and each service that is running on a computer should have the appropriate SPN service class assigned to it. If an application is written to take advantage of Kerberos authentication and delegation, it has the specific type of SPN that it needs to access pre-determined.

For example, when Internet Explorer versions 5.5 and later use the Kerberos protocol to authenticate to a Web service, the application looks for the HTTP SPN. On the other hand, a SQL Server client looks for the MSSQLSvc/ SPN. If the wrong service class is used on an SPN, then the SPN will not be located when a service searches for it.

Host. The computer to which the SPN belongs is all the names by which a computer on which the service is running can be referenced. This usually includes a NetBIOS name, a fully qualified domain name (FQDN), and any aliases that might have been assigned to this computer. A separate SPN will need to be set for each name by which the computer can be referenced, with the Host parameter changing respectively.

Port. The port that the service is running on. If this is a default port for that service (such as 80 for HTTP), then it can be omitted. However, it is recommended the port be included regardless of what service is running.

AccountName. The name of the domain account under which the service runs. If the service runs as Local System or the network service, you usually do not need to set an SPN explicitly for the service because most common SPN service classes will automatically be mapped to the HOST/ SPN which is in turn automatically generated for each computer account.

 

 

Appendix B: Configuration Examples for Common Scenarios

 

Internet Explorer to IIS to SQL Server

clip_image022

Figure 28   Internet Explorer to IIS to SQL Server

 

Internet Explorer 6

Verify that the client application is configured for the Kerberos protocol

This will vary based on the client application in use. For Internet Explorer 6, you must be sure that Integrated Windows authentication is configured and that the site is in the Local intranet zone.

 

To configure Integrated Windows authentication

1.

In Internet Explorer on the Tools menu, click Internet Options, and then click the Advanced tab.

2.

In the Security list box, select the Enable Integrated Windows Authentication (requires restart) check box, and then click OK.

3.

Restart Internet Explorer.

For information about this issue, see “Unable to Negotiate Kerberos Authentication After Upgrading to Internet Explorer 6” in the Microsoft Knowledge Base at http://go.microsoft.com/fwlink/?LinkId=23045.

Verify that the website is in the Local intranet zone

If Internet Explorer is attempting to access a site located in the Internet zone, the Kerberos protocol will not be used. Internet zone sites are prevented from using Integrated Windows authentication because these protocols will not typically work through Web proxies, among other reasons. If a site is located in the Internet zone, Internet Explorer will not attempt to use Kerberos authentication, and will automatically try NTLM. In all versions of Internet Explorer, when accessing a website to which you want to use Kerberos authentication, you must verify that the website appears as being in the Local intranet zone.

  Note
An icon in the lower right-hand corner of the Internet Explorer window will indicate what zone a website is in. It will display “Internet” for the Internet zone and “Local intranet” for the intranet zone. If the website appears as being in the Internet zone, you must manually add the site to the Local intranet sites list.

 

To add a site to the Local intranet sites list

1.

In Internet Explorer, click Tools, and then click Internet Options.

2.

Click the Security tab, then click Local intranet, then click Sites, and then click Advanced.

3.

In the Add this Web site to the zone: text box, type the name of the website you want to authenticate to with Kerberos authentication, and then click Add.

4.

Click OK.

For information about automating procedures that add Local intranet sites, see the following topics in the “Managing Internet Explorer Enhanced Security Configuration” white paper on Microsoft TechNet at http://go.microsoft.com/fwlink/?LinkId=26091.

“Using Group Policy to Add Sites to or Remove Sites from Security Zones”

“Using Internet Explorer Maintenance to Enforce Trusted Sites and Security Settings”

IIS

Verify that an SPN has been set for the service that runs IIS

At a command prompt, type:

setspn –L Account 

where Account is the name of the account under which the server that runs IIS is running.

These two SPNs for the IIS account must be present for delegation to properly function:

One for HTTP/Host, where Host is the name of the host computer.

One for HTTP/FQDN, where FQDN is the fully qualified domain name of the host computer.

In most cases HOST/Host and HOST/FQDN will be automatically used for IIS. If IIS is running as the Local System or the network service, you will not need to set any SPNs manually. Registering SPNs is typically required if the server running IIS has an alias for its host name.

Resolution

If there are no HTTP SPNs listed or if there is an SPN missing, then add the appropriate SPN using the setspn –A command. These SPNs are necessary for Internet Explorer to properly authenticate to the Web server.

If there are duplicate SPNs listed, then use the Setspn utility to rename or delete the duplicate SPNs. You can use Ldifde to query the global catalog to ensure there are no duplicate SPNs.

Verify that delegation is configured for the IIS account

Typically, IIS runs under the Local System or the network service account.

 

To verify that the IIS account is trusted for delegation

1.

Open Active Directory Users and Computers.

2.

Find the service account for IIS.

3.

Right-click the account and then click Properties.

If IIS is using an account in a Windows 2000 functional level domain, the Trust computer for delegation option on the Generaltab should be selected. (See Figure 29.)

clip_image013[2]

Figure 29   Functional Level Windows 2000 Domain Computer Account Trusted for Delegation

If IIS is using an account in a Windows 2000 functional level domain, click the Account tab. In the Account options box, confirm that the Account is trusted for delegation option is selected. (See Figure 30.)

clip_image023

 

Figure 30   Service Account Trusted for Delegation

If the IIS account is in a Windows Server 2003 functional level domain, click the Delegation tab.

clip_image016[2]

Figure 31   Windows Server 2003 Functional Level Domain User Account Using Constrained Delegation

 

On the Delegation tab, select one of the two Trust options:

1.

To configure the account to use unconstrained delegation, select Trust this user for delegation to any service (Kerberos only). This option is not recommended.

2.

To configure the account to use constrained delegation, select Trust this user for delegation to specified services only. Configure protocol transition by selecting one of the following two options:

To configure the account to use constrained delegation without protocol transition, select Use Kerberos Only.

To configure the account to use constrained delegation with protocol transition, select Use any authentication protocol.

  Note
When using constrained delegation, confirm that the appropriate SPNs are in the Services to which this account can present delegated credentials list. This should be the SPN of SQL Service. Recall that an SPN itself consists of three pieces of information, ServiceClass/Host:Port, where in this case:

MSSQLSvc is the service class for SQL Server.

SQLServer is the host name for the computer.

1433 is the port that the SQL Server runs on.

 
Verify middle tier service is configured for impersonation

When running SQL 2000, you must be using MDAC 2.6 or higher on the IIS server.

In the example where the middle tier is IIS, the website must have only the Integrated Windows authentication option enabled. This ensures that the Kerberos protocol will be used instead of other protocols.

 

To configure directory security for a website to Integrated Windows authentication only

1.

Open IIS Manager.

2.

Click the name of the computer that is running IIS, and then click Web Sites.

3.

Right-click the name of the website, and then click Properties.

4.

Click the Directory Security tab, and then under Authentication and access control click Edit....

5.

Verify that Integrated Windows authentication is the only check box selected by:

Clearing Enable anonymous access.

Selecting the Integrated Windows authentication check box.

Clearing each of the following check boxes:

Digest authentication for Windows domain servers

Basic authentication (password is sent in clear text)

.NET Passport authentication 

 

SQL Server

Verify that an SPN has been set for the SQL Server account

If SQL Server is running under a domain user account domain\sqlServiceAccount, then you will need to register an SPN for sqlServiceAccount, not for computername$. Failing to do so will result in logon failure.

At a command prompt, type:

setspn –L Account

where Account is the name of the account under which SQL Server is running.

For delegation to properly function, these two SPNs for the SQL service account must be present:

One for MSSQLSvc/Host:1433, where Host is the name of the host computer.

One for MSSQLSvc/FQDN:1433, where FQDN is the fully qualified domain name of the computer running SQL Server.

 

In SQL 2000, by default the SPN is registered if the SQL service account is running under Local System account or as a domain administrator.

Resolution

 

If there are no MSSQLSvc SPNs listed or there is an SPN missing, then you should add the appropriate SPN using the setspn –A command. These SPNs are needed for the Web server or Web service to properly authenticate and delegate credentials to the computer running SQL Server.

If there are duplicate SPNs listed, then use the Setspn utility to rename or delete the duplicate SPNs. You can use Ldifde to query the global catalog to ensure there are no duplicate SPNs.

 

Internet Explorer to IIS with ASP.NET Web Service to SQL Server

For more information about configuring ASP.NET applications for delegation, see “HOW TO: Configure an ASP.NET Application for a Delegation Scenario” in the Microsoft Knowledge Base at http://go.microsoft.com/fwlink/?LinkId=24926.

clip_image024

Figure 32   Internet Explorer-ASP.NET-SQL Server Delegation Scenario

 

Internet Explorer 6

 
Verify that the client application is configured for the Kerberos protocol

This will vary based on the client application in use. For Internet Explorer 6, you must ensure that Integrated Windows authentication is configured and that the site is in the Local intranet zone.

 

To configure Integrated Windows authentication

1.

In Internet Explorer on the Tools menu, click Internet Options, and then click the Advanced tab.

2.

In the Security list box, select the Enable Integrated Windows Authentication (requires restart) check box, and then click OK.

3.

Restart Internet Explorer.

 

For information about this issue, see “Unable to Negotiate Kerberos Authentication After Upgrading to Internet Explorer 6” in the Microsoft Knowledge Base at http://go.microsoft.com/fwlink/?LinkId=23045.

Verify that the website is in the Local intranet zone

If Internet Explorer is attempting to access a site located in the Internet zone, the Kerberos protocol will not be used. Internet zone sites are prevented from using Integrated Windows authentication because these protocols will not typically work through Web proxies, among other reasons. If a site is located in the Internet zone, Internet Explorer will not attempt to use Kerberos authentication, and will automatically try NTLM. In all versions of Internet Explorer, when accessing a website to which you want to use Kerberos authentication, you must verify that the website appears as being in the Local intranet zone.

 

  Note
An icon in the lower right-hand corner of the Internet Explorer window will indicate what zone a website is in. It will display “Internet” for the Internet zone and “Local intranet” for the intranet zone. If the website appears as being in the Internet zone, you must manually add the site to the Local intranet sites list.

 

To add a site to the Local intranet sites list

1.

In Internet Explorer, click Tools, and then click Internet Options.

2.

Click the Security tab, then click Local intranet, then click Sites, and then click Advanced.

3.

In the Add this Web site to the zone: text box, type the name of the website you want to authenticate to with Kerberos authentication, and then click Add.

4.

Click OK.

 

For information about automating procedures that add Local intranet sites, see the following topics in the “Managing Internet Explorer Enhanced Security Configuration” white paper on Microsoft TechNet at http://go.microsoft.com/fwlink/?LinkId=26091.

“Using Group Policy to Add Sites to or Remove Sites from Security Zones”

“Using Internet Explorer Maintenance to Enforce Trusted Sites and Security Settings”

 

IIS/Web Service

 

In the Internet Explorer to IIS to ASP.NET Web service to SQL Server scenario, you will need to register SPNs for the IIS account, the Web service account, and the SQL service account.

Verify that an SPN has been set for the IIS account

 

At a command prompt, type:

setspn –L Account