Host multiple asp.net applications

Asp.net| Program

Summary of this module
Microsoft®windows®server 2000 and the Windows server™2003 operating system provide a very scalable, very reliable Web hosting environment. They can be used to securely host hundreds of web sites and ASP.net applications on a Web server or Web server farm.

However, when using ASP.net applications in a shared hosting scenario, you must consider how to make applications independent of each other, as well as separate from shared system resources, including file systems, registry, and event logs. Without sufficient independence, malicious or poorly designed applications can adversely affect other applications on the server or access unauthorized resources. This application independence is particularly important for Internet service providers (ISPs) of large numbers of applications hosted by different companies.

This module describes what technologies can be used to isolate ASP.net applications in Windows 2000 and 2003 to ensure the integrity, confidentiality, and authenticity of the hosted Web site data.

Back to the top of the page
Goal
Through this module can:

• Understand the architecture and major components of ASP.net in Windows 2000 and 2003.

• Use multiple identities, application pools, and code access security to isolate Web applications.

• Configure anonymous account impersonation.

• Configure fixed account impersonation to access local or remote resources when using integrated Windows authentication or certificates to authenticate users.

• Improve the security of forms authentication.

• Understand how credentials are used when accessing data stored in a UNC share.

Back to the top of the page
Application Range
This module applies to the following products and technologies:

Microsoft Windows Server 2000 and 2003

Microsoft. NET Framework 1.1 and ASP.net 1.1

Back to the top of the page
How to use this unit
This module focuses on how to gain application independence in a shared hosting environment. The key element is code access security. This unit should also be used in conjunction with the following elements:

• Read Unit 8, "Code access security practices." The unit explains in more detail how code access security works and how to use it to constrain individual assemblies, such as the ability to restrict assemblies ' access to file systems, registries, networks, and other critical resources.

• Reading Unit 9 "Using code access Security in ASP.net". The unit explains how to use code access security policy for ASP.net applications, and discusses the considerations and implications of building partial-trust applications.

• Read Unit 16, "Securing Your Web Server." This unit describes how to protect the Windows 2000 operating system and the Microsoft. NET Framework. A secure underlying platform is a prerequisite for securing a asp.net Web application or Web service.

Content of this page
Summary of this module
Goal
Application Range
How to use this unit
Brief introduction
asp.net architecture on Windows 2000
asp.net architecture on Windows Server 2003
Isolating applications with identities
Isolating applications with application pools
Using code access security isolation applications
Problems with Forms authentication
UNC Share Boarding
Summary

Back to the top of the page
Brief introduction
In a shared hosting scenario, it is important to ensure that the application does not adversely affect the operation and security of other applications.

There are many ways to gain application independence. The available selections vary depending on the version of the. NET Framework running on the WEB server and the version of the operating system.

• If you are running version 1.1 of the. NET Framework, you can use the resource constraint model provided by code access security to provide a layer of application independence. This application is independent by restricting application access to different types of resources, such as file systems, registries, event logs, Active Directory, databases, network resources, and so on.

Windows Server 2003 provides process independence through the Internet Information Services 6.0 (IIS 6) application pool, which enables multiple applications to run in different instances of the IIS worker process. Process independence is not possible on Windows 2000, because all WEB applications run in separate asp.net worker process instances, and application domains provide independence.

Table 1 summarizes the various options for application independence on Windows 2000 and Windows Server 2003.

Table 1 Application-independent features on Windows 2000 and Windows Server 2003
Standalone features windows Windows Server 2003
Process Independent
Whether
Yes (IIS 6 application pool)

Application domain Independence
Is
Is

Multiple thread identities
Is
Is

Code Access security Resource constraints
Yes (. NET Framework version 1.1)
Yes (. NET Framework version 1.1)

Windows Server 2003, which runs the. NET Framework version 1.1, is the recommended platform for hosted multiple asp.net applications because it supports process independence and provides the widest range of choices for application independence.

