O site não conseguiu obter permissão adequada para gravar em uma pasta no Windows 2012R2 com o IIS 8.5, embora 'IIS APPPOOL \ PoolName' esteja definido corretamente

0

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 eu 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, inclusive pai. Independentemente; Ainda recebo permissão negada falhas.

Tento AUDITAR falhas de acesso a arquivos sem muita sorte: primeiro por meio da diretiva de domínio do GPO - > Configuração do Computador - > Configurações do Windows - > Configurações de segurança - > Auditoria Avançada - > Auditoria de sucesso e falha no acesso a arquivos. Que não registrou nenhuma falha de auditoria. O mesmo procedimento através da Política do 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, em seguida, removida em seguida.

Por meio do ACL, executei um teste de Acesso Eficaz no Principal selecionado 'IIS APPPOOL \ KanboardPool', que foi aprovado com sucesso. Agora estou apenas perplexo?

    
por horace 02.05.2015 / 22:09

1 resposta

0

O que tornou esse problema particularmente difícil de diagnosticar é que isso não era reproduzível em Site padrão . Quando coloquei o mesmo aplicativo em C:\inetpub\wwwroot\subfoldeer\phpapplication em DefaultAppPool identity.

Foi muito fácil simplesmente adicionar Controle total a C:\inetpub\wwwroot\subfolder\phpapplication\data para DefaultAppPool e isso simplesmente funcionou.

Depois de ler o link ; com fcgi.impersonate ativado em php.ini ; ele representará automaticamente o usuário autenticado. Viola, desligando esse recurso, o processo do PHP assumiu o AppPoolIdentity e funciona conforme o esperado.

Que explica porque eu não estava tendo falhas de acesso a arquivos para o KanboardPool. No entanto, isso não explica enquanto fcgi.impersonate que foi ativado em Default Web Site inicialmente não estava reproduzindo o mesmo comportamento.

    
por 06.05.2015 / 11:04