IIS 7.0 : Managing Remote Content

Typically, the files that comprise a Web application are stored on the IIS server’s local file system. Though this certainly makes sense when you are running a small set of Web applications, in a large or complex environment—such as a hosting company running Web farms with thousands of Web sites across many servers or a complex application consisting of many small applications that sit on different servers managed by various parties—it is almost impossible to host the application contents locally.

In some scenarios, you might need more than a single Web server to deliver a high-volume traffic Web application. Though it is definitely possible to copy the same set of contents to many Web servers serving the same application, this creates additional administrative overhead because you need to make sure that contents are synchronized on all servers, and potential replication issues could impact the application availability and content integrity. On top of that, managing content across different servers requires additional maintenance for user access accounts as well as access permissions for the content files. All of this increases the complexity of the overall deployment. Storing content locally might grant you a performance advantage, but it creates many drawbacks when scaling your application.

To work around these issues, IIS 7.0 enables you to host Web applications that have content located on a network share, which enables multiple Web servers to connect a single set of content from a file server. Though this will often increase the overhead of accessing this content, you may find significant benefits to setting up a centralized remote content store. The benefits include:

• Lower administrative overhead. Instead of setting up file system security on many Web servers, you manage the file system access only at the centralized content store. This reduces account and content management tasks to the centralized content store rather than a number of servers when content is hosted locally.

• Better fault tolerance. To increases content availability, the content can be hosted in Microsoft Cluster, Distributed File System (DFS), or even Storage Area Network (SAN) or Network Attached Storage (NAS) devices.

• More cost-effective. When compared with fault-tolerance setup at each Web server, for example, installing a set of Redundant Array of Inexpensive Disks (RAID) at every single Web server. Implementing fault-tolerance just to the centralized content store is more cost-effective and requires less hardware maintenance to have a pair of file share clusters compared to deploying a set of RAID to each sever inside a Web farm.

This section outlines the key concepts of remote content access, steps for setting up remote content, security consideration for remote content access, and a few notes on remote content configuration. These concepts generally apply to remote content management in various environments such as file share clusters and NAS devices.

Configuring the Application to Use Remote Content

Using virtual directories to map to remote content makes the content as part of an application’s URL namespace or the entire application to the remote network path at which the content is located.

To configure an application to use remote content, you need to do the following:

1. Set the physical path of the root virtual directory for the Web site or Web application to the network path where the content is located. If you would like to map only a part of the application to use remote content, you can simply create a virtual directory with the desired path in an existing application. 

2. Determine the desired security model for accessing network content, either using current credential via pass-through or custom fixed user for access credential.

3. Create the file share hosting the remote content on the network server and then grant required permissions to the file share.

Selecting the Security Model for Accessing Remote Content

To select the proper security model, it is important to consider how the Web server accesses the remote content. The following access is required:

• The web.config files located inside the remote content directory structure—to correctly apply delegated configuration for the remote content, IIS 7.0 will attempt to locate and read the web.config configuration files for all remote content directories. IIS accesses the configuration file before any content and the authenticated user is known. Because of this, either fixed virtual directory credentials must be set, or the IIS worker process identity must have read access to the remote content share.

• The content—IIS features such as the static file handler and application frameworks will access content files located in the remote content share. If the fixed credentials are set for the virtual directory, they will be used. Otherwise, the currently authenticated user identity will be used to access these files. If anonymous authentication is used, then the anonymous user identity will be used for this access.

Note

To access content, most IIS 7.0 modules and application frameworks will use the fixed credentials for the virtual directory or the authenticated user identity. However, in certain cases, they may fall back to the IIS worker process identity, in which case the IIS worker process identity must have access to the content. ASP.NET will do this by default. You may need to configure each application framework to use the correct identity. 

Generally, you can use two different security models for configuring access to the remote content share:

• Pass-through authentication. In this model, the Web server will access the remote content by using the IIS worker process identity and the identity of the authenticated user associated with the request. This is the default model.

• Fixed credentials. In this model, to access the remote content, the Web server will always use the fixed credentials configured on the virtual directory.

These options are similar to those provided by IIS 6.0. However, the need to access web.config files makes it more difficult to configure remote content access using pass-through authentication, because the authenticated user is not available when the Web server must read web.config files. This in turn requires the IIS worker process identity to have access to the remote content share. Alternatively, the fixed credential model has to be used.

Note

It is possible to disable the use of web.config files in the virtual directory by setting the allowSubDirConfig attribute on the virtual directory definition to "false". This disables the ability to use distributed configuration in web.config files inside this virtual directory, but it enables the use of pass-through authentication. 

