Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
546 views
in Technique[技术] by (71.8m points)

iis 7.5 - Granting write permissions to a networked UNC folder for ASP.NET under IIS 7.5 and Windows Server 2008 R2

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?

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Answer

0 votes
by (71.8m points)
  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.


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...