Back to the top of the page
asp.net architecture on Windows 2000
On Windows 2000, multiple WEB applications run in a asp.net worker process (aspnet_wp.exe) instance. Each application resides in its own application domain, providing some degree of independence for managed code. The Windows 2000/iis 5 architecture is shown in Figure 1.

Figure 1. asp.net architecture on Windows 2000 with IIS 5

Table 2 summarizes the components of the architecture described in Figure 1

Table 2 Windows asp.net architecture components
Part	Description
Inetinfo.exe	The primary IIS process. Run the Windows service under the local SYSTEM account.
Aspnet_isapi.dll	The IIS script Map associates the ASP.net file type with the ISAPI extension of the asp.net that runs within Inetinfo.exe. It is responsible for forwarding the request to the ASP.net worker process through an asynchronous named pipe. It also initiates the worker process and performs health monitoring. The ISAPI extension does not contain managed code and does not itself perform request processing.
Aspnet_filter.dll	A lightweight ISAPI filter that is used only to support ASP. NET application has no cookie-free session state. The Aspnet_filter.dll runs inside the Inetinfo.exe.
aspnet_wp.exe	asp.net the worker process. Host multiple WEB applications in different application domains (for providing independence). Usually one instance per server, although on multiprocessor servers, Web garden mode supports multiple identical processes with a given processor relationship. It is not possible to separate multiple specific Web applications into different processes. IIS 6 and Windows Server 2003 are required. aspnet_wp.exe runs with the local ASPNET account, although you can also use a custom account.
Aspnet_state.exe	An optional Windows service that stores the session state of an ASP.net application. Aspnet_state.exe can be run on either a Web server or a remote machine (required in the case of a Web server farm). Aspnet_state.exe runs under the local ASPNET account, although you can use a custom account to configure it through the Services snap-in.

Back to the top of the page

asp.net architecture on Windows Server 2003

On Windows Server 2003, the architecture has changed because IIS 6 allows multiple processes to be hosted on different WEB applications. This architecture is shown in Figure 2.

Note IIS 6 supports backward compatibility mode, enabling the IIS 5 asp.net worker process model to be supported.

Figure 2. asp.net architecture on Windows Server 2003 with IIS 6

The main difference in Windows Server 2003, compared to the ASP.net architecture under Windows 2000, is that you can host Web applications with different IIS worker process instances (W3wp.exe). By default, these applications are run using the NT authority\networkservice account, which is a least privileged local account that is used as a computer account across the network. Web applications running in the context of a network Service account need to provide the remote server with the credentials of the computer for authentication.

Configuring ACLs for Network Services

The process of configuring access control lists (ACLs) for network service accounts is different for local and remote machines. If you want to grant access to the Network Service account on the local machine, you need to add the Network Service account to the ACL. If you want to grant access to the Network Service account on the remote machine, you need to add the domainname\machinename$ account to the ACL.

Note Do not confuse the Network Service account with the built-in Network group, which includes users who authenticate across the network.

Table 3 summarizes the main components of the architecture described in Figure 2.

Table 3 Components of the Windows Server 2003 asp.net architecture
Part	Description
Aspnet_isapi.dll	Requests the ASP.net managed code engine to process and perform health monitoring queues.
Aspnet_filter.dll	A lightweight ISAPI filter that is used only for stateless session state that supports ASP.net applications. The Aspnet_filter.dll runs inside the W3wp.exe.
W3wp.exe	The IIS worker process, which contains the ASP.net managed code processing engine. The URL space can be arbitrarily delimited in different W3wp.exe instances that use the IIS 6 application pool. Web garden mode is also supported. Requests are routed directly from the http.sys running in kernel mode to the W3wp.exe process instance. By default, the process runs under the Network Service account, but can be configured.
Aspnet_state.exe	An optional Windows service that stores the session state of the ASP.net application. Aspnet_state.exe can be run on either a Web server or a remote machine (required in the case of a Web server farm). Run under the Network Service account, but can be configured with the Services snap-in.

