UNC Authentication

Applies To: Windows Server 2003, Windows Server 2003 with SP1

The UNC authentication method, which is also known as UNC Passthrough authentication, determines the credentials to use for gaining access to a UNC share on a remote computer. UNC Passthrough authentication works only with authentication methods that can perform delegation, for example, Basic authentication and Kerberos authentication. If you use IIS Manager to create a Web site or virtual directory and you specify a UNC path for the content, IIS Manager prompts you to type a user name and a password for the network resource. The user name must be specified as domain\username. If you specify a user name and password, both the UNCUserName Metabase Propertyy and the UNCPassword Metabase Property are set.

In IIS 6.0, UNC authentication works by looking at the requesting user and the credentials that are stored in the UNCUserName and UNCPassword properties of the metabase to determine the credentials to pass through to the computer with the UNC share. If UNCUserNameis specified (not empty) and UNCPassword is valid, the metabase user credentials are sent as the user identity for access to the remote share. If UNCUserName is specified (not empty) and UNCPassword is not valid, a "500 Internal Server Error: Invalid User Name or Password" message is sent to the client. If UNCUserName is empty, the credentials of the request user, which can be either an authenticated set of credentials for authenticated requests or IUSR_computername credentials for anonymous requests, are sent as the user identity for access to the remote share.

Table 5.6 shows the behavior resulting from the values of UNCUserName and UNCPassword.

Table 5.6 Values and Behavior of UNC Passthrough Properties in the IIS Metabase

UNCUserName Value	UNCPassword Value	Resulting Behavior
Specified (not empty)	Valid value	Metabase user credentials are sent as the user identity for access to the remote share.
Specified (not empty)	Invalid value	500 Internal Server Error: Invalid Username or Password message is sent to the client.
Empty	Not applicable	Credentials of the request user — either an authenticated set of credentials for authenticated requests or IUSR_computername credentials for anonymous requests — are sent as the user identity for access to the remote share.

Note

The UNCAuthenticationPassthrough metabase property is no longer used for UNC authentication.

Constrained Delegation

Delegation is the act of allowing a service to impersonate a user account or computer account to access resources throughout the network. When a service is trusted for delegation, that service can impersonate a user to use other network services. Constrained delegation is a new option for Windows Server 2003 that allows you to specify the SPNs to which an account can delegate. A service can be trusted for delegation, but the domain administrator can limit that trust to a select group of explicitly specified services. By allowing delegation only to specific services, you can control the specific network resources the service or computer can use.

Constrained delegation is particularly useful in scenarios in which a site that requires authentication — a site that does not allow anonymous access — contains content that is housed on a remote UNC file server. With constrained delegation, you can enable Integrated Windows authentication, which can use NTLM authentication or send credentials across the network as a Kerberos token. For more information about Integrated Windows authentication, see Integrated Windows Authentication.

Figure 5.3 shows how constrained delegation works in a simple configuration.

Deciding Whether to Use Constrained Delegation

Constrained delegation is best implemented in a Windows Server 2003 domain. Although you can use constrained delegation in a Windows 2000 Server mixed domain, there are significant limitations. In a Windows 2000 Server mixed domain, constrained delegation works only for users that are authenticated using Basic or Kerberos authentication. In addition, you cannot restrict delegation to a specific set of services on a computer running Windows 2000 Server, which makes it difficult to implement this feature and reduce the attack surface of your server.

If you do not use constrained delegation but you enable Integrated Windows authentication, the token that the Web server obtains from the security infrastructure of Windows does not have sufficient permissions to access another computer, such as your file server. However, with constrained delegation and Integrated Windows authentication, the token received by the Web server from the security infrastructure of Windows is a Kerberos-based token with permission to access other computers, including the file server. Essentially, constrained delegation allows an NTLM-based token to be upgraded to a Kerberos-based token.

If you use Basic authentication, you probably do not need constrained delegation because the tokens cached by Basic authentication have sufficient permissions to access other computers in the domain, including the file server. However, in some situations you do not need to allow clients to authenticate with Integrated Windows authentication, but you might need constrained delegation. For example, you might have applications that need to access a file server using computer accounts, such as an enterprise intranet application that impersonates the client to gain access to information on various servers in the enterprise and then presents the consolidated data to the client over HTTP.

If you are running IIS 6.0 in IIS 5.0 isolation mode and you have an out-of-process application, this process normally runs as the local IWAM_computername account, which prevents constrained delegation from working correctly. One example of an application that might fail to perform as expected in this scenario is an ASP application that accesses a remote computer running Microsoft® SQL Server™ on which you intend for the authenticated users credentials to be used. To fix this, switch IIS to run in worker process isolation mode.