在 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

查看:35
本文介绍了在 IIS 7.5 和 Windows Server 2008 R2 下为 ASP.NET 授予对联网 UNC 文件夹的写入权限的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

BLUF

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

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

环境设置

Web 服务器 mywebserver 有一个名为 My.Site.Com 的网站和一个名为 My.Site.Com 的相应应用程序池.应用程序池配置如下.

 .NET Framework 版本:v4.0启用 32 位应用程序:假托管管道模式:集成名称 : My.Site.Com身份:ApplicationPoolIdentity加载用户配置文件:错误

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

<块引用>

注意:目前,这条 UNC 路径实际上存在于相同的机器,mywebserver.然而,这最终将被转移到其他机器上在我们的测试环境和生产环境中比 mywebserver当它准备好了.目前,我只有一个测试环境可以进行故障排除.

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

[WebMethod][ScriptMethod(UseHttpGet = false, ResponseFormat = ResponseFormat.Json)]公共字符串 ExportReport(int reportId){尝试{字符串输出 = ConfigHelper.OutputPath + "test.html";//UNC路径字符串 url = ConfigHelper.VirtualPath + "test.html";string[] lines = { "Hello", "World!"};File.WriteAllLines(输出,行);//拒绝访问!返回网址;}catch (System.Exception ex){Logger.ErrorException("导出报告出错", ex);扔;}}

问题排查

失败的尝试

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

  1. 授予 mydomainmymachine$myotherservermydirectories 的完全权限
  2. 授予 mydomainmymachine$myotherservermydirectoriesoutput 的完全权限

<块引用>

注意:我还尝试修改代码,以便它读取一个myotherservermydirectoriesoutput 中的简单文件.什么时候尝试读取文件,过程失败并显示拒绝访问写入文件时的消息.

成功的尝试

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

授予本地 IIS APPPOOLMy.Site.Com 权限

第一个起作用的配置是授予 IIS APPPOOLMy.Site.Commyotherservermydirectories 的完全权限 该文件已成功写入,但是进程的用户出乎意料的是,一个域帐户是为另一个网站的同一台机器上的 Web 应用程序设置的.这仍然很令人困惑,但因为其他"帐户也有共享的写入权限.

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

将应用程序池标识更改为域用户

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

此选项可能是可行的,但它与 IIS 7.5 的最佳实践背道而驰,并且由于相当严格的 IT 政策,我们的生产环境可能不允许这样做.

在我的开发机器上运行网站

第三个测试是在我的开发机器 mydevmachine 上本地运行该站点.我的本地 IIS 配置与 mywebserver 相同,但我运行的是 Windows 7 而不是 Windows Server 2008.我向 授予了对 mydomainmydevmachine 的完全权限myotherservermydirectories 并运行该应用程序.文件已成功写入.根据进程监视器,进程的用户已正确设置为 IIS APPPOOLMy.Site.Com.

结论

我们希望使用 mywebserver 的机器帐户按设计启用写入访问权限.我们已阅读 ApplicationPoolIdentity 用户无法修改共享中的文件Windows Server 2008 中的文件夹跨域 IIS 7 应用程序池标识的共享文件夹权限应用程序池标识.

根据此信息,我们应该能够使用机器帐户授予对网络资源(例如 UNC 路径)的读写访问权限.事实上,当我从我的开发机器上运行网站时,我可以以所需的方式做到这一点.

有几个想法浮现在脑海中.可能是测试web服务器的机器账号有问题.或者也许是其他"软件以某种方式干扰了该过程.

对可能导致此问题的原因有任何想法吗?我们还应该做些什么来排除故障?

解决方案

  1. 重启你的mywebserver".

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

  3. 安装 MS HotFix KB2545850 并在 中了解有关此错误的详细信息href="http://support.microsoft.com/kb/2672809" rel="nofollow noreferrer">KB2672809 它还显示了重现和演示这个明显随机问题的步骤.直接下载链接这里.

  4. 推测为什么自该修补程序发布以来的 3 年内,Microsoft 没有设法为此发布正常的 Windows 更新.由于这个晦涩的问题,人们仍然继续遇到它并拔掉头发.

  5. 了解其他分享和享受 MS 礼物的人,这些礼物仍在继续给予:

您的 Windows 7 开发机器可能运行良好,因为它比服务器更频繁地重新启动.祝贺你写得非常好和彻底的错误报告.我很少在这里看到.

BLUF

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.

Environment Setup

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

The UNC path we are attempting to write to is myotherservermydirectoriesoutput 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.

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;
    }
}

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 APPPOOLMy.Site.Com as expected.

  1. Granting mydomainmymachine$ full permissions to myotherservermydirectories
  2. Granting mydomainmymachine$ full permissions to myotherservermydirectoriesoutput

NOTE: I have also tried modifying the code so that it would read a simple file from myotherservermydirectoriesoutput. 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.

Grant the local IIS APPPOOLMy.Site.Com permissions

The first configuration to work was to grant the IIS APPPOOLMy.Site.Com full permissions to myotherservermydirectories 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.

Change the App Pool Identity to Domain User

The second configuration that worked was to change the My.Site.Com application pool's identify to domain account that had full permissions to myotherservermydirectories. 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.

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.

Run the Site On My Development Machine

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 mydomainmydevmachine to the myotherservermydirectories and ran the application. The file was successfully written. According to Process Monitor the user for the process was correctly set to IIS APPPOOLMy.Site.Com.

Conclusion

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.

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.

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. Reboot your 'mywebserver'.

  2. Marvel at the now mysteriously functional ApplicationPoolIdentity.

  3. 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.

  4. 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.

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

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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