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, который мы пытаемся записать, - это \myotherserver\mydirectories\output, где 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 попытался создать файл в нужном месте, но сообщил о результате ACCESS DENIED. Пользователем каждой конфигурации был IIS APPPOOL\My.Site.Com, как и ожидалось.

• Предоставление прав доступа mydomain\mymachine $к\myotherserver\mydirectories
• Предоставление прав доступа mydomain\mymachine $для\myotherserver\mydirectories\output

ПРИМЕЧАНИЕ. Я также попытался изменить код, чтобы он читал простой файл из \myotherserver\mydirectories\output. когда пытаясь прочитать файл, процесс завершается неудачно с ACCESS DENIED как это было при записи файла.

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

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

Предоставить локальные разрешения IIS APPPOOL\My.Site.Com

Первой конфигурацией для работы было предоставление IIS APPPOOL\My.Site.Com полных разрешений для \myotherserver\mydirectories. Файл был успешно написан, однако пользователь процесса был совершенно неожиданно учетной записью домена, которая была настроена для веб-приложения на той же машине на другом веб-сайте. Это остается очень запутанным, но работает, так как у "другой" учетной записи также есть права на запись в общий ресурс.

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

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

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

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

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

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

Заключение

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

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

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

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