Configuring Application Isolation on Windows Server 2003 and Internet Information Services (IIS) 6.0

On This Page

	Introduction
	Using Isolation for Increased Reliability
	Using Isolation to Secure Applications
	Using Isolation to Improve Performance
	Considerations
	Summary
	Appendix
	Related Links

Introduction

This paper discusses the general topic of application isolation as it relates to Web applications run on Windows Server 2003 servers with IIS 6.0 running in worker process isolation mode. Isolation refers to the degree of separation between two Web applications running on a server. In this paper, the notion of a Web application is meant in a very broad sense; it includes the processes, files, and even users, serviced by the application. Applications are isolated from each other to the degree that one application is prevented from accessing resources used by another application.

Benefits of Isolation

Enterprises are increasingly interested in isolation because of the opportunity to reduce costs through server consolidation. As the capabilities of hardware increase dramatically over time, fewer servers are required to deliver the same applications. While this decreases the costs of deployment and maintenance, it can create logistical difficulties when there is a vested interest in keeping clear boundaries between applications that are consolidated to run on a single server.

In some scenarios, each Line of Business (LOB) for an organization is essentially a separate customer to the IT group responsible for application infrastructure. For example, an organization that has been acquired may compete with other parts of the acquiring organization. Consequently, there's a business requirement for creating effective barriers between applications serving each LOB and protecting sensitive data.

Another example of a clear need for high isolation is an ISP that hosts Web sites for many clients. One customer should not be able to view the files or databases in use by other Web sites on the server.

In other cases, a company may offer Web applications and other technical resources to business partners who are in competition with each other. As a result, companies need to offer a high degree of isolation for the applications in use by their individual customers, partners, or business units using the same server. It is important, for example, to have the ability to configure one partner's software that accesses a database, such that the application could not access another partners database.

Another benefit of application isolation is that you can design the infrastructure of the applications, server, and network to improve the ability to distribute content and applications. For example, you may want to put content on a remote file store so it can be shared by more than one server. Alternately, you may want to host each applications content on different file servers, to further isolate each LOB application, but share the same Web server as a front end.

The following sections discuss several approaches to obtaining a high level of isolation.

Physical Isolation

The highest degree of isolation is achieved when applications are hosted on completely different computers. Clearly, this offers the most isolation for applications but is also the most expensive, requiring additional hardware and server licenses to support each application. Nevertheless, in mission critical LOB applications, where information is very sensitive or valuable, this may be the best choice.

Virtual Isolation

You can also create isolated applications using virtual servers. Using software, such as Microsoft VPC or VMware that allows you to create multiple virtual servers running as tasks on a single operating system, you can create several servers that are functionally partitioned. Consequently, the applications can be highly isolated, yet run on the same hardware. Because virtualized systems do not perform as well as individual computers, virtual isolation provides high isolation, but at the cost of performance. Another incremental cost is software licenses for the virtual systems. In addition to the software licenses needed for the server hosting the virtual systems, you must also acquire individual software licenses for the operating system and applications on each virtual system as if each virtual system were an individual system.

Configured Isolation

Isolation by configuration means taking advantage of natural isolation boundaries, such as processes, security identities, Access Control Lists (ACLs), and namespaces that occur as a result of running the applications on a Web server. The degree of isolation achieved through this configured isolation is not as strong as physical or virtual isolation. Nevertheless, configured isolation is often the most reasonable choice to balance resource usage, simplicity of administration, and to leverage investments in hardware, software, and licensing. New features in Windows Server 2003 and IIS 6.0 make this option a more reliable, secure, and scalable solution than previously possible.

Isolation Through Operating System Features

Microsoft Windows Server 2003 has a number of features that support creating isolated environments for applications. Constrained Delegation and Protocol Transition allow you to pass through a users security context to file servers, regardless of the protocol used to authenticate the user on IIS. Quality of Service (QoS) improvements include a packet scheduler integrated with IIS that enables an administrator to limit the amount of bandwidth available to an application. Windows System Resource Manager (WSRM) is available for use with Windows Server 2003, Enterprise Edition, and Windows Server 2003, Datacenter Edition. WSRM allows an administrator to control exactly how much CPU an application pool can consume when the CPU is under load.

Isolation Through IIS Configuration

IIS 6.0 was designed with application isolation as a primary component of the architecture. Each Web site has the capacity to host one or multiple applications that can be assigned to run in a named process pool called an application pool. An application pool is served by one or more worker processes, can be independently configured for health-related settings, and can be assigned to run in the context of a designated user account.

In configuring application isolation, there are several objectives:

By combining the capabilities of IIS 6.0 with those of Windows Server 2003, you can effectively implement isolation and achieve these designated goals. Additionally, improvements in FTP and Microsoft FrontPage Server Extensions help enhance isolation and security of these applications.

The rest of this paper will address the capabilities of Microsoft Windows Server 2003 and IIS 6.0 for creating highly isolated applications that run on a single server. There is no single technique or administrative task that achieves this goal, but when using combinations of techniques, you can effectively implement application isolation.

Top of page

Using Isolation for Increased Reliability

One of the core design goals for the IIS 6.0 architecture was to improve the isolation between applications while minimizing the performance tradeoffs. This was accomplished by redesigning the IIS architecture for increased reliability, security, and performance. The basics of the new architecture with regard to increased reliability include the following elements:

Improved Isolation with Application Pools

