Share via

Integrated Windows Authentication

  • Article

Applies To: Windows Server 2003 with SP1

With Integrated Windows authentication (formerly called NTLM, and also known as Windows NT Challenge/Response authentication), the user name and password (credentials) are hashed before being sent across the network. When you enable Integrated Windows authentication, the client browser proves its knowledge of the password through a cryptographic exchange with your Web server, involving hashing.

Important

Integrated Windows authentication is disabled by default if you install Windows Server 2003 Service Pack 1 (SP1) as part of a slipstream installation of a Windows Server 2003 operating system. If you install Windows Server 2003 SP1 by itself, as an upgrade to a Windows Server 2003 operating system, the setting for Integrated Windows authentication is unchanged from its Windows Server 2003 setting. Integrated Windows authentication is enabled by default for Windows Server 2003 operating systems.

Integrated Windows authentication uses Kerberos v5 authentication and NTLM authentication. Kerberos is an industry-standard authentication protocol that is used to verify user or host identity. If Active Directory is installed on a domain controller running Windows 2000 Server or Windows Server 2003, and the client browser supports the Kerberos v5 authentication protocol, Kerberos v5 authentication is used; otherwise, NTLM authentication is used.

Integrated Windows authentication includes the Negotiate, Kerberos, and NTLM authentication methods. Negotiate, a wrapper for Kerberos v5 and NTLM, allows the client application to select the most appropriate security support provider for the situation. Kerberos v5 and NTLM have the following restrictions:

  • NTLM can get past a firewall, but is generally stopped by proxies because NTLM is connection-based, and proxies do not necessarily keep connections established.

  • Kerberos v5 requires that the client have a direct connection to Active Directory, which is generally not the case in Internet scenarios.

  • Kerberos v5 requires that both the client and the server have a trusted connection to a Key Distribution Center (KDC) and be Active Directory–compatible.

  • Kerberos v5 requires SPNs for multiple worker processes. If your Web site uses multiple worker processes, you can use Kerberos authentication, but you must manually register service names. For more information about Kerberos and service registration, see Kerberos and service registration later in this topic.

Integrated Windows authentication has the following limitations:

  • Integrated Windows authentication is supported by only Internet Explorer 2 and later.

  • Integrated Windows authentication does not work over HTTP proxy connections.

Therefore, Integrated Windows authentication is best suited for an intranet environment, where both user and Web server computers are in the same domain and where administrators can ensure that every user has Internet Explorer 2 or later.

Client Authentication Process

Unlike Basic authentication, Integrated Windows authentication does not initially prompt for a user name and password. The current Windows user information that is on the client is used for Integrated Windows authentication. If the authentication exchange initially fails to authorize the user, Internet Explorer prompts the user for a Windows account user name and password, which it processes using Integrated Windows authentication. Internet Explorer prompts the user for the correct user name and password up to three times. If, however, the user has logged on to the local computer as a domain user, then no authentication is required when the user accesses a network computer in that domain.

Note

Microsoft Internet Explorer versions 4.0 and later can be configured to initially prompt for user name and password. For more information, see Internet Explorer Help.

Kerberos and Service Registration

Kerberos is the default method of network authentication for services in Windows Server 2003. A service can use Kerberos only if that service first registers a service principal name (SPN) in Active Directory. By default, Active Directory registers the NetBIOS, or computer, name of the server, but if the SPN is different, you must manually register the service. Before Kerberos can authenticate a service, the service must be registered on only one account object. If the logon account name of a service instance changes, the service must be reregistered under the new account. Therefore, only one application pool that has the service registered can authenticate with Kerberos.

IIS uses the NTAuthenticationProviders Metabase Property to pass the Negotiate header when Integrated Windows authentication is used to authenticate client requests. The Negotiate header permits clients to choose either Kerberos or NTLM. Negotiate uses Kerberos, unless Kerberos cannot be used by one of the systems involved in the authentication, or unless the calling application does not provide sufficient information to use Kerberos.

By default, Active Directory allows the Network Service and Local System accounts to use Kerberos. If NtAuthenticationProviders is set to Negotiate,NTLM for an application pool, Kerberos works correctly with Network Service as the worker process identity, because this is the default worker process identity for IIS 6.0 in worker process isolation mode. However, suppose you isolate applications on a Web site by configuring each application to run in a separate application pool under a separate process identity that is a domain account. If you attempt to use Integrated Windows authentication with the isolated applications, because you want to use Kerberos authentication, Kerberos fails.

Unless Kerberos authentication is configured correctly, it fails with a 401.1 error in the following situations:

  • The Fully Qualified Domain Name (FQDN) is different from the NetBIOS name. For example, the IIS server might host a Web site called www.contoso.com on a server named web01.

  • The process—for example, Dllhost.exe or W3wp.exe—that is performing the underlying authentication runs under an identity other than System, and no SPN is registered for that identity.

  • Applications are hosted across multiple servers that use the same computer name. Only one user can be registered per computer name.

  • If all servers in a Web farm use one computer name, but load balancing distributes requests to multiple servers, and no server in the Web farm has a unique SPN.

For Kerberos authentication to work correctly, you must configure isolation at the site level, not at the application pool level. All application pools in your Web site that use Kerberos must run with the same application pool process identity. You must then register that process identity as an SPN with Kerberos by using the Setspn.exe command-line tool. The Setspn.exe tool is included in Resource Kit Tools for Windows Server 2003 Deployment Kit companion CD, or on the Web at https://www.microsoft.com/reskit. You must be a domain administrator to set an SPN. For more information about registering a service principal name by using Setspn.exe, see Configuring Constrained Delegation for Kerberos.

For more information about this limitation and using Setspn.exe, see Security-Related Changes in Authentication.