对 EVERYONE 的写访问有效，IUSR、IIS_IUSRS、DefaultAppPool 无效。为什么？

Question

好的。在这里，我们尝试在 Windows Server 2008 R2 中的 IIS 7.5 上设置经典 ASP 网站。在网站的根目录下有一个名为 dbc 的文件夹，它有一个文件，用于在处理每个页面时读取和写入某些信息。

问题是，如果我授予 IUSR 写入权限和 IIS_IUSRS 写入权限或 DefaultAppPool 写入权限，我会收到“对路径 'E:..\websiteroot\dbc\filename.txt' 的访问被拒绝”

但是，如果我授予每个人对该 dbc 文件夹的写访问权限，那么我不会收到任何错误，一切似乎都很完美。

更多信息：该网站在经典管道模式下运行，启用匿名身份验证（也许它是唯一启用的身份验证）。我尝试使用 IUSR 帐户以及应用程序池身份进行匿名身份验证。就我而言，ApplicationPoolIdentity 是网站身份验证的身份。我们使用 COM+ 进行文件 I/O。和经典的 ASP Server.CreateObject 来实例化一个对象。COM+ 作为网络服务运行。

想法？我不想向所有人授予写入权限。我错过了什么吗？

解决：这就是我所做的。

我的名为 CipherDemo 的网站在 IIS 7.5 中的 AppPoolIdentity 下运行，可以通过 Identity IIS AppPool\CipherDemo 定位。我使用 ICACLS 授予该文件夹的 RW 权限。

而实际执行文件 I/O 的 COM+ 在网络服务标识下运行。当我使用 Process Monitor 跟踪访问被拒绝错误时，它发现网络服务对该文件夹只有读取权限。

我使用 ICACLS "foldername" /grant:r "NT AUTHORITY\NETWORKSERVICE":(OI)(CI)RXW /T 授予对该文件夹的写访问权限。

并解决了它。

我的意图是因为该网站作为 CipherDemo Identity 运行，这将是用于通过 COM+ 访问文件的帐户。但是令人尴尬的是发现 COM+ 仍然可以在它自己的身份边界上工作。

Answer 1

您可以通过 NTFS GUI 直接键入来添加帐户。名称的格式为IIS APPPOOL\<<app pool name>>，例如IIS APPPOOL\DefaultAppPool。（请参阅此Microsoft 支持文章）

另一种解决方案：我一直在使用“网络服务”帐户作为授予它写权限的应用程序池用户。

Answer 2

在 IIS 7.5（以及可选在 IIS 7 中）下，所有工作人员都使用应用程序池标识运行：用户“IIS AppPool*PoolName*”。

授予该用户访问权限，而不是“所有人”（您需要在选择身份对话框中输入名称——它不会出现在查找功能中）。

iis.net上有一个非常有用的页面，其中包含更详细的内容。

另请注意：在 IIS7 (Server 2008) 下：

• 您可以在高级设置中基于每个应用程序池设置应用程序池标识。
• 没有 GUI 支持，因此您需要使用命令行来设置权限 ( icacls.exe)。

最后，SQL Server 的标识选择也不知道应用程序池标识：使用CREATE LOGIN和CREATE USER最初，此后 GUI 可用于授予角色等。