Technically, an application pool is a configuration object defined by a logical process boundary that is used by the HTTP.sys namespace mapper to direct requests to the correct worker process. In practice, this translates to the rather simple administrative task of using the IIS Manager to create an application pool, such as Project32-HighlyRestricted, and then assigning the programs contained in Web sites and directories to run in that application pool, or other application pools as you require (see Figure 1).

Figure 1: Assigning programs to application pools in IIS 6.0
See full-sized image.

In effect, application pools allow you to combine or isolate applications according to your technical, administrative, and business requirements.

Using Application Pools to Isolate Customer Applications or Business Units

Application pools create process boundaries between applications from different Web sites or directories on IIS. This is ideal for businesses such as ISPs, where each customer's applications need to be insulated from others, or for the scenario used above where LOB applications need to be isolated from one another. See the Security section of this paper for details about how to use ACLs to enforce application isolation on the file level.

Using Application Pools to Isolate Unreliable Applications

The WWW Service Administration and Monitoring component of IIS provides recycling and health features that can automatically restart an application pool. These features have been shown to significantly improve reliability. For example, consider an important application that you cannot afford to have offline, yet occasionally hangs. By placing this application in its own application pool, you insulate other applications from its effects. This increases overall reliability of other applications running on the server. Also, because application pools are individually monitored and can be configured to be automatically restarted when they are unresponsive, availability for unreliable applications is increased. Troubleshooting such an application is also facilitated because the application can be configured to run in its own process.

Recycling

Recycling criteria can easily be administered through the Application Pools Properties dialog, as shown in Figure 2 below. Recycling can be triggered based on several parameters, such as application uptime, number of requests, on a scheduled basis, based on memory consumption, or at will.

Figure 2: Recycling parameters available with IIS 6.0
See full-sized image.

Recycling can enhance application isolation and reliability by:

Impacts of Application Recycling

When an application is recycled, any information stored in the worker process, such as session state, is lost. To optimize the performance and reliability of your applications with IIS 6.0, you'll want to design them to be recycled without losing ongoing transaction data. For example, you can preserve session state details out of process using the ASPState service in Microsoft ASP.NET or store the data in Microsoft SQL Server.

Applications designed for recycling have an initialization time that is optimized to be as small as possible. Applications that require a long initialization procedure won’t perform well with frequent recycling. You can work around this by scheduling recycling during low usage periods.

Finally, your applications should tolerate running side by side with other instances of the same application. You can configure recycling to be overlapping or non-overlapping. By default, recycling is configured to be overlapping: the WWW Service Administration and Monitoring component creates a new worker process to process any new requests for the application before the existing worker process is shut down. The old worker process is kept alive until it has finished processing its existing requests or until a shutdown time-out event, whichever occurs first. During this period, both instances of the application will need to share resources. If recycling is configured to non-overlapping, the WWW Service Administration and Monitoring component shuts down the worker process before starting a new one. For information about configuring overlapping and non-overlapping recycling, see DisallowOverlappingRotation in the IIS 6.0 Help (http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/cde669f1-5714-4159-af95-f334251c8cbd.mspx).

Health

The WWW Service Administration and Monitoring component also maintains the health of applications by periodically testing an application pool for responsiveness. Not to be confused with the Internet Control Message Protocol (ICMP) ping command, this feature internally queries the application pool at a configurable interval (every 30 seconds by default) and waits for a response.

If there is no response, the WWW Service Administration and Monitoring component shuts down the worker process, publishes an event, and starts a new worker process. IIS can also be configured to not destroy the failed worker process. In addition to keeping the failed worker process, you can specify a program to launch when this event occurs to automatically instantiate troubleshooting or reporting tools.

For more information about isolating unhealthy worker processes, see Application Pool Health (http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/3f20bedc-67a4-4bdd-a435-ea7d2363c3b9.mspx) and OrphanWorkerProcess (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/iissdk/html/c70603f3-7fc2-4e0b-b177-77b92c8fb38b.asp) in the IIS 6.0 Help.

Rapid-Fail Protection

Rapid-fail protection can protect the server from a series of rapid worker process failures in the same application pool by disabling the application pool. When an application pool is disabled, IIS removes it from service and places it in a mode where the kernel-mode driver immediately returns a 503 Service Unavailable error message to any requests to for that application pool.

The number of failures and the interval in which they must occur are configurable per application pool. When rapid-fail protection is enabled, the Startup time limit and Shutdown time limit settings are used as measures of application pool health (see Figure 3).

Figure 3: Health options available in IIS 6.0
See full-sized image.

A worker process that fails to start up or shut down within the designated time is considered to have failed and counts toward the number of failures required to take the application pool offline. By default, rapid-fail protection is configured to disable an application pool if five application failures occur in a five-minute period.

Functional Use of Application Pools

In some cases, you will find that using an application pool is useful in order to separate applications that have different technical requirements. For example, you may find it helpful to configure all applications that require a particular COM component into a single application pool, if the COM component is known to be problematic. Also, as your applications undergo upgrades and improvements, it can be useful to create separate application pools for the new versions.

.NET Framework Application Domains

On Windows Server 2003, ASP.NET uses the application request-processing-model in worker process isolation and also maps one or more ASP.NET application domains to each worker process. The application domains within a single worker process can be recycled independently and have private components, session variables, and other private resources. This provides an additional layer and better granularity of isolation.

.NET Framework and Side-by-Side Assemblies

Traditionally, when a component or application is updated on a computer, the older version is removed and replaced with the newer version. If the new version is not compatible with the previous version, this usually breaks other applications that use the component or application. The .NET Framework provides support for side-by-side execution, which allows multiple versions of an assembly or application to be installed on the same computer, at the same time. Since multiple versions can be installed simultaneously, managed applications can select which version to use without affecting other applications that use a different version.

