在 Windows Server 2012 R2 中，IIS 在通常情况下作为 Web 服务器运行。但是，Web 内容不是来自，c:\inetpub\wwwroot\而是来自其他文件夹。Web 应用程序仍在其自己的用户（即来自 defaultAppPool）下运行。
我实际上忘记授予IIS_IUSRS对 Web 内容文件夹的读取/执行权限。但是该文件夹确实授予了访问权限。如果子文件夹需要可写，users我只会添加读取/执行/写入权限。IIS_IUSRS
为了稍微加强安全性，我检查了 Web 内容文件夹的访问权限，并通过反复试验了解到，现在IIS_IUSRS缺少访问权限，users负责一切的组的访问权限仍然有效。因为当我删除对该users组的访问权限时，应用程序将停止工作。
我尝试授予其他一些帐户/组的访问权限，我发现授予这两个帐户/组的访问权限users并IIS_IUSRS单独授予我的应用程序运行。授予访问权限IIS APPPOOL\不起作用。但授予我的特定应用程序池用户（例如IISAPPPOOL\nl-x-homepage）访问权限却可以。而最后一点正是我想要的，因为我不希望一个应用程序能够访问其他应用程序的文件。
但我很好奇... IIS 类帐户究竟是如何工作的？为什么授予访问权限users也适用于我的应用程序池访问 Web 内容文件夹？我无法在 lusrmgr 中看到我的特定应用程序池用户，但我猜测我的特定应用程序池用户位于该users组中，或位于该users组中的其他组中。有人可以证实这一点吗？
关于此事的最后一个问题是：为了使特定文件夹“受密码保护”，我在 Windows 中创建了一个普通用户，将该用户从组中删除users，然后在 IIS 管理器中转到该文件夹并执行身份验证 -> 基本身份验证 -> 已启用，并在身份验证规则中为新创建的 Windows 用户帐户设置了允许规则。这有效。但分析读/写访问权限时，我惊讶地发现，虽然应用程序是在应用程序池用户下运行的，但应用程序池用户只需要读取权限（没有写入权限），而新创建的 Windows 用户需要同时具有读写权限才能使文件夹可写。有人能帮忙解释一下为什么这样有效吗？
答案1
对于我来说，您所遇到的行为似乎很合乎逻辑。
IIS_IUSRS 是一个组，而不是一个帐户，其唯一目的是使其成员能够被分配为应用程序池身份，因此单独添加它是不够的（正如您所发现的）。
用户组包含具有足够权限使网站正常运行的 ASPNET 帐户，因此添加该帐户就足以获得默认权限。我相信 ASPNET 帐户是用作 DefaultAppPool 的帐户。
用户创建的文件或文件夹始终具有读取权限，因为创建者是所有者并拥有所有权限。如果另一个用户创建了该文件或文件夹，则在 Windows 中只授予写入权限而不授予读取权限是行不通的，因为在写入之前需要读取权限来检查权限和可用空间等。
答案2
IIS_IUSRS 是 IIS 工作进程帐户组。此内置组可以访问所有必要的文件和系统资源，因此当将帐户添加到此组时，该帐户可以无缝地充当应用程序池标识。
如果您右键单击域并打开“编辑权限”，您应该会看到列出的组和权限。在“安全”选项卡下，您将看到 MACHINE_NAME\IIS_IUSRS 以及 /Users。IIS 自动对该目录具有只读权限。
对于您创建的每个应用程序池，新应用程序池的 Identity 属性默认设置为 ApplicationPoolIdentity。IIS 管理进程 (WAS) 将创建一个具有新应用程序池名称的虚拟帐户，并默认在此帐户下运行应用程序池的工作进程。每当创建新的应用程序池时，IIS 管理进程都会创建一个代表应用程序池本身名称的安全标识符 (SID)。例如，如果您创建一个名为“MyFirstPool”的应用程序池，则 Windows 安全系统中会创建一个名为“MyFirstPool”的安全标识符。从此时起，可以使用此标识来保护资源。但是，该身份并不是真正的用户帐户；它不会在 Windows 用户管理控制台中显示为用户。这是正常行为。如果您想提供对某个文件夹的访问权限，只需通过编辑权限将其添加到该文件夹即可。但是，您必须检查默认身份验证配置（匿名身份），看看是否有合适的选择，或者对其进行配置以避免访问错误。
这个帖子解决其余问题。继承。
显然，您在此处添加的 Windows 用户需要权限，因为该帐户必须从必要的组继承权限。此处的读取权限至关重要。但是，它旨在访问本地资源。