Additionally, different application frameworks will behave differently when using the pass-through authentication model. Some application frameworks, including ASP.NET, will revert to the IIS worker process identity. Others, such as ASP, will always use the authenticated user identity. This makes it more difficult to manage access to the remote content when using the pass-through authentication model. Because of these reasons, the fixed credential model is recommended in most cases for setting up access to remote content on IIS 7.0.

The fixed credential model is simpler because it is not dependent on the Web server authentication mechanism, and it does not require all Web server users to have access to the remote content share. It also does not require delegation and protocol transition to be configured, which is required for many IIS 7.0 authentication mechanisms to use the authenticated identity to access the remote network share. This makes the fixed credential model significantly easier to configure and maintain in a networked environment.

However, because it does not use the authenticated user’s identity to access the remote content, it does not enable ACLs on the remote content to be used for authorization and auditing.

Note

The fixed credentials model does not enable NTFS file system (NTFS) ACLs to be used for auditing and authorization of authenticated users. IIS 7.0 does provide the URL authorization feature that can be used to create declarative authorization rules in configuration, which apply to the authenticated user. In addition, it is now possibly to quickly implement custom authorization solutions via IIS 7.0 modules. Likewise, auditing can be accomplished by inspecting request logs or developing a custom IIS 7.0 auditing module.

You may be able to use the pass-through model instead of the fixed credential model if:

• You need to access the remote content with the identity of the authenticated user for authorization or auditing purposes, and you cannot use the IIS URL authorization feature, custom authorization through an IIS 7.0 module, and log-based or custom auditing through an IIS 7.0 module.

• Your Web server and file server are in a domain environment.

• You are using an authentication mechanism that enables delegation of authenticated user identities (Basic authentication, Kerberos-based Windows authentication) to the remote network share, or if you have configured constrained delegation and protocol transition to enable delegation for other authentication mechanisms.

• You do not use anonymous authentication or have configured anonymous authentication to use a custom identity that has access to the network share.

• You have disabled distributed web.config configuration files in the virtual directory, or the application pool identity uses a domain account that has access to the network share to read web.config configuration files.

Configuring Fixed Credentials for Accessing Remote Content

To use the fixed credential model to configure access to the remote content, you need to set the user name and password on the virtual directory that points to the remote share. This user name and password must correspond to a valid local account on the file server or to a domain account that has read access to the network share specified by the virtual directory.

You can do this in IIS Manager when creating a new Web site or application, or by creating a new or editing an existing virtual directory. You can also do this by creating a new virtual directory or editing an existing virtual directory by using the AppCmd command line tool.

Note

Unlike the IIS 6.0 UNCUserName and UNCPassword metabase properties, IIS always uses the virtual directory credentials (if specified) to access the content and configuration files in that virtual directory, regardless of whether the physical location of the virtual directory is local or on a remote network share. This means that you can specify fixed access credentials for any virtual directory whether it refers to a local path or a remote UNC path.

Granting Access to the Remote Content

After selecting the security model for accessing the remote content and configuring the Web server to use the desired model, you need to grant the required access to the network share containing the remote content. To do this, you will need to create the network share on the file server and set the required access permissions for both the network share and the underlying files in the file system.

To do this, you will generally need to do the following:

1. Create the physical directory that will contain the remote content for the virtual directory being set up for remote content.

2. Share this directory with the desired share name via Windows Explorer.

3. Configure the share permissions to allow the identity used by IIS to connect to the share. The identity must have at least Read permission, and possibly Write/Full Access permissions if you are using IIS as a publishing mechanism. When you are using the fixed credentials for the virtual directory, this is the identity whose credentials are set on the virtual directory. This identity must be either a local account on the server or a domain account.

4. Configure the NTFS permissions on the remote content directory used by the share, in the same manner as for the network share. Retain the existing NTFS permissions on the directory to make sure that Administrators and Local System continue to have full access.

Caution

It is not recommended to grant IIS permissions beyond Read access. If the Web server is compromised, doing so can allow the attacker to gain control of the remote share. Only do this if you are using IIS to publish content, such as when using Web-based Distributed Authoring and Versioning (WebDAV). In all other cases, create a separate account for publishing content to the remote content directory.

Caution

If the account IIS uses for accessing the remote content has administrative privileges on the remote network server, an attacker can gain complete control of the file server if the Web server is compromised. Never use identities with Administrative privileges on the file server to access remote content.

When setting permissions, consider using a group to which the allowed identities belong instead of granting access to individual users for both the share and the NTFS permissions. Doing so makes it significantly easier to manage access to the remote content. It is especially valuable when using pass-through authentication to grant access to a large number of authenticated users.