IIS AppPoolIdentity和文件系统写访问权限

这是我一直在研究并且无处可寻的IIS 7.5和ASP.NET问题。任何帮助将不胜感激。

我的问题是：在IIS 7.5中使用ASP.NET，IIS和/或操作系统如何允许Web应用程序像C:\dump在完全信任下运行时一样写入文件夹？我不必为应用程序池用户显式添加写访问权限（在这种情况下）ApplicationPoolIdentity）？

我知道的很多：

• 在IIS 7.5中，应用程序池的默认标识为ApplicationPoolIdentity。
• ApplicationPoolIdentity 表示一个名为“ IIS APPPOOL \ AppPoolName”的Windows用户帐户，该帐户在创建应用程序池时创建，其中AppPoolName是应用程序池的名称。
• 默认情况下，“ IIS APPPOOL \ AppPoolName”用户是 IIS_IUSRS组。
• 如果你是在完全信任运行Web应用程序可以写入（不包括文件夹，如文件系统的许多领域C:\Users，C:\Windows等等）。例如，您的应用程序将有权写入某些文件夹，例如C:\dump。
• 默认情况下，IIS_IUSRS不授予该组读写权限C:\dump（至少不具有通过Windows资源管理器中“安全”选项卡可见的访问权限）。
• 如果您拒绝对的写入访问IIS_IUSRS，则尝试写入文件夹时（如预期的那样），您将收到SecurityException。

因此，考虑到所有这些因素，如何将写入访问权限授予“ IIS APPPOOL \ AppPoolName”用户？w3wp.exe进程以该用户身份运行，那么什么使该用户可以写入似乎没有明确访问权限的文件夹呢？

请注意，我知道这样做可能是为了方便起见，因为如果您在“完全信任”下运行，要授予用户对其需要写入的每个文件夹的访问权限将很痛苦。如果要限制此访问，则始终可以在“中等信任”下运行该应用程序。我有兴趣了解操作系统和/或IIS允许进行这些写入的方式，即使似乎没有明确的文件系统访问权限也是如此。

将ApplicationPoolIdentity被分配的成员Users组以及该IIS_IUSRS组。乍一看，这看起来有些令人担忧，但是Users组的NTFS权限有所限制。

例如，如果您尝试在该C:\Windows文件夹中创建一个文件夹，则会发现您无法创建该文件夹。的ApplicationPoolIdentity仍然需要能够从Windows系统文件夹读取文件（否则怎么回事就工作进程能够动态地加载DLL必不可少的）。

关于您关于能够写入c:\dump文件夹的意见。如果您查看“高级安全设置”中的权限，则会看到以下内容：

看到特殊权限继承自c:\：

这就是您的网站ApplicationPoolIdentity可以读取和写入该文件夹的原因。该权利是从c:\驱动器。

在一个共享环境中，您可能有数百个站点，每个站点都有自己的应用程序池和应用程序池标识，您将站点文件夹存储在一个文件夹或卷中，该文件夹或卷已Users删除了该组并设置了权限，从而仅管理员和SYSTEM帐户具有访问权限（具有继承权限）。

然后，您将IIS AppPool\[name]在其网站根文件夹上分别分配每个所需的必要权限。

您还应该确保在存储潜在敏感文件或数据的文件夹中Users删除了该组。您还应确保所安装的任何应用程序均不会在其中存储敏感数据c:\program files\[app name]文件夹中而应使用用户配置文件文件夹。

因此，是的，乍一看，它似乎ApplicationPoolIdentity拥有比应有的权利更多的权利，但实际上它没有比其组成员资格所规定的更多的权利。

ApplicationPoolIdentity可以使用SysInternals Process Explorer工具检查an 的组成员身份。查找与您感兴趣的应用程序池标识一起运行的工作进程（您必须将User Name列添加到要显示的列列表中：

例如，我这里有一个池，900300其中的应用程序池标识为IIS APPPOOL\900300。右键单击该进程的属性，然后选择“安全性”选项卡，我们将看到：

我们可以看到IIS APPPOOL\900300是该Users组的成员。

1. 右键单击文件夹。

2. 单击属性

3. 单击安全性选项卡。您将看到如下内容：

4. 点击上方屏幕中的“编辑...”按钮。您将看到如下内容：

5. 点击上方屏幕中的“添加...”按钮。您将看到如下内容：

6. 点击上方屏幕中的“位置...”按钮。您将看到类似这样的内容。现在，转到此树形结构的最上方，然后选择您的计算机名称，然后单击“确定”。

7. 现在，键入“ iis apppool \ your_apppool_name”，然后单击“检查名称”按钮。如果该应用程序池存在，您将在文本框中看到带有下划线的应用程序池名称。单击确定按钮。

8. 选中/取消选中您需要授予该帐户的任何访问权限

9. 单击“应用”按钮，然后单击“确定”。

IIs中的每个应用程序池默认在c：\ users下创建具有FULL读/写权限的自己的安全用户文件夹。打开“用户”文件夹，查看其中有哪些应用程序池文件夹，右键单击并检查其对分配的应用程序池虚拟帐户的权限。您应该看到您的应用程序池帐户已经添加了，并为其根目录和子文件夹分配了读/写访问权限。

这样就可以自动完成这种类型的文件存储访问，并且您应该能够在不更改任何内容的情况下在应用程序池用户帐户文件夹中写入所需内容。这就是为什么要为每个应用程序池创建虚拟用户帐户的原因。

我试图通过此方法来解决对IIS网站的访问问题，该问题在事件日志→Windows→应用程序中显示为以下内容：

日志名称：应用程序
资料来源：ASP.NET 4.0.30319.0
日期：2012年1月5日下午4:12:33
事件ID：1314
任务类别：Web事件
级别：信息
关键字：经典
用户：N / A
计算机：SALTIIS01

描述：
场次编码：4008 
事件消息：该请求的文件授权失败。 
活动时间：2012年1月5日下午4:12:33 
活动时间（UTC）：2012年1月6日上午12:12:33 
事件ID：349fcb2ec3c24b16a862f6eb9b23dd6c 
事件顺序：7 
事件发生：3 
事件详细代码：0 

应用信息： 
    应用程序域：/ LM / W3SVC / 2 / ROOT / Application / SNCDW-19-129702818025409890 
    信任等级：完整 
    应用程序虚拟路径：/ Application / SNCDW 
    应用程序路径：D：\ Sites \ WCF \ Application \ SNCDW \ 
    机器名称：SALTIIS01 

处理信息： 
    进程ID：1896 
    进程名称：w3wp.exe 
    帐户名称：iisservice 

索取信息： 
    要求网址：http：//webservicestest/Application/SNCDW/PC.svc 
    请求路径：/Application/SNCDW/PC.svc 
    用户主机地址：10.60.16.79 
    用户：js3228 
    已验证：真 
    身份验证类型：协商 
    线程帐户名称：iisservice 

最后，我必须授予Windows Everyone组对该文件夹的读取权限，以使其正常工作。