For example, applications can take advantage of side-by-side assemblies in order to allow applications to be installed on the same computer that require different versions of a DLL such as MDAC, MFS, MSVCRT, or MSXML. For more information about this topic, see the Appendix at the end of this paper.

Top of page

Using Isolation to Secure Applications

One of the primary tools for configuring isolation is the use of Access Control Lists (ACLs), authentication, and process identities to create effective security boundaries between applications. While configured isolation doesn't equate to the degree of isolation provided by independent servers, you can effectively use ACLs to prevent one application from accessing the files of another application inadvertently or maliciously. For example, a Web site administrator may create a script to browse the directory or change files of another application using the file system object. The administrator could also write an ASP application that reads data from files of another site such as a customer database. Proper use of ACLs and other authorization boundaries in Windows Server 2003 can prevent this scenario from occurring.

Configuring Application Pool Identity

One of the most important rules to remember when securing a server is that all processes must run as a user or built-in account. In most cases, this requirement is transparent, because file system resources required by or requested from an application are typically opened in the context of the user making the request. However, an application developer can choose to author an application in such a way that the file system resources are opened in the context of the account used to launch the parent process hosting an application rather than the user.

Lets examine what happens when an anonymous user opens an application. The user makes a request to the application and is automatically assigned to the anonymous account (typically the IUSR_<ComputerName> account). The requested file is opened and executed using the credentials of the anonymous user, provided the proper permissions are in place in the IIS Manager and ACLs on the requested file. However, if the application then invokes the Win32API RevertToSelf function, subsequent file accesses made from the application occur as the Network Service user account. The Network Service user account is the built-in account assigned as the identity for application pools.

Built-in Accounts

Even though the Network Service user account has limited rights on the server, application pools sharing this identity have rights to each others resources when ACLs are configured to allow access to this built-in account. You will want to give each application pool its own identity in order to effectively isolate applications, as shown in Figure 4.

Figure 4: The default identity for an application pool is the Network Service user account
See full-sized image.

Because an application can run as the application pool identity, when selecting an application pool identity, you should choose one with the least number of privileges required by your application. In the case where the worker process identity is set to an account with high privileges, like LocalSystem, the result may be that the application is given permissions beyond the scope of the authenticated user. Instead, consider setting the worker process identity to an account with low privileges to prevent an application from elevating its privilege in this manner.

Assigning an Account

When configuring an individual user account as the application pool identity, you must make the user account a member of the IIS_WPG local group. The IIS_WPG group is created to simplify the process of setting the necessary authorizations and rights on all of the system resources that a worker process must access to function properly, including launching application pools. When IIS is installed, or when new application pools are created, the IIS_WPG group is included in all ACLs of resources that the application pool must access. However, it is not necessary to add IIS_WPG to a sites content directories and files. In fact, if you require high isolation between users, but configure ACLs that grant access to IIS_WPG, you may decrease the degree of isolation because all applications whose user accounts are members of the IIS_WPG group would have access to each others content. Consequently, you will want to add accounts you create for each application pool identity to the IIS_WPG local group, but you should not use the IIS_WPG group in ACLs on content files and directories.

Accounts used for application pool identity should also be distinct from anonymous accounts and individual accounts for site authors and owners. Accounts used for anonymous access or for site authors and owners should not be added to the IIS_WPG group because doing so would grant those accounts access to directories that are shared among application pools such as the compression cache and ASP template cache.

Additionally, if you configure application pools with an identity other than Network_Service and your applications launch CGI processes, you will need to assign the following user rights to accounts designated as application pool identities:

Authentication Considerations

Authentication is the process of proving that you are a valid user to an application. Once proven valid, the user is then assigned an identity, which is used to limit access to resources. Part of building secure boundaries between applications is to ensure that you have the identities for your applications and users organized in such a way that you can effectively manage the authorization of the application and the users access to resources.

IIS 6.0 supports Anonymous, Basic, Digest, Advanced Digest, Client Certificate, Integrated Windows (NTLM and Kerberos), and Passport authentication. Additionally, applications may implement their own authentication methods, for example, forms-based authentication in ASP.NET. Remember that the method you use for authentication can impact the choices you have for implementing security.

For highly isolated applications, it is best to create a unique user account to be used for anonymous access for the application, and then assign this user as the anonymous user in the Directory Security tab of the properties for the Web site (see Figure 5). This allows you to configure authorization (see the Configuring Authorization section) so that applications launched by the anonymous user are constrained to appropriate resources. A unique anonymous user identity combined with a designated account for the application pool identity provides two of the essential elements needed for constructing an effective security boundary for the application.

To configure a unique anonymous user account for a Web site

1.	In IIS Manager, expand the local computer, expand the Web Sites folder, right-click the Web site you want to change, and then click Properties.
2.	On the Directory Security tab, under Authentication and access control, click the Edit button, as shown in Figure 5. Figure 5: Site properties Directory Security tab See full-sized image.
3.	In the Authentication Methods dialog, enter the User name and Password of the account to use for anonymous access, as shown in Figure 6. Figure 6: Configuring a unique anonymous user account See full-sized image.
4.	Click OK
5.	Click OK

When using Kerberos or Basic authentication, you can use UNC passthrough authentication to determine the credentials to be used for gaining access to a UNC share on a remote computer. Administrators can configure IIS to use a fixed set of credentials or to submit the user's credentials, known as pass-through authentication, to the file server or NAS device. By default, IIS is configured to use pass-through authentication for Basic and Kerberos authentication when working in a Windows Server 2003 environment and running application pools with the Network Services identity. You can also configure Windows Server 2003 so pass-through authentication is possible for any authentication method.

