BLUF

наше приложение пытается записать файл в папку UNC с помощью ASP.NET веб-служба, работающая под .NET 4.5, IIS 7.5 и Windows Server 2008 R2. Однако любая попытка записать файл в нужное место приводит к исключению с отказом в доступе.

задача кажется простой, однако я и моя команда устраняли неполадки в течение некоторого времени, и мы в тупике относительно того, что может быть причиной ошибки. Ниже приведены детали нашей установки и что мы постарались и нашли до сих пор. Имена были изменены, чтобы защитить невинных.

Настройки Среды

веб-сервер, mywebserver, имеет веб-сайт с именем My.Site.Com с соответствующим пулом приложений с именем My.Site.Com. Пул приложений настроен, как показано ниже.

 .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, который мы пытаемся написать, это myotherservermydirectoriesoutput где mydirectories является фактической долей. На этом общем ресурсе группе домена mygroup-www были предоставлены полные разрешения на общий ресурс и все подпапки. Учетная запись машины (т. е. mywebserver)является членом этой группы mygroup-www.

Примечание: На данный момент этот путь UNC фактически живет на том же машина, mywebserver. Однако, это в конечном итоге будет перенесен на другую машину чем mywebserver в нашей испытательной среде и в производственная среда когда это будет готово. В настоящее время у меня есть только одна тестовая среда для устранения неполадок.

ошибка может быть реплицирована путем выполнения следующего кода.

[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 процесс попытался создать файл в нужном месте, но сообщил о результате ДОСТУП ЗАПРЕЩЕН. Пользователь каждой конфигурации был IIS APPPOOLMy.Site.Com как и ожидалось.

1. о предоставлении mydomainmymachine$ полный доступ к myotherservermydirectories
2. о предоставлении mydomainmymachine$ полный доступ к myotherservermydirectoriesoutput

примечание: Я также попытался изменить код, чтобы он читать a простой файл из myotherservermydirectoriesoutput. Когда попытка читать файл, процесс завершается с отказом в доступе сообщение как это было при записи файла.

Успешные Попытки

мы также попробовали несколько конфигураций, которые работал.

предоставить локальный IIS APPPOOLMy.Site.Com разрешения

первая конфигурация для работы должна была предоставить IIS APPPOOLMy.Site.Com полные разрешения на myotherservermydirectories файл был успешно написан, однако пользователь процесса был довольно неожиданно учетной записью домена, которая была настроена для веб-приложения на той же машине на другом веб-сайте. Это остается очень запутанным, но работает как "другая" учетная запись также имеет разрешения на запись в общий ресурс.

это не будет работать в производстве, поскольку мы не можем использовать локальные учетные записи для предоставления доступа к сетевым ресурсам, но тем не менее является интересной точкой данных.

измените идентификатор пула приложений на пользователя домена

вторая конфигурация, которая работала, должна была изменить My.Site.Com пул приложений идентифицирует учетную запись домена, которая имела полные разрешения на myotherservermydirectories. Это была ваниль. учетная запись домена, созданная нами вручную. Мы не захватили, что пользователь процесса был, но это может быть еще одна полезная точка данных.

этот вариант может быть возможен, однако он отрывается от лучших практик с IIS 7.5 и не может быть разрешен в нашей производственной среде из-за довольно строгой ИТ-политики.

запустите сайт на моей машине разработки

третий тест должен был запустить сайт локально на моей машине разработки, mydevmachine. Моя локальная конфигурация IIS идентична mywebserver за исключением того, что я запускаю Windows 7 вместо Windows Server 2008. Я предоставил полные разрешения для mydomainmydevmachine до myotherservermydirectories и запустил приложение. Файл был успешно написан. Согласно Process Monitor пользователь для процесса был правильно установлен в в IIS APPPOOLMy.Site.Com.

вывод

мы хотели бы включить доступ на запись, как это предусмотрено с помощью учетной записи машины mywebserver. Мы читали ApplicationPoolIdentity пользователь не может изменять файлы в общей папке в Windows Server 2008 и разрешения для общей папки для удостоверения пула приложений IIS 7 в домене и Удостоверения Пула Приложений.

по этому информация мы должны иметь возможность использовать учетную запись компьютера для предоставления доступа на чтение и запись к сетевым ресурсам, таким как путь UNC. Фактически, я могу сделать это желаемым образом при запуске веб-сайта с моей машины разработки.

есть пара мыслей, которые приходят на ум. Возможно, что-то не так с учетной записью компьютера тестового веб-сервера. Или, возможно, это "другое" программное обеспечение каким-то образом вмешивается в процесс.

какие мысли что может быть причиной этой проблемы? Что еще мы должны сделать для устранения неполадок?