Back to the top of the page

Isolating applications with identities

From the standpoint of the operating system identity, you can isolate ASP.net Web applications by controlling the account identity used to run each application. If each application uses a different fixed account identity, each application can be authorized and audited separately.

Note If you want to host a asp.net Web application built using the. NET Framework version 1.0, the process account requires appropriate access to the root of the current file system drive. For more information, see Microsoft Knowledge Base article 317955 "FIX: ' Failed to Start monitoring Directory Changes ' Error messages when you are Sp.net Page ".

If each application on a shared Web server wants to use a different fixed identity, there are two ways to do it:

•	Anonymous account Impersonation
•	Fixed identity Impersonation

Anonymous account Impersonation

With Anonymous account impersonation, an application can impersonate an anonymous account that is specified by IIS and configured for the application's virtual directory. You can use this approach if your application is to authenticate users independently of IIS (for example, by using forms or Microsoft Passport authentication). In these cases, you can isolate the application by using a fixed anonymous account. Once the caller is authenticated and the role is checked, the trusted server model can be used for downstream resource access, where the configured anonymous account provides a trusted identity.

To support this approach, the application virtual directory in IIS must support anonymous access, and you must configure a different anonymous account for each application. The application must then be configured for impersonation. This approach is shown in Figure 3. Local and remote resource access assumptions use the security context of the impersonated anonymous account.

Figure 3. Multiple anonymous accounts for each application

To use multiple anonymous accounts for resource access

This process describes how to use multiple anonymous accounts (one per WEB application) for resource access to support individual application authorization and auditing. F20secmod03.gif

1.	Create a new anonymous user account, one for each application. For more information about creating anonymous user accounts, see the "Accounts" section in the "Securing the Web Server" unit. If you need to use an anonymous account to access a remote resource, either use a least privileged domain account, or use a local account to create a duplicate local account on the remote server using a matching username and password.
2.	Use the <location> tag to configure each WEB application in Machine.config for impersonation. <location path= "Web Site name/vdirname" allowoverride= "false" > <system.web> <identity Impersonate= "true"/> <system.web><location> The allowoverride= "false" setting prevents a single application from overwriting this setting in the Web.config file. For more information about <location> elements, see the "Machine.config and Web.config Details" section of the "Securing ASP.net Applications" unit.
3.	Use Internet Services Manager to configure the virtual directory for each application to use a different anonymous user account. 1. Start Internet Services Manager from the Administrative Tools program group. 2. Select the application's application directory, right-click, and then click Properties. 3. Click the Security tab, and then click the Edit button. 4. Make sure Anonymous accessis selected, and then click Edit. 5. Enter the user name of the anonymous account you have created, or click Browseto select a user name from the list. 6. If you want to use an account to access remote resources, clear the Allow IIS to control Password check box for the anonymous account. If you select Allow IISto control Password, the network credentials for the logon session created with the specified anonymous account will be NULL and cannot be used to access network resources that are required for authentication. If this check box is cleared, the logon session will be an interactive logon session that requires network credentials. However, if the account is a machine local account, the account cannot be authenticated by other machines on the network. In this case, you should create a duplicate account on the target remote server. Note the type of logon session that you create is controlled by the LogonMethod IIS metabase setting. The default is an interactive logon session that requires an account with "Allow Log on Locally" user privileges. There is no Allow IIS to control Password option on IIS 6. IIS 6 Sets the default LogonMethod to network cleartext, which requires the account to have "Access this computer from the network" user privileges. This causes the account to be authenticated by the network server.
4.	Configure NTFS permissions for each account to ensure that each account has access to only the appropriate file system files and folders, and does not have access to critical resources such as operating system tools. For more information about configuring NTFS permissions for anonymous accounts, see the unit "Securing Web servers." Note If you run the IISLockdown Wizard, it will create a Web anonymous user group. Members of this group will be denied access to the system directories and tools.

