我们有Windows 2012服务器与IIS 8上。
在此服务器上运行的ASP.NET应用程序通过REST API向单独的应用程序进行身份validation。 这个单独的应用程序会回应一个名为login.xml的.XML文件，默认情况下，ASP.NET应用程序将尝试放置在本地C：\ Windows \ System32 \ inetsrv文件夹中。 ASP.NET应用程序不会要求这个.xml文件，而且似乎也没有办法使得这个文件被转储到别的地方。
由于“IIS AppPool \ DefaultAppPool”用户（它是运行ASP.NET应用程序的应用程序池的标识）在此C：\ Windows \ System32 \ inetserv文件夹中没有许可，所以.XML文件不能写入并在浏览器中显示错误。
部分地，浏览器中显示的错误是：
“访问path”C：\ windows \ system32 \ inetserv \ login.xml“被拒绝。
我怀疑，通常，将“C：\ windows \ system32 \ inetserv \”目录上的权限授予此“IIS AppPool \ DefaultAppPool”用户将不会是这样一个热门的安全明智的想法，但在我们的具体情况下，这将是好的。
在早些时候用Googlesearch浏览器中显示的错误的方式，似乎很多人已经能够成功地授予文件夹所需的权限。 不过，在我看到的关于这个主题的所有文章中，似乎也使用了IIS的版本是7以上。
作为本地pipe理员，我没有成功尝试将用户的必要权限添加到“C：\ windows \ system32 \ inetserv \”，并且也试图不成功地取消选中该文件夹的只读属性，但已被拒绝，因为甚至pipe理员用户没有权限更改文件夹的权限。 仔细查看文件夹的权限，所有用户都具有“读取和执行”，“列出文件夹内容”和“读取”权限，但pipe理员没有额外的权限。
我还没有发现任何在互联网上，特别是说，微软已经lockingWindows Server 2012或IIS 8的地方额外的权限不能授予在这个文件夹…任何人都可以阅读这个揭示了为什么我不能授予这些允许？
此外，还有一个相关的问题 – 该服务器位于AWS，由亚马逊提供的AMI构build。 亚马逊的AMI是否有可能以某种方式特别强化，拒绝这些权限更改，使AWS托pipe的服务器尽可能安全？
谢谢，迈克
Server 2012上system32\inetsrv的默认权限为：
NT SERVICE\TrustedInstaller:(F) NT SERVICE\TrustedInstaller:(CI)(IO)(F) NT AUTHORITY\SYSTEM:(M) NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(F) BUILTIN\Administrators:(M) BUILTIN\Administrators:(OI)(CI)(IO)(F) BUILTIN\Users:(RX) BUILTIN\Users:(OI)(CI)(IO)(GR,GE) CREATOR OWNER:(OI)(CI)(IO)(F) APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(RX) APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(OI)(CI)(IO)(GR,GE)
pipe理员具有修改权限，这意味着AWS默认值不同或其他人已更改权限。
你的主要问题是你的ASP.NET应用程序试图写入inetsrc ，这是一个禁止否。 联系谁写的应用程序，要求他们修复它。
如果您确实想要更改inetsrv的权限，则首先需要将所有权更改为pipe理员
takeown.exe /F .\inetsrv /R /A
2012年的默认所有者是TrustedInstaller
那么您可以为AppPool标识添加修改权限。
正如你所说的那样，这会降低安全性，并可能危及整个服务器，所以真的试图首先修复应用程序。