在工作中我在以下情况下苦苦挣扎： 我们有一个在WIndows Server 2008 64位机器上运行的Web应用程序。应用程序的ApplicationPool在ApplicationPoolIdentity下运行，并配置为.net 2和Classic管道模式。
直到XmlSerialization需要创建Serializer程序集时才能正常工作，其中MEF用于创建已知类型的集合。
为了解决这个问题，我希望将ApplicationPoolIdentity权限授予ASP.Net Temporary Files目录就足够了，但是唉......
我所做的是从cmd提示符运行以下命令：
icacls "c:\windows\microsoft.net\framework64\v2.0.50727\Temporary ASP.NET Files" /grant "IIS AppPool\MyAppPool":(M)
显然这不起作用，否则你不会读这个：）
奇怪的是，每当我授予用户或更具体，Authenticated Users Group这些权限时，它都有效。同样奇怪（在我看来）是在我开始授予访问权限之前，ApplicationPoolIdentity已经是IIS_IUSRS的成员，它具有临时asp文件目录的修改权限。
现在我想知道为什么这种情况需要Authenticated Users组的修改权限。我认为可能是因为apppool帐户缺少额外的权限（谷歌搜索返回了一些结果，所以我尝试了这些），但是授予对Windows \ Temp目录和/或应用程序目录本身的ApplicationPoolIdentity修改权限并没有修复它
目前我们有一个解决方法，但我讨厌我不知道这里到底发生了什么，所以我希望你们中的任何一个人能够对此有所了解。
提前Thanx！
答案 0 :(得分：5)
如果应用程序池作为AppPool Identity运行，则事情应该是开箱即用的，因为工作进程将注入IIS_IUSRS SID，该SID将具有正确的写入权限。
我的猜测是，应用程序必须使用Windows身份验证，并且在ASP.NET中启用了模拟，以便代码可能作为发出请求的特定用户运行，而不是必需的进程标识。
我是否认为该应用正在运行Windows身份验证？并且在asp.net中启用了模拟？
答案 1 :(得分：0)
可能与您无关 - 但如果您将应用程序池作为域用户运行，则规则会在启动时自动将IIS_IUSRS令牌注入进程。最近在迁移到.net 4时没有获得新Temporary ASP.net Files目录的权限，这让我们感到很沮丧。
请在此处查看解决方法：http://www.yusufozturk.info/iis7/asp-net-write-access-error-on-iis7-5.html