У меня есть определенные проблемы в отношении IIS 8.5, разрешений и аудита. У меня есть приложение PHP, работающее под удостоверением KanboardPool, и я правильно установил разрешения на папку приложения 'data' для 'IIS APPPOOL\KanboardPool' для полного контроля.
Кроме того, я установил IIS_IUSRS на чтение, выполнение и список в той же папке, включая родительскую. Независимо от этого; я все еще получаю отказы в доступе.
Я пытался провести АУДИТ сбоев доступа к файлам, но без особого успеха: сначала через Политику домена GPO -> Конфигурация компьютера -> Параметры Windows -> Параметры безопасности -> Расширенный аудит -> Аудит успешных и неудачных попыток доступа к файлам. Который не зарегистрировал никаких сбоев аудита. Та же процедура через Политику контроллера домена и, наконец, через Локальную политику по какой-то причине. Изменение политики аудита добавляется, а затем удаляется позже последовательно.
Через ACL я провел тест эффективного доступа на выбранном Principal 'IIS APPPOOL\KanboardPool', который прошел с блеском. Теперь я просто в тупике?
решение1
Особенно трудной для диагностики этой проблемы является то, что ее невозможно воспроизвести приВеб-сайт по умолчанию. Когда я разместил то же самое приложение под C:\inetpub\wwwroot\subfoldeer\phpapplicationименем DefaultAppPool«Идентификация».
Мне было очень легко просто добавитьПолный контрольк C:\inetpub\wwwroot\subfolder\phpapplication\datafor 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это было включено подВеб-сайт по умолчаниюизначально не воспроизводил то же самое поведение.