Website erhält keine ordnungsgemäße Berechtigung zum Schreiben in einen Ordner unter Windows 2012R2 mit IIS 8.5, obwohl „IIS APPPOOL\PoolName“ ordnungsgemäß festgelegt ist

Website erhält keine ordnungsgemäße Berechtigung zum Schreiben in einen Ordner unter Windows 2012R2 mit IIS 8.5, obwohl „IIS APPPOOL\PoolName“ ordnungsgemäß festgelegt ist

Ich habe spezielle Probleme in Bezug auf IIS 8.5, Berechtigungen und Auditing. Ich habe eine PHP-Anwendung, die unter der Identität KanboardPool läuft, und ich habe die Berechtigungen für den Anwendungsordner „data“ ordnungsgemäß auf „IIS APPPOOL\KanboardPool“ für die vollständige Kontrolle eingestellt.

Außerdem habe ich IIS_IUSRS so eingestellt, dass es im selben Ordner (einschließlich des übergeordneten Ordners) liest, ausführt und auflistet. Trotzdem erhalte ich immer noch die Fehlermeldung „Berechtigung verweigert“.

Ich habe versucht, Dateizugriffsfehler zu ÜBERPRÜFEN, aber ohne viel Erfolg: Zuerst über GPO-Domänenrichtlinie -> Computerkonfiguration -> Windows-Einstellungen -> Sicherheitseinstellungen -> Erweiterte Überwachung -> Erfolgreiche und fehlgeschlagene Dateizugriffe überwachen. Dabei wurden keine Überwachungsfehler protokolliert. Gleiches Verfahren über Domänencontrollerrichtlinie und schließlich aus irgendeinem Grund über lokale Richtlinie. Die Änderung der Überwachungsrichtlinie wird hinzugefügt und später nacheinander entfernt.

Über ACL habe ich einen Effective Access-Test für den ausgewählten Principal „IIS APPPOOL\KanboardPool“ ausgeführt, der mit Bravour bestanden wurde. Jetzt bin ich einfach ratlos?

Antwort1

Was die Diagnose dieses Problems besonders schwierig machte, war die Tatsache, dass es nicht reproduzierbar war unterStandardwebsite. Als ich den gleichen Antrag unter „Identität“ gestellt C:\inetpub\wwwroot\subfoldeer\phpapplicationhabe DefaultAppPool.

Es war sehr einfach für mich, einfach hinzuzufügenVolle Kontrollezu C:\inetpub\wwwroot\subfolder\phpapplication\datafür DefaultAppPoolund es hat einfach funktioniert.

Nach dem Lesenhttp://www.iis.net/learn/get-started/planning-for-security/secure-content-in-iis-through-file-system-acls; wenn fcgi.impersonatein ; aktiviert ist php.ini, wird automatisch die Identität des authentifizierten Benutzers angenommen. Viola, wenn diese Funktion deaktiviert wird, übernimmt der PHP-Prozess die AppPoolIdentity und funktioniert wie erwartet.

Das erklärt, warum ich keine Dateizugriffsfehler für KanboardPool bekam. Es erklärt jedoch nicht, wann fcgi.impersonatedas eingeschaltet war unterStandardwebsitewurde zunächst nicht dasselbe Verhalten reproduziert.

verwandte Informationen