Sito Web che non riesce ad acquisire l'autorizzazione appropriata per scrivere in una cartella in Windows 2012R2 con IIS 8.5 anche se 'IIS APPPOOL \ PoolName' è impostato correttamente

Sto avendo problemi specifici riguardo a IIS 8.5, Autorizzazioni e Auditing. Ho un'applicazione PHP in esecuzione con l'identità KanboardPool e ho impostato correttamente le permsions sulla cartella 'data' dell'applicazione su 'IIS APPPOOL \ KanboardPool' per il pieno controllo.

Inoltre, ho impostato IIS_IUSRS per leggere, eseguire ed elencare nella stessa cartella, incluso il genitore. Senza riguardo; Ricevo ancora permessi di autorizzazione negati.

Ho provato a VERIFICARE gli errori di accesso ai file senza molta fortuna: prima attraverso la politica dei domini di GPO - & gt; Configurazione del computer - & gt; Impostazioni di Windows - & gt; Impostazioni di sicurezza - & gt; Advance Auditing - & gt; Controlla accesso ai file riuscito e fallito. Che non ha registrato errori di audit. Stessa procedura attraverso la politica dei controller di dominio e infine tramite i criteri locali per qualsiasi motivo. La modifica dei criteri di controllo viene aggiunta e rimossa successivamente in successione.

Tramite ACL, ho eseguito un test di accesso effettivo sul prescelto 'IIS APPPOOL \ KanboardPool' che è passato a pieni voti. Ora sono solo perplesso?

Ciò che ha reso questo problema particolarmente difficile da diagnosticare è che questo non era riproducibile in Sito Web predefinito . Quando ho inserito la stessa applicazione sotto C:\inetpub\wwwroot\subfoldeer\phpapplication sotto DefaultAppPool identità.

È stato molto facile per me aggiungere semplicemente Pieno controllo a C:\inetpub\wwwroot\subfolder\phpapplication\data per DefaultAppPool e ha semplicemente funzionato.

Dopo aver letto http://www.iis.net/learn/get-started/planning-for-security/secure-content-in-iis-through-file-system-acls ; con fcgi.impersonate acceso php.ini; impersonerà automaticamente l'utente autenticato. Viola, disattivando questa funzione, il processo PHP ha assunto AppPoolIdentity e funziona come previsto.

Che spiega perché non stavo ottenendo errori di accesso ai file per KanboardPool. Tuttavia non spiega mentre fcgi.impersonate che è stato acceso sotto Sito Web predefinito inizialmente non stava riproducendo lo stesso comportamento.