Estou tendo problemas específicos em relação ao IIS 8.5, permissões e auditoria. Eu tenho um aplicativo PHP em execução sob a identidade KanboardPool e configurei corretamente as permissões na pasta 'data' do aplicativo para 'IIS APPPOOL\KanboardPool' para controle total.
Além disso, configurei IIS_IUSRS para ler, executar e listar na mesma pasta, incluindo o pai. Sem considerar; Ainda recebo falhas de permissão negada.
Tentei auditar falhas de acesso a arquivos sem muita sorte: primeiro por meio da Política de Domínio GPO -> Configuração do Computador -> Configurações do Windows -> Configurações de Segurança -> Auditoria Avançada -> Sucesso e Falha no Acesso ao Arquivo de Auditoria. Que não registrou nenhuma falha de auditoria. O mesmo procedimento através da Política de Controlador de Domínio e finalmente através da Política Local por qualquer motivo. A alteração da política de auditoria é adicionada e removida posteriormente sucessivamente.
Por meio do ACL, executei um teste de acesso efetivo no principal selecionado 'IIS APPPOOL\KanboardPool', que passou com louvor. Agora estou perplexo?
Responder1
O que tornou esse problema particularmente difícil de diagnosticar é que ele não era reproduzível sobSite padrão. Quando coloquei o mesmo aplicativo C:\inetpub\wwwroot\subfoldeer\phpapplicationem DefaultAppPoolidentidade.
Foi muito fácil para mim simplesmente adicionarControlo totalpara C:\inetpub\wwwroot\subfolder\phpapplication\datafor DefaultAppPoole simplesmente funcionou.
Depois de lerhttp://www.iis.net/learn/get-started/planning-for-security/secure-content-in-iis-through-file-system-acls; com fcgi.impersonateativado php.ini; ele representará automaticamente o usuário autenticado. Viola, desativando esse recurso, o processo PHP assumiu o AppPoolIdentity e funcionou conforme o esperado.
O que explica por que não estava tendo falhas de acesso a arquivos no KanboardPool. No entanto, isso não explica enquanto fcgi.impersonateestava ativado emSite padrãoinicialmente não estava reproduzindo o mesmo comportamento.