logo标签列表

IIS应用程序池身份和文件系统写访问权限

asp.netpermissionsiis-7.5windows-server-2008-r2
430

这里涉及到一个我一直在研究但没有任何进展的IIS 7.5和ASP.NET的问题。真心感谢任何给予帮助的人。

我的问题是：当使用ASP.NET在IIS 7.5上运行时，操作系统和/或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允许这些写入发生的方式很感兴趣，即使没有明确授予文件系统访问权限也是如此。
4个回答
424
ApplicationPoolIdentity会分配到Users组和IIS_IUSRS组的成员身份。初看起来可能有些令人担忧，但是Users组的NTFS权限是有限制的。
例如，如果你尝试在C:\Windows文件夹中创建文件夹，就会发现你做不到。然而，ApplicationPoolIdentity仍然需要能够从windows系统文件夹中读取文件（否则工作进程如何能够动态加载必要的DLL）。
关于你能够向c:\dump文件夹写入的情况。如果你查看高级安全设置中的权限，你会看到以下内容： enter image description here 注意从c:\继承的特殊权限： enter image description here 这就是为什么你网站的ApplicationPoolIdentity可以读取并且写入该文件夹的原因。这个权限是从c:\驱动器继承下来的。
在共享环境中，你可能会有几百个站点，每个站点都有自己的应用程序池和Application Pool Identity，你需要将站点文件夹存储在已删除Users组并且权限设置为只有管理员和SYSTEM帐户访问的文件夹或卷中（带继承）。
你需要单独为每个IIS AppPool\[name]在其网站根文件夹上分配必要的权限。
你还应确保你创建的任何存储可能敏感文件或数据的文件夹中，已删除Users组。你还应确保你安装的任何应用程序不会在它们的c:\program files\[app name]文件夹中存储敏感数据，并使用用户配置文件夹来代替。

是的，乍一看似乎ApplicationPoolIdentity拥有比它应该拥有更多的权限，但实际上它没有超出其组成员身份所决定的权限。

可以使用SysInternals Process Explorer 工具来查看一个ApplicationPoolIdentity的组成员身份。找到正在使用你感兴趣的应用程序池标识的工作进程（你将不得不将用户名列添加到要显示的列列表中：

enter image description here

例如，在这里我有一个名为900300的池，它有一个名称为IIS APPPOOL\900300的应用程序池标识。右键点击进程属性并选择安全选项卡，我们可以看到：

enter image description here

如我们所见， IIS APPPOOL\900300 是用户组的成员。

7
让我们投票让这个部分包含在MSDN中。我从来没有花时间去弄清楚这个，所以这很有帮助（而且我感到很惭愧我从不知道）。 - Grimace of Despair
73
不清楚为什么这份微软IIS核心文档在SO而不是MSDN上。 - Amit Naidu
我有一个与此主题相关的问题。是否有一种方法可以作为特定的AD用户访问文件夹，而不是“ApplicationPoolIdentity”？例如，如果名为John的用户登录到Web应用程序，则使用他的AD帐户来访问磁盘上的文件夹。更多信息请参见：https://stackoverflow.com/questions/46332785/asp-net-access-some-folder-on-file-share-based-on-user-authenticated - Primoz
@RGS - 抱歉，我现在非常忙。如果我有空余时间，我会尝试回答它。 - Kev
@Kev，好的。谢谢。 - RGS
显示剩余7条评论
68

  1. 右键单击文件夹。

  2. 点击属性。

  3. 点击安全选项卡，您会看到类似下面的内容：

enter image description here

  1. 在上面的屏幕中点击 "编辑..." 按钮，您会看到类似下面的内容：

enter image description here

  1. 在上面的屏幕中点击 "添加..." 按钮，您会看到类似下面的内容：

enter image description here

  1. 在上面的屏幕中点击 "位置..." 按钮，您会看到类似下面的内容。现在，转到此树结构的顶部，选择计算机名称，然后点击确定。

enter image description here

  1. 现在输入 "iis apppool\your_apppool_name" 并点击 "检查名称" 按钮。如果应用程序池存在，则会在带有下划线的文本框中看到您的应用程序池名称。点击确定按钮。

enter image description here

  1. 勾选/取消勾选需要授予该帐户的任何访问权限。

  • 点击应用按钮，然后点击确定。

    • 3
    将位置更改为树结构的顶部对我来说是关键。非常感谢！ - Hedgybeats
    0

    我尝试使用以下方法来解决访问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 请求信息： 请求URL：http://webservicestest/Application/SNCDW/PC.svc 请求路径：/Application/SNCDW/PC.svc 用户主机地址：10.60.16.79 用户：js3228 已验证：True 验证类型：Negotiate 线程帐户名称：iisservice 最后我不得不给Windows的Everyone组读取那个文件夹的权限，才能使它正常工作。
    0

    IIS中的每个应用程序池都会默认创建自己的安全用户文件夹，位于c:\users下，并具有完全的读/写权限。打开您的用户文件夹，查看其中是否存在应用程序池文件夹，右键单击并检查其分配给应用程序池虚拟账户的权限。您应该已经看到您的应用程序池账户已添加，并被分配了对其根目录和子文件夹的读/写访问权限。

    因此，这种类型的文件存储访问是自动完成的，您应该能够在应用程序池用户账户文件夹中随意编写任何内容，而无需更改任何设置。这就是为什么为每个应用程序池创建虚拟用户账户的原因。

    1
    只有在“加载用户配置文件”设置为True时才会发生这种情况。 - JamesQMurphy
    1
    没错，这意味着如果不是真的，AppPool用户文件夹就不会被创建，对吧？这就是为什么他们以这种方式构建它的原因......防止IIs访问和存储垃圾在windows/temp和整个硬盘上，而不是在一个受管理的安全文件夹中只为该帐户。 - Stokely
    网页内容由stack overflow 提供, 点击上面的
    可以查看英文原文，
    原文链接