0

在工作中，我遇到了以下情况：我们有一个在 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 修改权限并没有修复它.

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

提前谢谢！

4

2 回答 2

5

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

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

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

于 2010-06-15T03:41:28.033 回答
1

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

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

于 2010-06-29T11:52:42.513 回答