ApplicationPoolIdentity被分配为Users组和IIS_IUSRS组的成员。乍一看，这可能有点令人担忧，但用户组的NTFS权限有些有限。

例如，如果您尝试在C:\Windows文件夹中创建一个文件夹，那么您会发现您不能。ApplicationPoolIdentity仍然需要能够从windows系统文件夹中读取文件(否则工作进程如何能够动态加载必要的DLL)。

关于你对能够写入c:\dump文件夹的观察。如果你在高级安全设置中查看权限，你会看到以下内容:

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

这就是站点的ApplicationPoolIdentity可以读写该文件夹的原因。这个权限是从c:\ drive继承的。

在共享环境中，您可能有几百个站点，每个站点都有自己的应用程序池和应用程序池标识，您可以将站点文件夹存储在删除了Users组的文件夹或卷中，并且权限设置为只有管理员和SYSTEM帐户具有访问权限(带有继承)。

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

您还应该确保您创建的用于存储潜在敏感文件或数据的任何文件夹都已删除Users组。你还应该确保你安装的任何应用程序都不会将敏感数据存储在它们的c:\program files\[app name]文件夹中，而是使用用户配置文件文件夹。

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

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

例如，我在这里有一个名为900300的池，它的应用程序池标识为IIS APPPOOL\900300。右键单击进程的属性，然后选择Security选项卡:

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

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

这种类型的文件存储访问是自动完成的你应该可以在应用程序池用户帐户文件夹中写任何你想写的东西而不需要改变任何东西。这就是为每个应用程序池创建虚拟用户帐户的原因。

右键单击文件夹。 单击“属性” 单击“安全选项卡”。你会看到这样的东西:

点击上方屏幕中的“编辑…”按钮。你会看到这样的东西:

点击上方屏幕中的“添加…”按钮。你会看到这样的东西:

点击屏幕上方的“位置…”按钮。你会看到类似这样的东西。现在，转到这个树结构的最顶端，选择您的计算机名，然后单击OK。

现在输入“iis apppool\your_apppool_name”，然后点击“检查名称”按钮。如果apppoool存在，您将在文本框中看到带有下划线的apppoool名称。单击OK按钮。

勾选/取消勾选您需要授予该帐户的任何访问权限 单击“应用”按钮，然后单击“确定”。

我试图修复访问IIS网站的问题，这在事件日志→Windows→应用程序中表现为如下内容:

Log Name:      Application
Source:        ASP.NET 4.0.30319.0
Date:          1/5/2012 4:12:33 PM
Event ID:      1314
Task Category: Web Event
Level:         Information
Keywords:      Classic
User:          N/A
Computer:      SALTIIS01

Description:
Event code: 4008 
Event message: File authorization failed for the request. 
Event time: 1/5/2012 4:12:33 PM 
Event time (UTC): 1/6/2012 12:12:33 AM 
Event ID: 349fcb2ec3c24b16a862f6eb9b23dd6c 
Event sequence: 7 
Event occurrence: 3 
Event detail code: 0 

Application information: 
    Application domain: /LM/W3SVC/2/ROOT/Application/SNCDW-19-129702818025409890 
    Trust level: Full 
    Application Virtual Path: /Application/SNCDW 
    Application Path: D:\Sites\WCF\Application\SNCDW\ 
    Machine name: SALTIIS01 

Process information: 
    Process ID: 1896 
    Process name: w3wp.exe 
    Account name: iisservice 

Request information: 
    Request URL: http://webservicestest/Application/SNCDW/PC.svc 
    Request path: /Application/SNCDW/PC.svc 
    User host address: 10.60.16.79 
    User: js3228 
    Is authenticated: True 
    Authentication Type: Negotiate 
    Thread account name: iisservice 

最后，我不得不给予Windows Everyone组对该文件夹的读访问权，以使其正常工作。