Fixed identity Impersonation

If IIS is required to authenticate users to the application (for example, by using Integrated Windows authentication or certificate authentication), a fixed impersonation identity can be used to execute the asp.net application. This scenario is shown in Figure 4.

Figure 4. The application simulates a fixed account and uses it to access resources

You can configure a separate ASP.net application to simulate a fixed account. The benefit of this configuration is that it can be used for any IIS authentication method and does not require IIS anonymous authentication.

To use multiple fixed impersonation accounts for resource access

This process describes how to use multiple fixed impersonation accounts (one per WEB application) for resource access to support separate application authorization and auditing.

1.	Create a new anonymous user account, one for each application. For more information about creating anonymous user accounts, see the "Accounts" section in the "Securing the Web Server" unit. If you need to use an anonymous account to access a remote resource, either use a least privileged domain account, or use a local account to create a duplicate local account on the remote server using a matching username and password.
2.	Store encrypted account credentials in the registry. Run Aspnet_setreg.exe encrypted credentials that store the new account in the registry. For more information, see Microsoft Knowledge Base article 329290 How to: Encrypt credentials and session state connection strings using the ASP.net utility.
3.	Configure the Web application for impersonation. Can be implemented in Machine.config or web.config. In order to configure multiple applications with different identities, you can use the <location> tags in machine.config. Running the aspnet_setreg.exe output in the steps above will display the required format for the userName and password property values of the <identity> element. Some examples are shown below. <location path= "Web Site Name/appvdir1" allowoverride= "false" > <system.web> <identity Impersonate= "true" username= "Registry:hklm\software\yourapp1\identity\aspnet_setreg,username" password= "Registry:hklm\software\yourapp1\identity\aspnet_setreg,password"/> </system.web> </location><location path= "Web Site Name/appvdir2" allowoverride= "false" > <system.web> <identity impersonate= "true" username= "Registry:hklm\software\yourapp2\identity\aspnet_setreg, UserName " password=" registry:hklm\software\yourapp2\identity\aspnet_setreg,password "/> < /system.web></location> To configure application-level impersonation, use a <identity> element in the application's Web.config file, as shown below. <identity impersonate= "true" username= "Registry:hklm\software\yourapp\identity\aspnet_setreg,username" password= "Registry:hklm\software\yourapp\identity\aspnet_setreg,password
4.	Configure NTFS permissions for each account to ensure that each account has access to the appropriate file system files and folders and does not have access to critical resources such as operating system tools. For more information about configuring NTFS permissions for anonymous accounts, see the unit "Securing Web servers."

Note on Windows 2000 and. NET Framework version 1.0, if you simulate a fixed identity by using the above configuration, you must grant "Act as part of" to the ASP.net process account that is used to run the WEB application perating system "privilege. This is contrary to the principle of minimum privilege. It is recommended that you upgrade to the. NET Framework version 1.1, which is no longer required.

Back to the top of the page

Isolating applications with application pools

If your application is running on Windows Server 2003, you can use application pools and configure each application to run in its own worker process, which can provide process-level independence. By default, all applications run in a default application pool. With application pools, you can configure each process to run with a different identity, so you do not need to use impersonation.

To provide process-level independence

1.	Create a new set of Windows accounts, one for each application, to run each worker process instance.
2.	Configure NTFS permissions for each account to ensure that each account has access only to the appropriate file system files and folders, and does not have access to critical resources such as operating system tools. For more information about configuring NTFS permissions for anonymous accounts, see the unit "Securing Web servers."
3.	Disables WEB application impersonation. This can be accomplished in Machine.config or web.config. To disable impersonation of multiple applications in Machine.config, place <identity> elements in the <location> element, as shown below. Use the following configuration. This configuration will not be emulated. <location path= "Web Site Name/appvdir1" allowoverride= "false" > <system.web> <identity Impersonate= "false" </system.web></location> Note ASP. NET application is not emulated by default.
4.	Create new application pools and configure them to run under the new account. Using IIS 6 to create a new application pool with the default settings, use the account created in step 1 to configure the identity of each pool so that each pool runs with a different identity.
5.	Configure each application to run in its own application pool. In each IIS application's Directory tab, select the application pool to run for your application.

