临时 Asp.Net 文件的 ApplicationPoolIdentity 权限

Posted 2023-02-23

【中文标题】临时 Asp.Net 文件的 ApplicationPoolIdentity 权限

【英文标题】：ApplicationPoolIdentity permissions on Temporary Asp.Net files

【发布时间】：2010-06-08 10:36:15

【问题描述】：

在工作中，我遇到了以下情况： 我们有一个在 WIndows Server 2008 64 位机器上运行的 Web 应用程序。应用的 ApplicationPool 在 ApplicationPoolIdentity 下运行并配置为 .net 2 和 Classic 管道模式。

直到 XmlSerialization 需要创建序列化程序程序集，其中 MEF 用于创建已知类型的集合时，这都可以正常工作。

为了解决这个问题，我希望授予 ASP.Net 临时文件目录的 ApplicationPoolIdentity 权限就足够了，但是唉...

我所做的是在 cmd 提示符下运行以下命令：

icacls "c:\windows\microsoft.net\framework64\v2.0.50727\Temporary ASP.NET Files" /grant "IIS AppPool\MyAppPool":(M)

显然这不起作用，否则你就不会阅读这个:)

奇怪的是，每当我授予用户或更具体的授权用户组这些权限时，它就可以工作。奇怪的是（在我看来），在我开始授予访问权限之前，ApplicationPoolIdentity 已经是 IIS_IUSRS 的成员，它确实具有临时 asp 文件目录的修改权限。

现在我想知道为什么这种情况需要 Authenticated Users 组的修改权限。我认为这可能是因为 apppool 帐户缺少其他权限（谷歌搜索返回了一些结果，所以我尝试了这些），但是授予 Windows\Temp 目录和/或应用程序目录本身的 ApplicationPoolIdentity 修改权限并没有修复它.

现在我们有一个解决方法，但我讨厌我不知道这里到底发生了什么，所以我希望你们中的任何人都可以对此有所了解。

提前谢谢！

【问题讨论】：

应用程序池以什么用户身份运行？网络服务？还是别的什么？

应用程序池在 ApplicationPoolIdentity 下运行，这就是为什么在 cmd 提示符下使用 icacls 设置访问权限的原因。

【参考方案1】：

如果应用程序池作为 AppPool Identity 运行，那么一切都应该开箱即用，因为工作进程将被注入具有正确写入权限的 IIS_IUSRS SID。

我的猜测是，应用程序必须使用 Windows 身份验证，并且在 ASP.NET 中启用了模拟，因此代码可能以发出请求的特定用户身份运行，而不是进程身份。

我对应用程序正在运行 Windows 身份验证的猜测是否正确？并且在 asp.net 中启用了模拟？

【讨论】：

该应用确实启用了 Windows 身份验证。该应用程序是从将 Windows 身份验证和模拟设置为 true 的网站调用的服务总线，因此您的猜测是错误的。网站和应用程序都在同一个 AppPool 下运行。但是，当我自己从网站运行应用程序时，问题仍然存在，并且我是托管网站和服务总线应用程序的计算机上本地管理员组的成员（显然，它是一个开发框：p）。我在这里错过了什么？

即使您是管理员组的成员，由于网络令牌过滤，您也可能不会以管理员权限运行。我会专门为您的帐户尝试 ACL，然后再试一次（不是管理员或所有人），看看是否有效。最后，我会使用 ProcMon 来查看它是否可以发现正在执行访问的用户身份technet.microsoft.com/en-us/sysinternals/bb896645.aspx

标记了你的答案。由于时间紧缺，我将不得不在本周晚些时候查看您的最后评论，但非常感谢您的帮助！

【参考方案2】：

可能与您无关 - 但如果您以 域 用户身份运行应用程序池，则在启动时将 IIS_IUSRS 令牌自动注入进程的规则会发生变化。这让我们最近在迁移到 .net 4 时发现了这一点，并且没有新的 Temporary ASP.net Files 目录的权限。

请参阅此处了解解决方法：http://www.yusufozturk.info/iis7/asp-net-write-access-error-on-iis7-5.html