Веб-сайт не может получить правильное разрешение на запись в папку под Windows 2012R2 с IIS 8.5, даже если «IIS APPPOOL\PoolName» установлен правильно

Question

У меня возникают конкретные проблемы в отношении IIS 8.5, Разрешения и Аудит. У меня есть приложение PHP, работающее под идентификатором KanboardPool, и я правильно установил разрешения для папки «data» приложения в «IIS APPPOOL\KanboardPool» для полного контроля.

Кроме того, я установил для IIS_IUSRS значение «Чтение», «Выполнение» и «Список» в той же папке, включая родительский. Несмотря на; Я все еще получаю разрешение отказано в неудачах.

Я пытаюсь АУДИРОВАТЬ сбои доступа к файлам без особой удачи: сначала через Политику домена GPO -> Конфигурация компьютера -> Параметры Windows -> Параметры безопасности -> Расширенный аудит -> Аудит доступа к файлу и неудачи. Который не регистрировал никаких ошибок аудита. Та же самая процедура через Политику Контроллера домена и наконец через Локальную Политику по любой причине. Изменение политики аудита добавляется, а затем удаляется позже.

Через ACL я выполнил тест «Эффективный доступ» для выбранного принципала «IIS APPPOOL\KanboardPool», который прошел с плавающими цветами. Теперь я просто в тупик?

Answer 1

Что делает эту проблему особенно трудной для диагностики, так это то, что ее невозможно воспроизвести на веб-сайте по умолчанию. Когда я поместил то же приложение в C:\inetpub\wwwroot\subfoldeer\phpapplication под удостоверением DefaultAppPool .

Мне было очень легко просто добавить Full Control в C:\inetpub\wwwroot\subfolder\phpapplication\data для DefaultAppPool и это просто сработало.

После прочтения http://www.iis.net/learn/get-started/planning-for-security/secure-content-in-iis-through-file-system-acls ; с fcgi.impersonate в php.ini ; он будет автоматически выдавать себя за аутентифицированного пользователя. Виола, отключив эту функцию, процесс PHP принял AppPoolIdentity и работает как положено.

Что объясняет, почему я не получаю сбои доступа к файлу для KanboardPool. Однако это не объясняет, в то время как fcgi.impersonate который был включен в Default Web Site, изначально не воспроизводил то же самое поведение.