Back to the top of the page

Using code access security isolation applications

In version 1.1 of the. NET Framework, you can usethe < trust > element Configuration application to run at a partial-confidence level. The following configuration describes how to configure the trust level of an application from Machine.config. In this example, the Medium trust level is used.

<location path= "Web Site Name/appvdir1" allowoverride= "false" >  <system.web>    <trust level= " Medium "Originurl=" "/>  </system.web></location>

If you configure an application to run with a trust level other than "full", the application's access security permissions for a specific resource type will be restricted. In this way, you can constrain applications, prevent them from interacting with each other, and gain access to system-level resources, such as the file system, registry, event logs, and so on restricted zones.

For more information about the ASP.net trust level and how to use them to provide application independence and considerations for application-specific design and development, see the "Using Code access security in ASP.net" unit.

Note If you use code access security to provide application independence, you should also consider the application's operating system identity. The recommended standalone model is a combination of code access security and process-level independence on Windows Server 2003.

Back to the top of the page

Problems with Forms authentication

If you use Forms authentication in version 1.0 of the. NET Framework, you should use a different cookie path and name. If not, a user who is authenticated in an application may request another application without redirecting to the application's login page. The URL authorization rule in the second application may deny access to this user even if the opportunity to use the login form to provide logon credentials is not given.

To avoid this problem, each application's <forms> element uses a unique cookie path and name attribute, and each application uses a different machine key.

Version 1.1 of the. NET Framework supports the IsolateApps setting shown below.

<machinekey validationkey= "Autogenerate,isolateapps"            decryptionkey= "Autogenerate,isolateapps" validation= "SHA1"/>

This ensures that each application on the machine uses a different key to encrypt and verify the form authentication cookie and view state.

In version 1.0 of the. NET Framework, IsolateAppscannot be used, and <MachineKey> elements must be generated manually. For more information about this issue, see the following article in the Microsoft Knowledge Base.

•	313116 "Prb:forms authentication Requests Are not directed to Loginurl Page"
•	312906 "How To:create Keys by Using Visual C #. NET for use in Forms authentication"

Back to the top of the page

UNC Share Boarding

If you are running an application that has content in a universal naming convention (UNC) share, the credentials used to access the share are either the application's credentials or the credentials of the authenticated client. This is configured by the administrator in IIS.

When the application is configured so, ASP.net simulates the security context of the token that it received from IIS. This cannot be configured through the <identity> tag unless explicit credentials are provided.

In version 1.0 of the. NET Framework, use Mscorcfg.msc to create a code group based on the URL and grant it full trust.

When you host an ASP.net application with a virtual directory that points to a remote share, you may receive a security exception. For more information, see the Microsoft Knowledge Base article 320268 "PRB:System.Security.SecurityException:Security error" error message when the Virtual D Irectory Points to a Remote Share in asp.net. ”

Back to the top of the page

Summary

If you are hosting multiple asp.net applications on a WEB server, you need to consider the independence between applications and between applications and shared system resources such as file systems, registries, and event logs. Without sufficient independence, malicious or poorly designed applications can negatively impact other applications on the server.

On Windows Server 2003, use the multiple worker process model supported by IIS 6 to provide an operating system process independence for your application. On Windows 2000, process independence is not possible, although multiple applications can be configured to use different anonymous user accounts. This provides a separate application audit and supports independent application authorization.

On two platforms, you can use the resource constraint model provided by code access security as an additional control to restrict which applications have access to which resource types. In ASP. NET application, the. NET Framework version 1.1 is required to use code access security.

For more information about securing ASP.net applications, see the "Securing ASP.net Applications" unit.