目标
简介
Windows 2000 上的 ASP.NET 体系结构
Windows Server 2003 上的 ASP.NET 体系结构
用标识隔离应用程序
用应用程序池隔离应用程序
用代码访问安全隔离应用程序
窗体身份验证的问题
UNC 共享寄宿
小结
简介
在共享宿主场景中，确保应用程序不会对其他应用程序的操作和安全产生负面影响，是非常重要的。
获得应用程序独立有许多方式。可用的选择因 Web 服务器上运行的 .NET Framework 的版本和操作系统的版本的不同而不同。
如果运行的是 .NET Framework 的 1.1 版本，可以使用代码访问安全提供的资源约束模型提供一层应用程序独立。这种应用程序独立是通过限制应用程序访问不同类型的资源（如文件系统、注册表、事件日志、Active Directory、数据库、网络资源等等）而实现的。
Windows Server 2003 通过 Internet 信息服务 6.0 (IIS 6) 应用程序池提供了进程独立，可以使多个应用程序运行在不同的 IIS 辅助进程实例中。进程独立在 Windows 2000 上是不可能的，因为所有 Web 应用程序都运行在单独的 ASP.NET 辅助进程实例中，而应用程序域提供了独立性。
表 1 总结了 Windows 2000 和 Windows Server 2003 上应用程序独立的各种选择。
运行着 .NET Framework 1.1 版的 Windows Server 2003 是寄宿多个 ASP.NET 应用程序的推荐平台，因为它支持进程独立，并为应用程序独立提供了最大范围的选择。
Windows 2000 上的 ASP.NET 体系结构
在 Windows 2000 上，多个 Web 应用程序运行在一个 ASP.NET 辅助进程 (Aspnet_wp.exe) 实例中。每个应用程序都驻留在自己的应用程序域中，为托管代码提供了一定程度的独立性。Windows 2000/IIS 5 体系结构如图 1 所示。
图 1. 带有 IIS 5 的 Windows 2000 上的 ASP.NET 体系结构
表 2 总结了图 1 中所描述的体系结构的组成部分
Windows Server 2003 上的 ASP.NET 体系结构
在 Windows Server 2003 上，体系结构有所改变，因为 IIS 6 允许多个进程用于寄宿不同的 Web 应用程序。此体系结构如图 2 所示。
注 IIS 6 支持向后兼容模式，从而能够支持 IIS 5 ASP.NET 辅助进程模型。
图 2. 带有 IIS 6 的 Windows Server 2003 上的 ASP.NET 体系结构
与 Windows 2000 下的 ASP.NET 体系结构相比，Windows Server 2003 中的主要区别在于可以用不同的 IIS 辅助进程实例 (W3wp.exe) 寄宿 Web 应用程序。默认时，这些应用程序是使用 NT Authority\NetworkService 帐户运行的，这是一个最低特权本地帐户，它用作跨网络的计算机帐户。运行在网络服务帐户环境下的 Web 应用程序需要给远程服务器提供计算机的凭据以进行身份验证。
为网络服务配置 ACL
为网络服务帐户配置访问控制列表 (ACL) 的过程，对于本地和远程机器而言是不同的。如果要授予本地机器上的网络服务帐户访问权限，需要将网络服务帐户添加到 ACL 中。如果要授予远程机器上的网络服务帐户访问权限，需要将 DomainName\MachineName$ 帐户添加到 ACL 中。
注 不要把网络服务帐户与内置的网络组搞混淆了，后者包括的是跨网络进行身份验证的用户。
表 3 总结了图 2 中所描述的体系结构的主要组成部分。
用标识隔离应用程序
从操作系统标识的观点来看，可以通过控制用来运行每个应用程序的帐户标识隔离 ASP.NET Web应用程序。如果每个应用程序使用不同的固定帐户标识，就可以分别授权和审核每个应用程序。
注 如果要寄宿使用 .NET Framework 1.0 版构建的 ASP.NET Web应用程序，进程帐户需要适当的对当前文件系统驱动器根的访问权限。有关更多信息，请参阅 Microsoft 知识库文章 317955“FIX:'Failed to Start Monitoring Directory Changes' Error Message When You Browse to an ASP.NET Page”。
如果共享 Web 服务器上每个应用程序要想都使用不同的固定标识，可以采用两种方式：
匿名帐户模拟
固定标识模拟
匿名帐户模拟
通过匿名帐户模拟，应用程序可以模拟 IIS 指定、并为应用程序的虚拟目录配置的匿名帐户。如果您的应用程序要独立于 IIS 对用户进行身份验证（如，通过使用窗体或者 Microsoft Passport 身份验证），就可以使用此方式。在这些情况下，可以通过使用固定的匿名帐户隔离应用程序。一旦调用方通过了身份验证，角色也经过了检查，就可以将可信服务器模型用于下游的资源访问，其中已配置的匿名帐户提供了可信的标识。
为了支持这一方式，IIS 中的应用程序虚拟目录必须支持匿名访问，必须为每个应用程序配置不同的匿名帐户。应用程序然后必须配置为模拟。这种方式如图 3 所示。本地和远程资源访问假设使用模拟的匿名帐户的安全上下文。
图 3. 用于每个应用程序的多个匿名帐户
为了使用多个匿名帐户进行资源访问
此过程叙f20secmod03.gif述了如何使用多个匿名帐户（每个 Web 应用程序一个）进行资源访问，以支持单独的应用程序授权和审核。
1. 创建新的匿名用户帐户，每个应用程序一个。
有关创建匿名用户帐户的更多信息，请参阅“保护 Web 服务器的安全”单元中的“帐户”部分。
如果需要使用匿名帐户访问远程资源，要么使用一个最低特权域帐户，要么使用本地帐户，在远程服务器上使用匹配的用户名和密码创建一个重复的本地帐户。
2. 使用 标记在 Machine.config 中配置每个 Web 应用程序为模拟。
allowOverride="false" 设置防止了单个的应用程序改写 Web.config 文件中的这一设置。有关 元素的更多信息，请参阅“保护 ASP.NET 应用程序的安全”单元中的“Machine.config 和 Web.config 详解”部分。
3. 使用 Internet 服务管理器配置每个应用程序的虚拟目录，以使用不同的匿名用户帐户。
1. 从管理工具程序组启动 Internet 服务管理器。
2. 选择应用程序的应用程序目录，鼠标右键单击，然后单击 Properties。
3. 单击 Security 选项卡，然后单击 Edit 按钮。
4. 确保选择了 Anonymous access，然后单击 Edit。
5. 输入已创建的匿名帐户的用户名，或者单击 Browse，从列表中选择用户名。
6. 如果想使用帐户访问远程资源，请清除匿名帐户的 Allow IIS to Control Password 复选框。
如果选择了 Allow IIS to Control Password，使用指定匿名帐户创建的登录会话的网络凭据将为 NULL，而且不能用于访问必需进行身份验证的网络资源。如果清除了这一复选框，登录会话将是一个需要网络凭据的交互式登录会话。但是，如果帐户是机器本地帐户，则网络上其他机器都无法对此帐户进行身份验证。在此情况下，应该在目标远程服务器上创建一个重复帐户。
注 所创建的登录会话的类型是由 LogonMethod IIS 元数据库设置控制的。默认时是交互式登录会话，需要具有“Allow Log on Locally”用户特权的帐户。
IIS 6 上没有 Allow IIS to Control Password 选项。IIS 6 将默认的 LogonMethod 设置为 Network Cleartext，这要求帐户有“Access this computer from the network”用户特权。这使帐户由网络服务器进行身份验证。
4. 为每个帐户配置 NTFS 权限，以确保每个帐户都有只访问适当的文件系统文件和文件夹的权限，而不能访问关键的资源（如操作系统工具）。
有关为匿名帐户配置 NTFS 权限的更多信息，请参阅单元“保护 Web 服务器的安全”。
注 如果运行 IISLockdown 向导，它将创建一个 Web 匿名用户组。该组的成员将被拒绝访问系统目录和工具。
固定标识模拟
如果需要 IIS 为应用程序对用户进行身份验证（例如，通过使用集成 Windows 身份验证或者证书身份验证），可以使用一个固定模拟标识来执行 ASP.NET 应用程序。此场景如图 4 所示。
图 4. 应用程序模拟一个固定帐户，并使用它访问资源
可以配置单独的 ASP.NET 应用程序模拟一个固定帐户。这种配置的好处在于，它可以用于任何 IIS 身份验证方法，而且无需 IIS 匿名身份验证。
