当谈到 IIS 7.5 安全性时，据我所知：
应用程序池标识决定谁我的 Web 应用程序运行为。
身份验证方法决定谁客户端被认证为。
我有一个配置如下的虚拟文件夹：
- 我使用匿名身份验证，期望所有客户端都应进行身份验证独立专家。
- 我授予 IUSR 对该文件夹的完全控制权。
- 我的应用程序池身份设置为XXX帐户，该帐户对该文件夹没有任何权限。 （我故意这样设置的）
但结果显示我无法浏览该文件夹中的文件。一旦我授予XXX帐户访问该文件夹的权限，一切就都好了。
那么应用程序池标识在匿名身份验证中起什么作用？完全出乎意料的是，我必须授予应用程序池标识帐户访问该文件夹的权限。我以为匿名身份验证就足够了？
谢谢。
答案1
这里有很多重载术语，并且 IIS 7 和 7.5 之间存在变化。
应用程序池身份与应用程序池帐户
让我们从应用程序池标识（小写的 i 标识，我称之为应用程序池帐户以避免歧义）：
我是这样说的，应用程序池帐户账户用于引导应用程序池，以及应用程序池未冒充任何其他人时所假定的身份。
因此，无论你赋予应用程序池什么身份，它都需要能够读取内容文件夹中的文件：特别是{但不限于}任何web.config 文件（它构成 IIS 配置的一部分，并控制应用程序池要执行的操作）。
如果它无法访问某个文件夹，它会认为其中可能有一个重要的（改变游戏规则的）web.config 文件，并显示错误。因此，应用程序池帐户需要读访问所有内容文件夹。
应用程序池标识
为什么要区分应用程序池帐户（应用程序池的标识）和应用程序池标识？因为特殊大写字母应用程序池标识是新帐户类型- 托管服务帐户 - 在 IIS 7.5 / Windows 2008 R2 中引入并设为默认帐户，从 Windows 2008 SP2 开始也可使用（但不是默认帐户）。
当您使用 GUI 在 2008 R2 或更高版本下创建网站时：
- 将创建一个应用程序池来托管该网站，并且
- 账户类型为应用程序池标识，而不是网络服务（2008 年的默认值）、本地服务或本地系统
- 虚拟身份 IIS AppPools\AppPoolName 将可用作本地计算机上的安全主体
在 2008 RTM 中，默认的应用程序池帐户是网络服务加唯一的应用程序池标识/唯一标识符；新的 R2/SP2 AppPoolIdentity帐户类型是一个网络服务喜欢帐户（即连接机外时的计算机），但可以防止模拟同一机箱内的另一个应用程序池。
回到最初的问题：
应用程序池帐户定义WHO您的应用运行为当它没有冒充其他人时
身份验证方法描述如何你将对客户端进行身份验证（以便模拟他们）
这匿名用户帐户定义在模拟用户执行未经身份验证的请求时将以谁的身份运行 - IUSR 就是这样的一个用户。
顺便说一句，使用 IIS 7.5+，您可以将匿名用户帐户设置为应用程序池标识（匿名身份验证方法的属性），这可能使隔离和保护给定网站的内容变得更加直接。
使用 IIS AppPool\YourSiteName 作为名称格式设置权限（请参阅这个帖子）。
答案2
您会看到两个在 ASP.NET 中经常混淆的事情：
- “用户身份” - 用户帐户的身份验证与在 IIs 和 ASP.NET 下实际运行的帐户或身份无关。匿名身份验证允许任何用户访问任何公共内容，而无需向客户端浏览器提供用户名和密码质询。在 IIS 中默认进行身份验证的匿名 IUSR 帐户仅应用于对公共网站内容的访问。它不会影响底层 IIs 或 ASP.NET 服务使用的进程或资源。
- “应用程序标识” - 这是服务器上实际运行在 IIS 和 ASP.NET 后面的实际“WindowsIdentity”帐户，即由 IIs 分配给池并提供给 ASP.NET 的应用程序池标识帐户。默认情况下，您的 ASP.NET 进程在此应用程序池标识帐户（在 IIs 版本 7.5 及以上版本中称为虚拟帐户）下运行。
解释：首先，ASP.NET 中的“身份验证”只是通常在 web.config 中设置的一个事件，该事件登录给定的用户帐户，该帐户由 IIs 作为用户令牌传递给 ASP.NET，作为纯 HttpContext 对象……即当前用户的当前会话或上下文。它实际上并没有改变运行 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 中将 anonymousAuthentication 属性明确设置为 true（而不是使用 Windows 或其他登录帐户），IIs 将抛弃应用程序池标识，并且 IIs 和 ASP.NET 现在都将以匿名 IUSR 身份验证和模拟帐户的身份运行其应用程序进程。
当您执行此操作时，ASP.NET 及其进程现在将在 IUSR 帐户下运行...即 ASP.NET 的应用程序进程将以 IUSR 帐户的身份运行其 WindowsIdentity 帐户。您现在可以对该匿名 IUSR 帐户以及您希望该帐户访问的文件夹应用读/写访问权限。（注意：但请务必添加默认进程帐户、池的应用程序池帐户以及对这些文件夹的权限。这是根据 Microsoft 的建议）
祝你好运！
答案3
有两个身份验证上下文在起作用。Web 服务器进程（处理您的 Web 请求）以应用程序池标识用户的身份运行。当虚拟主机收到请求时，应用程序池会模拟特定站点的“匿名身份验证凭据”中列出的用户 - 默认情况下为 IUSR。
从您的网站内部运行的任何脚本都将以 IUSR 身份运行，但日志记录和某些其他功能将以应用程序池用户身份运行（默认情况下为网络服务 - 尽管最近已更改为使用特殊的虚拟应用程序池用户）。应用程序池标识（网络服务）需要能够列出目录中的文件，因为在将控制权移交给您的脚本之前，会在请求堆栈中完成某些检查。
最好在每个池中运行一个站点，并将应用程序池标识设置为以与网站的匿名用户相同的用户身份运行。可以脱离匿名用户上下文 (IUSR) 并将权限提升到应用程序池标识本身的权限。