在IIS 7.5和Windows Server 2008 R2下向ASP.NET的联网UNC文件夹授予写权限 [英] Granting write permissions to a networked UNC folder for ASP.NET under IIS 7.5 and Windows Server 2008 R2

问题描述

我们的应用程序正在尝试使用在.NET 4.5，IIS 7.5和Windows Server 2008 R2下运行的ASP.NET Web服务将文件写入UNC文件夹.但是，任何将文件写入所需位置的尝试都会导致拒绝访问的异常.

Our application is attempting to write a file to a UNC folder using an ASP.NET web service running under .NET 4.5, IIS 7.5, and Windows Server 2008 R2. However, any attempt to write the file to the desired location results in an access denied exception.

任务似乎很简单，但是我和我的团队已经对此进行了一段时间的故障排除，对于可能导致该错误的原因，我们深感困惑.以下是设置的详细信息以及到目前为止我们已经尝试和发现的内容.名称已更改，以保护无辜者.

The task seems simple however me and my team have been troubleshooting this for a while now and we are stumped as to what may be causing the error. Below are the details of our setup and what we have tried and found so far. Names have been changed to protect the innocent.

Web服务器 mywebserver 具有一个名为 My.Site.Com 的网站，以及一个名为 My.Site.Com 的相应应用程序池. .应用程序池的配置如下所示.

The web server, mywebserver, has a website named My.Site.Com with a corresponding application pool named My.Site.Com. The application pool is configured as shown below.

 .NET Framework Version     : v4.0
 Enable 32-bit Applications : False
 Managed Pipeline Mode      : Integrated
 Name                       : My.Site.Com
 Identity                   : ApplicationPoolIdentity
 Load User Profile          : False

我们尝试写入的UNC路径是 \ myotherserver \ mydirectories \ output ，其中 mydirectories 是实际共享.在此共享上，已授予名为mygroup-www的域组对共享和所有子文件夹的完全权限.机器帐户(即mywebserver)是此mygroup-www组的成员.

The UNC path we are attempting to write to is \myotherserver\mydirectories\output where mydirectories is the actual share. On this share a domain group named mygroup-www has been granted full permissions to the share and all subfolders. The machine account (i.e., mywebserver) is a member of this mygroup-www group.

注意:目前，此UNC路径实际上位于同一路径上 机器，mywebserver.但是，最终将其转移到其他机器上 在测试环境和生产环境中比 mywebserver 当它准备好了.目前，我只有一种测试环境可以解决.

NOTE: For the moment, this UNC path actually lives on the same machine, mywebserver. However, this will eventually be moved to a machine other than mywebserver in our test environment and in the production environment when that it is ready. Currently, I only have the one test environment to troubleshoot with.

可以通过执行以下代码来复制错误.

The error can be replicated by executing the following code.

[WebMethod]
[ScriptMethod(UseHttpGet = false, ResponseFormat = ResponseFormat.Json)]
public string ExportReport(int reportId)
{
    try
    {
        string output = ConfigHelper.OutputPath + "test.html"; // UNC path
        string url = ConfigHelper.VirtualPath + "test.html";
        string[] lines = { "Hello", "World!" };
        File.WriteAllLines(output, lines);                     // Access Denied!
        return url;
    }
    catch (System.Exception ex)
    {
        Logger.ErrorException("Error exporting report", ex);
        throw;
    }
}

问题排查

尝试失败

我们尝试了对文件夹(下面列出)的组/用户权限的各种组合.运行这些测试时，我们还运行了Process Monitor.对于每种配置，我们看到相同的结果. w3wp.exe进程尝试在所需位置创建文件，但报告了 ACCESS DENIED 的结果.每个配置的用户都是 IIS APPPOOL \ My.Site.Com .

Troubleshooting

Failed Attempts

We tried various combinations of group/user permissions on the folders (listed below). When running these tests we also ran Process Monitor. For each configuration we saw the same result. The w3wp.exe process attempted to create the file in the desired location but reported a result of ACCESS DENIED. The user of each configuration was IIS APPPOOL\My.Site.Com as expected.

1. 授予 mydomain \ mymachine $ 对 \ myotherserver \ mydirectories
的完全权限
2. 授予 mydomain \ mymachine $ 对 \ myotherserver \ mydirectories \ output
的完全权限

1. Granting mydomain\mymachine$ full permissions to \myotherserver\mydirectories
2. Granting mydomain\mymachine$ full permissions to \myotherserver\mydirectories\output

注意:我也尝试过修改代码，以使其 read a \ myotherserver \ mydirectories \ output 中的简单文件.什么时候 尝试读取文件，该过程失败，访问权限被拒绝 写入文件时显示的消息.

NOTE: I have also tried modifying the code so that it would read a simple file from \myotherserver\mydirectories\output. When attempting to read the file, the process fails with an ACCESS DENIED message as it did when writing the file.

成功尝试

我们还尝试了几种有效的配置.

Successful Attempts

We also tried several configurations that worked.

第一个有效的配置是向 \ myotherserver \ mydirectories 授予 IIS APPPOOL \ My.Site.Com 的完全权限.文件已成功写入，但是进程的用户出乎意料的是，它是为另一个网站的同一台计算机上的Web应用程序设置的域帐户.这仍然很令人困惑，但是因为其他"帐户也具有对该共享的写入权限.

The first configuration to work was to grant the IIS APPPOOL\My.Site.Com full permissions to \myotherserver\mydirectories The file was successfully written however the process's user was quite unexpectedly a domain account that was set up for a web application on the same machine in another website. This remains very confusing but worked as the 'other' account also has write permissions to the share.

