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