“应用程序池标识”在应用程序池中扮演什么angular色？

这里有很多重载的术语，以及IIS 7和7.5之间的变化。

应用程序池标识与应用程序池帐户

我们从应用程序池标识开始（小写字母I，即应用程序池帐户 ）：

我告诉它的方式是， 应用程序池帐户是用来启动 应用程序池的帐户 ，以及应用程序池在不模仿其他人时所采用的身份。

因此，无论您给App Pool的身份如何，都需要能够读取内容文件夹中的文件 ：特别是（但不限于）任何web.config文件 （它们构成IISconfiguration的一部分，并控制应用程序池将会这样做）。

如果它不能访问文件夹，它会假设那里可能有一个重要的（改变游戏的）web.config文件，并显示一个错误。 所以应用程序池帐户需要读取所有内容文件夹。

ApplicationPoolIdentity

为什么区分应用程序池帐户（应用程序池的身份）和应用程序池标识？ 因为特殊资本使用的ApplicationPoolIdentity是一个新的帐户types – 一个托pipe服务帐户 – 在IIS 7.5 / Windows 2008 R2中引入并设置了默认值，并且也可以从Windows 2008 SP2（但不是默认值）获得。

请参阅IIS.Net上的应用程序池标识

当您使用GUI在R2下创build网站时：

• 将创build一个应用程序池来托pipe该网站
• 帐户types将是ApplicationPoolIdentity，而不是networking服务（2008默认值），本地服务或本地系统。

使用2008 RTM时，默认的应用程序池帐户是networking服务加上一个独特的应用程序池标识/独特者; 新的R2 / SP2 AppPoolIdentity 帐户types是一个类似于networking服务的帐户（即，当连接到离线框时，是计算机），但防止在同一个框中模拟另一个应用程序池。

回到原来的问题：

• 应用程序池帐户定义了您的应用程序运行的时间， 因为它不是冒充其他人

• 身份validation方法描述了如何对客户端进行身份validation（以模拟他们）

• 匿名用户帐户定义了在为未经身份validation的请求模拟用户时要运行的用户 – IUSR就是这样的用户。

顺便提一句，在IIS 7.5中，您可以将匿名用户帐户设置为应用程序池标识（匿名身份validation方法的属性），这可能会更直接地隔离和保护给定网站的内容。

使用IIS AppPool \ YourSiteName为名称格式设置权限。 （另见这篇文章 ）

你看到了两件事情，一般在ASP.NET中感到困惑：

1. “用户身份” – 用户帐户的身份validation与在II和ASP.NET下实际运行的帐户或身份无关。 匿名身份validation允许任何用户访问任何公共内容，而不会向客户端浏览器提供用户名和密码质询。 默认情况下在IIS中获得身份validation的匿名IUSR帐户只适用于访问公共网站内容。 它不会影响底层II或ASP.NET服务使用的进程或资源。
2. “应用程序标识” – 这是实际在IIS和ASP.NET后面运行的服务器上的实际“WindowsIdentity”帐户，它是由IIs分配给池并提供给ASP.NET的应用程序池标识帐户。 您的ASP.NET进程在默认情况下在此应用程序池标识帐户（在IIs版本7.5+中称为虚拟帐户）下运行。

说明：首先，ASP.NET中的“身份validation”只是一个通常在web.config中设置的事件，该事件logging在给定的用户帐户中，该帐户作为普通的HttpContext对象作为用户令牌由IIs传递给ASP.NET。即当前会话或当前用户的上下文。 它实际上并没有改变运行ASP.NET进程的WindowsIdentity，只是传递一个用户id令牌给它。 使用HttpContext，您的代码可以使用该ID或名称来存储您的网站的各个部分的数据库权限。 但它不会影响ASP.NET的文件访问，因为它不会影响或更改在IIs下运行ASP.NET的实际应用程序“进程”帐户的标识。

这不会发生，直到你做“模拟”告诉ASP.NET模拟任何令牌被传递给它的IIs，然后在该帐户ID下运行。 你可以在你的web.config中设置模拟。 当您在ASP.NET中激活模拟时，WindowsIdentity会在工作进程上更改为通过身份validation的帐户从IIS传递到ASP.NET，然后您可以访问文件，当然基于您分配该用户帐户的权限。 在发生临时事件时，需要注意的一点是，ASP.NET可以恢复到当前IIs版本的默认进程标识，即再次分配给给定应用程序池的应用程序池标识帐户。

当IIs仅使用纯粹的匿名用户帐户而没有在ASP.NET中设置显式validation时，IIs默认启动网站分配的应用程序池的应用程序池标识帐户，并将其传递给ASP.NET以及运行它的工作进程。 该应用程序池标识帐户将处理对IIS的所有请求，并为该站点运行ASP.NET。

当IIs在此设置下启动并且被用户访问时，它实际上在默认情况下对匿名IUSR账户进行身份validation，该账户确定对网页和其他基本资源的访问。 但是，该帐户不传递给ASP.NET。 它不会影响IIS运行的应用程序池标识以及运行在哪个ASP.NET下。

如果在你的web.config中设置Impersonate为“true”，并且在IIs中使用默认的匿名IUSR帐户进行公共访问，并且你在web.config中显式设置了anonymousAuthentication属性（而不是使用Windows或其他login帐户），IIs将抛出应用程序池标识和II和ASP.NET将现在运行他们的应用程序进程作为匿名的IUSRauthentication和模拟帐户。

当你这样做ASP.NET及其进程现在将在IUSR帐户下运行….即ASP.NET的应用程序进程将运行其WindowsIdentity帐户作为IUSR帐户。 现在，您可以对该匿名IUSR帐户以及您希望该帐户访问的文件夹应用读/写访问权限。 （注意：不过要确保添加默认进程帐户，池的应用程序池帐户，以及这些文件夹的权限，这是根据微软的build议）

祝你好运！

有两个authentication上下文在玩。 Web服务器进程（处理您的Web请求）作为App Pool Identity用户运行。 当您的虚拟主机发出请求时，应用程序池将模拟特定站点的“匿名身份validation凭据”中列出的用户 – 默认情况下为IUSR。

任何从您的网站运行的脚本都将作为IUSR运行，但是日志logging和某些其他function将作为App Pool User运行（默认情况下为networking服务 – 虽然最近已更改为使用特殊的虚拟应用程序池用户）。 应用程序池标识（networking服务）需要能够列出目录中的文件，因为在将控制权交给脚本之前，请求堆栈中会进行特定的检查。

在每个池中运行一个站点是一个很好的做法，并将App Pool Identity设置为与您网站的匿名用户相同的用户运行。 有可能摆脱匿名用户上下文（IUSR）并将权限提升到App池标识本身的权限。