“应用程序池标识”对于应用程序池起什么作用？

在谈论IIS 7.5安全性时，AFIAK：

应用程序池标识确定我的Web应用程序以谁运行。

验证方法决定谁的客户端认证为。

我有一个配置如下的虚拟文件夹：

• 我使用匿名身份验证，期望所有客户端都应被身份验证为IUSR。
• 我让IUSR完全控制该文件夹。
• 我的应用程序池标识设置为XXX帐户，该帐户对该文件夹没有任何权限。（我有意设置了这个）

但事实证明，我无法浏览该文件夹中的文件。一旦我授予XXX帐户访问该文件夹的权限，一切就会顺利进行。

那么，App Pool Identity在匿名身份验证中扮演什么角色？我必须授予App Pool Identity帐户访问该文件夹的权限，这完全出乎意料。我认为匿名身份验证就足够了吗？

谢谢。

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

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

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

按照我的说法，应用程序池帐户是用于启动应用程序池的帐户，并且是应用程序池在不假冒其他任何人时所采用的身份。

因此，无论您赋予应用程序池什么身份，都需要能够读取内容文件夹中的文件：特别是{但不限于}任何web.config文件（它们构成IIS配置的一部分，并控制应用程序池将要做）。

如果无法访问文件夹，则假定其中可能存在重要的（改变游戏规则的）web.config文件，并显示错误。因此，应用程序池帐户需要对所有内容文件夹具有读取权限。

应用程序池标识

为什么要区分应用程序池帐户（应用程序池的标识）和应用程序池标识？因为使用特殊大写字母的ApplicationPoolIdentity是一种新帐户类型 -托管服务帐户-在IIS 7.5 / Windows 2008 R2中引入并默认设置，并且也可以在Windows 2008 SP2中使用（但不是默认值）。

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

使用GUI在R2下创建网站时：

• 将创建一个应用程序池来托管该网站，并且
• 帐户类型将为ApplicationPoolIdentity，而不是网络服务（默认为2008），本地服务或本地系统。

对于2008 RTM，默认的应用程序池帐户是网络服务以及唯一的应用程序池标识/唯一符；新R2 / SP2 AppPoolIdentity 帐户类型是网络服务- 像帐户（即连接断开框时是计算机），但相同的盒子内的另一应用程序池的防止假冒。

回到原始问题：

• 应用程序池帐户定义谁您的应用程序运行的时候它不是模仿别人

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

• 该匿名用户帐户定义你要冒充为未通过身份验证请求的用户在作为运行谁- IUSR是这样的用户。

顺便说一下，使用IIS 7.5，您可以将匿名用户帐户设置为应用程序池标识（匿名身份验证方法的属性），这可以使为给定网站隔离和保护内容更加直接。

使用IIS AppPool \ YourSiteName作为名称格式设置权限。（另请参阅此帖子）

您会看到两件事，在ASP.NET中通常很困惑：

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

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

直到您执行“模拟”，告诉ASP.NET模仿IIs传递给它的任何令牌，然后以该帐户ID运行之后，这种情况才会发生。您可以在web.config中设置模拟。当您在ASP.NET中激活模拟时，WindowsIdentity确实会在工作进程上更改为从IIS传递到ASP.NET的身份验证帐户，然后您就可以访问文件，当然这取决于您为该用户帐户分配的权限。重要的是要注意，这是临时的，ASP.NET可以还原为其默认进程身份，在当前的IIs版本中，该身份也是分配给给定应用程序池的应用程序池身份帐户。

当IIs仅使用在ASP.NET中未设置显式身份验证的普通匿名用户帐户时，IIs默认情况下会启动网站分配的应用程序池的应用程序池标识帐户，并将其传递给ASP.NET和运行它的辅助进程。该应用程序池标识帐户处理所有对IIS的请求，并为该站点运行ASP.NET。

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

如果您在说web.config时将Impersonate设置为“ true”，并且您正在使用IIs中的默认匿名IUSR帐户进行公共访问，并且您在web.config中显式将匿名身份验证属性设置为true（而不是使用Windows或其他登录帐户），II将放弃应用程序池标识，II和ASP.NET现在都将以匿名IUSR身份验证和模拟帐户运行其应用程序进程。

当您执行该操作时，ASP.NET及其进程现在将在IUSR帐户下运行..即，ASP.NET的应用程序进程将其WindowsIdentity帐户作为IUSR帐户运行。现在，您可以对该匿名IUSR帐户以及您希望该帐户访问的文件夹应用读/写访问权限。（注意：但是请确保将默认进程帐户，该池的应用程序池帐户以及这些文件夹的权限添加到该文件夹​​。这是根据Microsoft的建议）

祝好运！

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

在您网站上运行的所有脚本都将以IUSR的身份运行，但日志记录和某些其他功能将以应用程序池用户的身份运行（默认情况下，网络服务-尽管最近已更改为使用特殊的虚拟应用程序池用户）。应用程序池标识（网络服务）需要能够列出目录中的文件，因为在将控制权移交给脚本之前，在请求堆栈中已进行了某些检查。

优良作法是每个池运行一个站点，并将应用程序池标识设置为与您的网站的匿名用户相同的用户身份运行。可以突破匿名用户上下文（IUSR）并将特权提升为应用程序池身份本身的特权。