Accessing Remote Content (IIS 6.0)

Applies To: Windows 7, Windows Server 2008, Windows Server 2008 R2, Windows Vista

As with any benefit, centralized content comes with tradeoffs. While remote storage gives the administrator more options on the IIS server, extra security requirements become necessary in this environment.

Logging on to IIS

When a user enters a URL in a Web browser to access content on IIS, IIS always associates the user with a user account. If anonymous access is enabled and the Web site and NTFS permissions allow the kind of access requested, the user is assigned to the anonymous account, typically IUSR_ComputerName. Otherwise, the user must authenticate using one of the authentication methods enabled for the requested resource. The user name and password associated with the user are the user’s “credentials.” Requests for local NTFS permissions are checked against the user’s security identifier (SID) to determine access permissions. Applications launched by IIS on behalf of the user are said to run in the “security context” of the user.

Accessing the Remote File Server

When a user requests information from IIS that is mapped with UNC pathnames to a remote file server, the file server challenges IIS to authenticate before that user is granted access. In IIS 4.0 and IIS 5.0, when a new Web site or virtual directory is created in which the content is located on a UNC share, IIS prompts the administrator creating the site for user name and password credentials, as shown in figure 4. The user name and password are stored in the metabase and are subsequently used to authenticate to the share to view the files in Internet Service Manager. Consequently, the user entered in the User name text box must be a valid local user on the remote file server or, if both the IIS server and file server are domain members, a domain user.

Figure 4: Virtual Directory Creation Wizard (IIS 4.0 and IIS 5.0)

When a Web user accesses the Web site or virtual directory, IIS retrieves the credentials from the metabase and uses them for authentication to the UNC share.

For example, if 100 different users authenticate to IIS and request access to a remote file server, IIS authorizes access to content stored on the local disk with each user’s credentials. For remotely-stored content, IIS doesn’t use the authenticated user’s credentials but submits the user name and password credentials that the administrator created for the Web site to the remote file server to authorize access. Using a single user’s credentials to deliver content is an effective technique for ensuring that remote content is always available; however, it reduces both the effectiveness of using NTFS permissions to secure such content and the usefulness of auditing.

In IIS 6.0, IIS Manager still allows you to configure a fixed set of credentials, like in IIS 4.0 and IIS 5.0, or you can submit the user’s credentials to the file server. This pass-through authentication (sometimes called user delegation) is the default configuration in IIS 6.0, as shown in figure 5.

Figure 5: Virtual Directory Creation Wizard (IIS 6.0)

When enabled, IIS 6.0 provides the user’s credentials to the remote system so that administrators may secure and audit remote content at a much more detailed level than possible in previous versions of IIS. Additionally, applications residing on the file server that are launched when pass-through authentication is used are run in the security context of the user.

The changes visible in IIS Manager reflect underlying changes in the metabase and in how IIS now uses authentication credentials with remote file servers. First when the UNCUsername and UNCPassword metabase properties are left blank, the credentials of the authenticated user are passed on to the remote file server, rather than the credentials being stored in the metabase. Second, if the authenticated user’s credentials are submitted to authenticate the user, but are incorrect, the server returns a 401 error (Unauthorized) to the Web browser. If UNCUserName and UNCPassword are submitted to authenticate the user, but are incorrect, a 500 error (Internal Server Error) is returned. The minimum necessary amount of information is provided in IIS error messages in order to inform legitimate users, but thwart attempts by hacking tools to determine how to circumvent the security of IIS.

Figure 6 outlines the authentication process for all content processed by IIS, including static content such as .gif files and HTML pages, script-mapped files, CGI scripts, and ISAPI extension DLLs (like ASP and Microsoft ASP.NET), all run under the proper user context. ISAPI filters run under the context of the worker process identity. By default, the worker process runs as Network Service, which is a built-in service account with minimal permissions. For more information about IIS architecture and worker process identity see the IIS Overview.

Figure 6: Authentication process for all content executed or retrieved by IIS

Pass-Through Authentication in a Workgroup Environment

In a workgroup environment, all user accounts are local. Pass-through authentication using Basic authentication can still function, as long as both the IIS and file servers have user accounts with identical user names and passwords. This configuration quickly becomes an administrative burden and consequently is not widely implemented. For these circumstances, designating a single user account designed specifically for use with the UNC connection is likely the best choice.

Pass-Through Authentication in a Domain Environment

There are several ways to configure pass-through authentication in a domain environment. Each way assumes that the file server(s) and the server running IIS are members of the same domain or of trusted domains. Each way also uses some form of delegation, which is a server’s ability to pass through a user’s credentials to another server. Using delegation eliminates the need to re-authenticate the user.

In Windows 2000 and Windows Server 2003 domains, both the Basic and Kerberos authentication methods support delegation. However, in Windows Server 2003 native domains, you can also configure delegation for NTLM, Digest, and client certificate authentication methods. These additional authentication methods, along with Kerberos, can use a new feature for Windows Server 2003 native domains called constrained delegation. This feature allows you to implement delegation with increased security and to delegate other logon credentials in addition to those provided by the Basic and Kerberos authentication methods. Constrained delegation works with IIS 6.0 worker process isolation mode.

If you use Basic authentication—which should always be implemented with Secure Sockets Layer (SSL) to encrypt the user name and password data—you do not need to do any additional configuration at the domain controller level. If you use Kerberos via Integrated Windows authentication for pass-through authentication, read the section called “Configuring Servers for Delegation” below. For NTLM, Digest, and client certificate authentication configuration, read both the “Configuration Servers for Delegation” and the “Using Protocol Transition for Authentication” sections below.

Table 1 shows the pass-through authentication configuration requirements for each authentication method.

Table 1 Pass-through authentication configuration requirements

The next section of this white paper explains how constrained delegation works. For more information about constrained delegation, see Help and Support Center for Windows Server 2003.