Note: Use a domain-based account when assigning an application pool identity if you intend to use pass-through authentication with Kerberos. For more information about this, see the Deploying and Configuring Internet Information Services (IIS) 6.0 with Remotely Stored Content on UNC Servers and NAS Devices white paper (http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/webapp/iis/remstorg.mspx).

ASP.NET applications using forms-based authentication rely primarily on the use of .config files to control authentication. The application .config files may contain user names and passwords required to access the applications or may reference a database (other than the local SAM or Microsoft Active Directory) to validate users. Applications using forms-based authentication have enhanced application boundaries, since the authentication for a user is valid only in the authorizing application.

Configuring Authorization

The foundation for effectively enforcing application isolation lies in the proper use of authorization. Authorization uses the authenticated identity of the user, including the anonymous user, to limit access to resources. For our purposes, the concept of a user is also extended to the identity of application pools, which are authorized only to use resources required by the application.

Methods for enforcing authorization include configuring ACLs on content, share permissions, the metabase, and the registry. Additionally, other techniques, for example, URL authorization using Windows Server 2003 URL Authorization manager and authorization in ASP.NET applications can be used.

Configuring ACLs on Content

When configuring ACLs, your task will be easier if you keep in mind two principles:

When implementing permissions, users often require flexibility that was not preconceived when the applications were first configured. To preserve your options and ease administration, consider using groups to contain application pool identities, then assign ACLs to the groups. For example, when configuring isolation for Application X, create a group, such as ApplicationX_Processes, and then assign application pool identity for Application X to this group. This allows you several conveniences:

Once you have assigned your application pool identity, you need to assign NTFS permissions to file system resources to allow permissions on a variety of locations, including folders used in databases, compiling or caching of scripts, logging directories for customized logging, or other file system locations where the application pool identity requires access. Be careful not to unintentionally allow another application pool identity access to the same resources. For example, you would not want to assign permissions to the Users or the IIS_WPG group. Remember that if access is not specifically allowed, it is denied.

In addition to configuring ACLs for the proper access by the application pool identity, you need to provide permissions for users. This is facilitated by creating groups that designate functions, such as ApplicationX_authors and ApplicationX_anonusers, then adding users to these groups and assigning permissions to the groups. Having a group for anonymous users is useful in that you may wish to authenticate some users for logging or auditing purposes, but still only allow them access to resources as if they were anonymous users.

Configuring for Access of UNC-based Content

When accessing content on another server using UNC paths, you must consider both Share and NTFS permissions. Often Share permissions are left fairly open and NTFS permissions are used to secure the content. The degree to which you lock down your Share permissions is dependent on your specific security requirements.

For the majority of applications, Share and NTFS permissions on remote content will be assigned to the authenticated user that is requesting access. If you are using the default pass-through authentication, this will be the individual user as authenticated by IIS. If you are specifying a user account for remote access, as was required in IIS 4.0 and IIS 5.0, the specified user will require access rights for both Share and NTFS permissions. If the user specified for accessing remote content is not a domain account, it is best if the user account is created with the same user name and password on the IIS server as well as the remote file server. This facilitates management of remote content in the IIS Manager console. For more information about configuring authentication and authorization for UNC servers and NAS devices, see the Deploying and Configuring Internet Information Services (IIS) 6.0 with Remotely Stored Content on UNC Servers and NAS Devices white paper (http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/webapp/iis/remstorg.mspx).

Configuring ACLs on the Metabase

In addition to setting ACLs on file system resources, you can set ACLs on metabase keys. Use Metabase Explorer 1.6 or MetaEdit 2.2 to view and set ACLs on metabase keys. Metabase Explorer 1.6 can be downloaded from http://www.microsoft.com/downloads/details.aspx?FamilyID=56fc92ee-a71a-4c73-b628-ade629c89499&DisplayLang=en. MetaEdit 2.2 can be downloaded from http://download.microsoft.com/download/iis50/Utility/5.0/NT45/EN-US/MtaEdt22.exe.

For Web sites and their contents that have corresponding keys with properties in the metabase, the IIS_WPG group is set to Allow for the permissions: Query, Query Unsecure Property, and EnumerateProperty. The default ACLs on application pools permit the IIS_WPG, Network_Service, and Local_System accounts the ability to query metabase properties for all application pools.

Applications running in the context of the application pool do not have the ability to alter the metabase unless the application can be run in the security context of the Administrator identity, which by default has full control on the entire metabase. This can occur, for example, when the system administrator logs in or authenticates to the application using the Administrator credentials and the application assumes the credentials via impersonation. Consequently, these settings do not represent a serious security risk. However, you can increase application isolation by making the following adjustments to isolate a sites metabase settings:

Configuring ACLs on Registry Keys