这在生产中将不起作用，因为我们不能使用本地帐户来授予对网络资源的访问权限，但仍然是一个有趣的数据点.

This won't work in production as we cannot use local accounts to grant access to networked resources but is an interesting data point nonetheless.

第二个有效的配置是将My.Site.Com应用程序池的标识更改为对 \ myotherserver \ mydirectories 具有完全权限的域帐户.这是我们手动创建的普通"域帐户.我们没有捕获过程用户，但这可能是另一个有用的数据点.

The second configuration that worked was to change the My.Site.Com application pool's identify to domain account that had full permissions to \myotherserver\mydirectories. This was a 'vanilla' domain account that was manually created by us. We did not capture what the user of the process was but that may be another useful data point.

该选项是可能的，但是它违反了IIS 7.5的最佳实践，并且由于相当严格的IT策略，在我们的生产环境中可能不允许使用此选项.

This option may be possible, however it breaks away from best practices with IIS 7.5 and may not be allowed in our production environment due to fairly stringent IT policies.

第三个测试是在我的开发计算机 mydevmachine 上本地运行该站点.我的本地IIS配置与 mywebserver 相同，除了我运行的是Windows 7而不是Windows Server2008.我向授予了 mydomain \ mydevmachine 的完全权限\ myotherserver \ mydirectories 并运行该应用程序.文件已成功写入.根据进程监视器，该进程的用户已正确设置为 IIS APPPOOL \ My.Site.Com .

The third test was to run the site locally on my development machine, mydevmachine. My local IIS configuration is identical to mywebserver with the exception that I am running Windows 7 instead of Windows Server 2008. I granted full permissions for mydomain\mydevmachine to the \myotherserver\mydirectories and ran the application. The file was successfully written. According to Process Monitor the user for the process was correctly set to IIS APPPOOL\My.Site.Com.

我们希望启用使用 mywebserver 的计算机帐户设计的写访问权限.我们已阅读> ApplicationPoolIdentity用户无法修改共享中的文件Windows Server 2008中的文件夹和

We would like to enable write access as designed using the machine account of mywebserver. We have read ApplicationPoolIdentity user cannot modify files in shared folder in Windows Server 2008 and Permissions for Shared Folder for IIS 7 Application Pool Identity Across Domain and Application Pool Identities.

根据此信息，我们应该能够使用机器帐户来授予对诸如UNC路径之类的网络资源的读写访问权限.实际上，当从我的开发机器上运行网站时，我可以按照期望的方式进行操作.

According to this information we should be able use the machine account to grant read and write access to networked resources such as the UNC path. In fact, I can do this in the desired manner when running the web site from my development machine.

我想到了一些想法.测试Web服务器的机器帐户可能有问题.或者，也许是其他"软件以某种方式干扰了该过程.

There are a couple thoughts that come to mind. Perhaps there is something wrong with the machine account of the test web server. Or perhaps that 'other' software is interfering with the process somehow.

关于什么可能导致此问题的任何想法?我们还应该做些什么来排除故障?

Any thoughts as to what may be causing this issue? What else should we do to troubleshoot?

推荐答案

1. 重新启动"mywebserver".

1. Reboot your 'mywebserver'.

惊叹于现在神秘的功能ApplicationPoolIdentity.

Marvel at the now mysteriously functional ApplicationPoolIdentity.

安装MS HotFix KB2545850 ，并在 KB2672809 ，它还显示了重现和演示此表面上随机问题的步骤.直接下载链接此处.

Install MS HotFix KB2545850 and learn the details about this bug in KB2672809 which also shows the steps to reproduce and demonstrate this apparently random problem. Direct download link here.

推测自此修补程序发布以来的三年之内，Microsoft为什么仍未设法发布正常的Windows更新.由于这个晦涩的问题，人们仍然继续跑进去并拔掉头发.

Speculate why Microsoft has not managed to release a normal windows update for this in the 3 years since that hotfix was published. While people still continue running into it and pulling their hair out because of this obscure problem.

了解来自MS的其他分享和享受礼物的人，他们仍然继续奉献:

Learn about the other folks who have shared and enjoyed this gift from MS that still continues to keep on giving:

• 使用应用程序池标识的IIS应用程序丢失主令牌吗?
• DirectoryServicesCOMException 80072020从IIS 7.5站点在ApplicationPoolIdentity下运行
• ApplicationPoolIdentity无法访问网络资源
• ApplicationPoolIdentity IIS 7.5到SQL Server 2008 R2无法正常工作
• Windows使用应用程序池标识时身份验证失败

• IIS application using application pool identity loses primary token?
• DirectoryServicesCOMException 80072020 From IIS 7.5 Site Running Under ApplicationPoolIdentity
• ApplicationPoolIdentity cannot access network resources
• ApplicationPoolIdentity IIS 7.5 to SQL Server 2008 R2 not working
• Windows Authentication Failed when using application pool identity
• IIS 7.5 stops using machine account to connect to network resource when using AppPoolIdentity

您的Windows 7开发人员计算机可能工作正常，因为它比服务器更频繁地重新启动.恭喜，您撰写的书面报告非常详尽且完整.我很少在这里看到.

Your Windows 7 dev machine probably worked fine because it reboots more often than the server. Congrats on your very well written and thorough bug report. I rarely see that here.

这篇关于在IIS 7.5和Windows Server 2008 R2下向ASP.NET的联网UNC文件夹授予写权限的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！