On secure servers, it is recommended that permissions be tightened on certain registry keys. Microsoft provides several templates for tightening permissions, including those provided with the Security Operations Guide (http://www.microsoft.com/technet/security/prodtech/win2000/secwin2k/default.mspx). Increasing security in general will increase the effectiveness of application isolation, but you may need to specifically restrict access to portions of the registry that contain information about COM objects used by your applications. It should not be possible, for example, for a user to determine what objects are registered on the server and then write a script to invoke those objects.

COM+ Isolation

COM+ Partitions can be used to isolate Web applications into their own COM+ partitions. This is useful to prevent one Web application from accessing the private COM+ applications, configuration information, and data of another Web application. COM+ partitions can hold different versions of your own custom COM components. For example, if you host Web sites for two competing companies that both use COM+ in their Web applications, you can use COM+ partitions to ensure that one company's Web application cannot access the COM+ components in the other company's Web applications. If one of those companies asks you to change certain features in a COM+ application that they both use, you can isolate the new version of that COM+ application in the partition that is linked to their Web application.

To enable COM+ partitions on the IIS side, set the AspUsePartition flag of the AspAppServiceFlags metabase property at the application level. The partition is identified by a GUID (created using the Component Services Manager snap-in), which can be set at the AspPartitionID metabase property. If no partition is specified, the default system partition is used. For more information, please see "Creating and Configuring COM+ Partitions," in the COM+ SDK (http://go.microsoft.com/fwlink/?LinkId=2823).

Important: Only one version of a COM+ component can be used in any application pool, even though this feature is configurable at the application level. For example, if application App1 uses version 1.0 of a custom COM+ application called Shop.dll, and application App2 uses version 2.0 of Shop.dll, then App1 and App2 should not be in the same application pool. If they are, the application that is loaded first has its version of Shop.dll loaded, and the other application is forced to use it until the applications are unloaded.

URL Authorization

Authorization Manager and URL authorization are features of the .NET Framework that have been extended into the operating system for Windows Server 2003. Consequently, these features are available to ASP and other applications. Windows Server 2003 and IIS 6.0 provide the ability to use Authorization Manager in combination with URL authorization to create sets of rules that authorize access to URLs based on the user's roles. Roles can be defined any number of ways, including Lightweight Directory Access Protocol (LDAP) queries, custom user roles, and Authorization Manager scripts (BizRules). This is quite different from applying ACLs to files, because role membership can be determined through a query at the time of the request. For example, you could authorize employees of a company, who have been employed for more than 90 days, to access a specific URL. When an employee reaches the 91 day of employment, however that is defined by your requirements, access is granted without the need to change ACLs, or local/domain group memberships. For better application isolation, you may define a rule so that all employees or customers of CompanyA can access the CompanyA application and all others are denied.

For more information about Authorization Manager, see Authorization Manager in the Windows Server 2003 product documentation (http://www.microsoft.com/technet/prodtechnol/acs/proddocs/default.mspx). For more information about URL authorization, see URL Authorization in the IIS 6.0 Help (http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/3f20bedc-67a4-4bdd-a435-ea7d2363c3b9.mspx).

FTP User Isolation

IIS 6.0 also includes an FTP server to allow users to upload or download files. Where FTP is deployed, configuring your server so that FTP users cannot browse other user's directories is an important part of server security. IIS 6.0 provides for this capability with FTP user isolation. When enabled, a user cannot navigate higher up the directory tree, because the user's top-level directory appears as the root of the FTP service. Within the user's specific site, the user still has the ability to create, modify, or delete files and folders.

FTP user isolation has three settings available for user restriction, as shown below in Figure 7.

IMPORTANT: FTP is not a secure protocol, so user names and passwords are sent across the network in clear text. In addition, you cannot use SSL with FTP.

Figure 7: FTP User Isolation allows three options to restrict user access
See full-sized image.

FTP user isolation has two modes to isolate users: Isolate users and Isolate users using Active Directory.

Isolate Users

This mode authenticates users against local or domain accounts before they can access the home directory that matches their user name. All user home directories are in a directory structure under a single FTP root directory where each user is placed and restricted to their home directory. In this mode, the home directory name is the same as the authenticated user name. When users authenticate, they are automatically placed into the directory that corresponds to their logon name and they are not permitted to navigate out of their home directory. If users need access to dedicated shared folders, you can also establish a virtual root. This mode may use, but does not require, the Active Directory service.

Isolate Users using Active Directory

When you set your FTP server to isolate users with Active Directory, each user's home directory can reside on an arbitrary network path. In this mode, you have the flexibility to distribute user home directories across multiple servers, volumes, and directories, as is appropriate to the network configuration, and the home directory name may be different from the authenticated user name. This is accomplished by using ADSI to set the msIIS-FTPDir and msIIS-FTPRoot properties for the user object in Active Directory. For more information about setting these properties with the IISFTP.VBS scripts, see Setting Active Directory User Isolation in the IIS 6.0 Help (http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/iis/default.mspx). Note that the IIS 6.0 Help incorrectly lists these attributes as FTPRoot and FTPDir. These properties are not exposed in the Active Directory Users and Computers console.

For step by step instructions on how to implement FTP user isolation, see Isolating FTP Users in the IIS 6.0 Help (http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/3f20bedc-67a4-4bdd-a435-ea7d2363c3b9.mspx).

FrontPage 2002 Server Extensions Security

FrontPage 2002 Server Extensions make it simple for users to publish Web sites using FrontPage and to publish Web applications from Microsoft Visual Interdev. You can create a FrontPage-enabled Web site by extending the Web site with the FrontPage Server Extensions.

To create a FrontPage-enabled Web site

FrontPage Server Extensions uses a distributed security model where the account specified as the Web administrator has the right to create users and assign roles resulting in permissions being changed on the Web site. The Web administrator can do these tasks, but is not required to be an administrator on the server. Consequently, you should configure the Web administrator to use an account that is not a member of the Administrators group.

When you install FrontPage Server Extensions on your server, a specialized application pool named MSSharepointAppPool is created and is assigned to run in the security context of the Local System account. The _vti_bin folder of any FrontPage-enabled Web site will run in this security context. The _vti_bin folder in each FrontPage-extended Web or sub-Web is a virtual directory mapped to the same physical directory containing the FrontPage Server Extensions binaries, so each application runs the same FrontPage Server Extensions code. Although the FrontPage Server Extensions share an application pool, applications may still be configured in their own application pool, so that the user-written part of the application, and any other user-provided code, can be isolated.

How FrontPage Manages ACLs

FrontPage Server Extensions 2002 will manage permissions on Web content without server administrator intervention, using roles-based authorization. Users are assigned roles such as browser, author, Web designer and administrator. When you create a Web site and then extend the Web with FrontPage Server Extensions, FrontPage Server Extensions adds certain users and groups to your Web content folders with specific permissions. These include the Network and Interactive built-in groups. This could represent a security issue, as these groups are automatically maintained by the server. A user with a network logon type is a member of the Network group (authenticated with NTLM, for example). A user with a local logon type (authenticated with Basic, for example), is a member of the Interactive group. Consequently, granting these groups access rights to FrontPage Web content probably grants users from other Web sites and applications the same rights granted to the Network and Interactive groups, depending on how the users are authenticated. To improve isolation and security between applications, FrontPage Server Extensions on Windows Server 2003 allow group accounts to be used for authorization.

Using Group Accounts to Isolate Access to FrontPage Webs

You can configure FrontPage Server Extensions so that they use group accounts instead of the built-in Network/Interactive groups. When properly configured, FrontPage Server Extensions will not add the Network and Interactive groups to ACLs on root Webs, but instead will authorize access to the Web using a group name constructed by a prefix you provide (such as SecureWeb) and the Web site instance number. The resulting group name for the default Web site in this example would be SecureWeb_1. This group can then be configured manually to manage access to the Web site.

Details on implementing this feature should be read carefully at http://www.microsoft.com/technet/prodtechnol/sppt/sharepnt/proddocs/admindoc/owsj03.mspx.

For more details on FrontPage Server Extensions 2002 and Microsoft SharePoint Team Services, see http://www.microsoft.com/technet/prodtechnol/sppt/sharepnt/proddocs/default.mspx.

Disabling Shared File Caches

IIS and ASP use file caches to improve performance while serving Web content. On an isolated server, these caches should be disabled because the directories they use are shared by application pools with ACLs allowing access to the IIS_WPG group. It is possible under some circumstances for a malicious site owner to write an application running in one application pool to browse data stored by other applications in these directories. While the likelihood and impact of this scenario are limited, disabling IIS compression, static file caching, and ASP template caching blocks such exposure in the first place. Conversely, on a server in which all of the site owners are trusted or there is a single owner for multiple sites, this is not a problem.

To disable IIS compression

Alternatively, you can enable HTTP compression of static files by setting the HcDoStaticCompression and HcDoDynamicCompression metabase properties to false.

To disable ASP file caching

To disable static file caching

You need to restart IIS for this setting to take effect.

Top of page

Using Isolation to Improve Performance

Another benefit of application isolation is the ability to limit the effects on other applications of over consumption by any individual application. There are a number of Windows Server 2003 and IIS 6.0 features that help to assure that applications will have available to them the resources required when they need them.

IIS 6.0 Features for Resource Availability

Application pools in IIS 6.0 allow better use of resources than with previous versions of IIS. The properties for application pools allow you to configure a variety of parameters that effect resource use of the application. Because these settings are available per application pool, you can optimize the configuration of the application pool for the specific characteristics of the application, load, and resulting resources required. Figure 6 shows the Performance property tab for the Default Application Pool.

Memory Recycling

Each application pool can be set to recycle when it uses too much shared (maximum virtual memory) or privately-allocated (maximum used memory) system memory. When memory use passes one of these thresholds, recycling occurs without interfering with other applications, making the memory consumed by the application available for other applications and system requirements. (See Figure 2, Recycling parameters available with IIS 6.0, in the Recycling section above.)

Request Queue Limit

Because the request queue for an application pool resides in the kernel, if an application pool receives requests faster than it can respond, kernel memory is used to queue the requests. In order to keep queue size from growing too large, you can specify the maximum number of requests that can be queued for an application. Subsequent requests will receive a 503 error and are logged to the HTTPERR log with a reason string of QUEUE_FULL.

Rapid-Fail Protection

This topic was discussed earlier in the Isolation for Increased Reliability section. This setting configures IIS to remove an application pool that contains a failing application from service, and place it in a mode where the kernel-mode driver immediately returns a 503 Service Unavailable out-of-service message to any requests to that application pool. Consequently, this helps prevent failing applications from interfering with other applications running on the server, and system resources that may have been locked up by a non-responsive application are released.

Number of Connections

On the Performance tab of the properties of a Web site, you can set the number of connections allowed for the Web site. This could be useful when you are offering Web sites that provide a number of connections as a condition of service, or when you are concerned about the number of connections overwhelming a Web site's applications. Additionally, you may have non-critical, but popular Web sites you wish to constrain in order to make resources available to other applications.

Windows Server 2003 Features for Resource Availability

Windows Server 2003 has several features that can be implemented to help assure resource availability for Web applications. In some cases, enabling a feature in IIS invokes a process for installing the capability at the server level. For example, configuring bandwidth throttling in IIS Manager automatically enables the Quality of Service Packet Scheduler for the server. In this way, server capabilities are more seamlessly integrated into IIS Manager than in previous versions of IIS.

Windows System Resource Manager

Windows System Resource Manager (WSRM) is available for use with Windows Server 2003, Enterprise Edition, and Windows Server 2003, Datacenter Edition. WSRM enables you to manage CPU and memory utilization on a per process basis. An administrator sets targets for the amount of hardware resources that running applications or users are allowed to consume. This means that you can allocate resources among multiple applications on a server according to your business priorities.

When used to manage IIS performance, WSRM enables a system administrator to do the following:

WSRM maintains an updatable exclusion list of processes that shouldn't be managed because of the negative system impact such management could create. WSRM does not manage address windowing extensions (AWE) memory, large page memory, locked memory, or operating system pool memory.

Bandwidth Throttling

On the Performance tab of the properties of a Web site, you can enable bandwidth throttling and set the maximum bandwidth consumption for a Web site. Unlike previous versions of IIS, bandwidth throttling uses the Quality of Service Packet Scheduler to manage when data packets are sent. When you configure a site to use bandwidth throttling using IIS Manager, Packet Scheduler is automatically installed, and IIS automatically sets bandwidth throttling to a minimum of 1024 bytes/second. You can configure this setting higher, but not lower.

Using Resources Efficiently

Of course, if you have sufficient resources available for your applications, you do not need to spend as much time constraining applications and Web site use. Toward that end, application pools have several properties that optimize server resources.

Idle Time-out

Idle Time-out is located on the Performance tab of application pool properties. When configured, a worker process in an application pool will be terminated if it remains idle for the configured interval. This frees memory-based resources for active applications. For ISPs that often have many Web sites on a server with only a few active at any time, this permits a greater Web site density per server, without over-committing server resources.

Demand Start

Another feature of IIS 6.0 that helps with efficient use of resources is demand start. Application pools, even though configured and available, are not started until they are requested. In this way, applications are not loaded before they are required, which keeps resources available until the moment they are needed. However, this also may intensify the performance impact of application startup time. If your applications are not optimized to start up quickly, and you don't have a large number of applications in use, you may wish to disable Idle Time-out so that once applications are launched, their worker process remains active and the resources acquired by the application are not released.

WebGardens

A Web garden is an application pool that is serviced by more than one worker process simultaneously. This is enabled by setting the number of worker processes setting to more than one on the Performance tab of an application pool. When requests for the application begin to queue, IIS 6.0 automatically creates another worker process for the same application pool and begins to route new requests to the new worker process. When demand is reduced, the worker processes will eventually be spun down and resources released. Web gardens are useful in situations where there are a high number of concurrent connections and contention for locks and resources within a single process may limit request throughput.

CPU Affinity

Application pools can be assigned to run on a CPU. On an SMP system, this allows you to distribute CPU resources among the application pools. For example, if you have an application pool that runs a CPU-intensive application, assigning the application pool to a CPU could assist with performance by making certain that enough CPU processing power is available to the application. This also leverages the caching technology built into the processor. Other application pools can similarly be configured away from the dedicated processor. CPU affinity is set in the metabase. For more information about configuring CPU affinity, see SMPAffinitized in the IIS 6.0 help (http://technet2.microsoft.com/WindowsServer/en/Library/02b0333e-2fe5-4fcd-a0d9-b9fa960e90251033.mspx).

Top of page

Considerations

Performance and Scale

While high isolation achieves many benefits, it impacts scaling for the server. For example, Microsoft tests show that you can run up to approximately 500 worker processes simultaneously. Assuming you have 20,000 sites, you can configure your application pools so that applications share them — a low isolation approach — or you can give each application its own application pool, but set the application pool time-out aggressively.

Number of Application Pools That Can Be Configured

In the default configuration, using Network_Service as the application pool identity, you can create a large number of application pools without any difficulty. When you specify an identity for an application pool, it is given a set of resources, including a non-visible desktop. Interactive processes use desktops for dispatching events or messages, such as a mouse click, to Windows applications. In this context, only a few desktops are ever required by an application. For server applications, such as IIS, there is no interactive user; IIS and other COM applications running in a Single Threaded Apartment (STA) use the Windows message pump in a desktop to marshal data to COM components created within the process, and desktops are created even if the application uses no COM components. Microsoft tests show that when configuring more than 60 application pools with unique identities, a shared desktop should be used. This may be configured by setting the registry key HKLM\System\CurrentControlSet\Services\W3SVC\Parameters\UseSharedWPDesktop to 1. When this setting is enabled, application pools share a common desktop, thereby increasing scalability.

Number of Web Sites and Active Worker Processes

The number of application pool worker processes that can be simultaneously active on a server is dependent on a variety of factors, including hardware configuration, the specific language in use, number of sites, number of application pools, and how those application pools are configured. IIS supports up to 20,000 configured sites, although the number of concurrent sites varies in practice, depending on how they are configured to application pools and the ratio of active to configured sites on a server.

Regarding non-ASP.NET applications, IIS 6.0 has been tested on a well-configured mainframe server running up to 2,000 concurrent worker processes, each serving one application pool, but not using unique identities. In practice, a design of up to 500 simultaneous application pools is achievable, depending on the application requirements and assuming hardware resources are not a significant constraint. It is important to configure the UseSharedWPDesktop registry setting mentioned above when using more than 60 application pools with unique identities.

When running ASP in a hundred or more application pools, you will need to configure ASP to run its threads in a Multi-Threaded Apartment (MTA). To enable this capability, set the metabase property AspExecuteInMTA to 1 (it is set to 0 by default). When ASP is set to run in a MTA and the ASP application also uses Single-Threaded Apartment (STA) objects, performance may be affected by the data marshalling that occurs between ASP, running in an MTA, and the component, which runs in a STA in another process. If you are using components such as ADO, which use an apartment model of Both there should be no problems with enabling this setting. For more information about enabling multi-threaded apartments, see AspExecuteInMTA in the IIS 6.0 Help.

ASP.NET applications require more resources than ASP. While 500 individual application pools may be reasonable for ASP, it is aggressive for ASP.NET. You will need to study your server performance as pools are added to determine a practical ceiling for the number of application pools running ASP.NET in your environment.

Top of page

Summary

In this white paper, we have reviewed the various techniques you can employ to increase application isolation and the various benefits that isolation can offer. While clearly the most isolated design would be an individual computer for each application, you can create effective application boundaries by correctly configuring Windows Server 2003 and IIS 6.0. The ability to gather or isolate Web applications into an application pool in IIS 6.0 is perhaps the most significant component of application isolation. The built-in abilities of IIS 6.0 to manage resources efficiently, monitor application health, recycle applications, and assign security identities to application pools creates a centerpiece from which you can deploy isolated applications. Combining these abilities with proper use of authentication, ACLs on various resources, and constraining applications as required, creates an environment where applications can have an optimized set of resources available to them on demand, as well as minimizing the impacts of poorly-performing or resource-intensive applications on the server.

When your Web sites require FrontPage Server Extensions 2002, you can configure the extensions to use a defined local group for ACLs on Web content. This permits you to allow FrontPage authors and administrators to deploy content only on their assigned Web sites.

Finally, by deploying .NET applications that use isolated application design and side-by-side assemblies, you can strengthen application isolation and minimize versioning problems induced when multiple applications share the same code base.

Taken as a whole, some subset of the capabilities are more than sufficient, in most cases, to permit applications to be deployed on a server, while assuring that those applications are independent, secure, and available.

Top of page

Appendix

The .NET Framework, which includes ASP.NET, has capabilities that can be used to enhance application isolation. These features are implemented by software engineers in the design and implementation of the .NET applications and are not specifically related to IIS capabilities. The Windows Server 2003 platform is designed specifically to support .NET applications, making it an ideal choice for deploying highly reliable and secure Web-based applications.

Features of .NET Framework and ASP.NET That Can Be Used for Isolation

When creating applications with the .NET Framework, you have additional capabilities that can be used to create by design applications that are more fully isolated, reliable, and manageable.

.NET Applications Designed to Be Isolated Applications

.NET applications can be constructed such that they are considered isolated applications. In this context, the term isolated application has a specific meaning, which refers to a type of .NET application rather than the kind of configured application isolation referred to in the rest of this paper.

When a .NET application is designed as an Isolated application, it is more stable and reliable since it is unaffected by the installation, removal, or upgrading of other applications on the system. Isolated applications can be designed so that they always run using the same assembly versions with which they were built and tested.

Isolated applications are self-describing applications installed with manifests. Isolated applications can run on Microsoft Windows XP and later systems and can use both private assemblies and shared assemblies.

Applications built with different versions of the same assembly may run simultaneously without affecting each other's execution. The installation, removal, or upgrading of other applications on the system will not affect a fully-isolated application. An application is fully isolated if all of its components are side-by-side assemblies. It is partially isolated if it uses some assemblies, and some shared components that are not side-by-side assemblies. Most applications will be partially isolated.

Side-by-Side Assemblies

A common problem with deploying DLL-based applications occurs when there are different versions of a DLL with the same name, and both versions are required by some part of the application. This versioning problem is resolved with the use of Side-by-Side Assemblies.

A side-by-side assembly contains a collection of resources — a group of DLLs, windows classes, COM servers, type libraries, or interfaces — that are always provided to applications together. These are described in the assembly manifest. A manifest describes the assembly's contents in XML format.

Because of the intrinsic information provided in an assembly and its manifest, an application can specify which version of an assembly it requires. And, two applications requiring different versions of the same DLL can run together.

For more information about .NET application isolation and side-by-side assemblies, see http://msdn.microsoft.com/library/en-us/sbscs/setup/about_isolated_applications_and_side_by_side_assemblies.asp.

Note: ASP.NET supports running multiple versions of the .NET Framework side-by-side but only when running IIS in IIS 5.0 isolation mode.

Application Domains

The .NET Framework allows the deployment of multiple applications in the same application pool that have built-in application protection. Each .NET application running in the application pool has an application domain, and code from one domain cannot directly access objects in another domain. You can also stop and start applications within a single application pool without halting the entire application pool. This permits you to focus the enforcement of your application boundaries in the design of your application, rather than relying completely on server configuration.

Application domains provide a secure and versatile unit of processing that the common language runtime can use to provide isolation between applications. You can run several application domains in a single process with the same level of isolation that would exist in separate processes, but without incurring the additional overhead of making cross-process calls or switching between processes. The ability to run multiple applications within a single process dramatically increases server scalability. In addition, code running in one application cannot directly access code or resources from another application.

Note: You cannot unload individual assemblies or types; only a complete domain can be unloaded.

For more information on Application Domains, see http://msdn.microsoft.com/library/en-us/cpguide/html/cpconapplicationdomainsoverview.asp.

Top of page

Related Links

See the following resources for further information:

For the latest information about IIS, see the IIS Web site at http://www.microsoft.com/WindowsServer2003/iis/default.mspx. For the latest information about Windows Server 2003, see the Windows Server 2003 Web site at http://www.microsoft.com/windowsserver2003/default.mspx.

Top of page