Schreibzugriffsberechtigungen für IIS AppPoolIdentity und Dateisystem

Hier ist ein Problem mit IIS 7.5 und ASP.NET, mit dem ich recherchiert habe und mit dem ich nichts anfangen kann. Jede Hilfe wäre sehr dankbar.

Meine Frage lautet: Wie ermöglicht IIS und / oder das Betriebssystem unter Verwendung von ASP.NET in IIS 7.5, dass die Webanwendung in einen Ordner schreibt, wie C:\dumpwenn sie unter voller Vertrauenswürdigkeit ausgeführt wird? Wie kommt es, dass ich dem Anwendungspoolbenutzer (in diesem Fall ApplicationPoolIdentity) keinen expliziten Schreibzugriff hinzufügen muss ?

Soviel weiß ich:

• In IIS 7.5 lautet die Standardidentität für einen Anwendungspool ApplicationPoolIdentity.
• ApplicationPoolIdentity stellt ein Windows-Benutzerkonto mit dem Namen "IIS APPPOOL \ AppPoolName" dar, das beim Erstellen des Anwendungspools erstellt wird, wobei AppPoolName der Name des Anwendungspools ist.
• Der Benutzer "IIS APPPOOL \ AppPoolName" ist standardmäßig Mitglied der IIS_IUSRSGruppe.
• Wenn Sie unter Voll vertrauenswürdig ausgeführt werden , können Sie Ihre Web - Anwendung auf viele Bereiche des Dateisystems schreiben (ohne Ordner wie C:\Users, C:\Windowsusw.). Beispielsweise kann Ihre Anwendung in einige Ordner schreiben, z C:\dump.
• Standardmäßig IIS_IUSRSerhält die Gruppe keinen Lese- oder Schreibzugriff C:\dump(zumindest keinen Zugriff, der über die Registerkarte "Sicherheit" im Windows Explorer angezeigt wird ).
• Wenn Sie den Schreibzugriff verweigern IIS_IUSRS, wird beim Versuch, in den Ordner zu schreiben (wie erwartet), eine SecurityException angezeigt.

Wie wird dem Benutzer "IIS APPPOOL \ AppPoolName" unter Berücksichtigung all dessen Schreibzugriff gewährt? Der Prozess w3wp.exe wird als dieser Benutzer ausgeführt. Wie kann dieser Benutzer also in einen Ordner schreiben, auf den er scheinbar keinen expliziten Zugriff hat?

Bitte beachten Sie, dass ich verstehe, dass dies wahrscheinlich aus Bequemlichkeitsgründen getan wurde, da es schwierig wäre, einem Benutzer Zugriff auf jeden Ordner zu gewähren, in den er schreiben muss, wenn Sie unter Full Trust ausgeführt werden. Wenn Sie diesen Zugriff einschränken möchten, können Sie die Anwendung jederzeit unter Medium Trust ausführen. Ich bin daran interessiert herauszufinden, wie das Betriebssystem und / oder IIS diese Schreibvorgänge zulässt, obwohl anscheinend kein expliziter Dateisystemzugriff gewährt wird.

Dem ApplicationPoolIdentitywird die Mitgliedschaft sowohl in der UsersGruppe als auch in der IIS_IUSRSGruppe zugewiesen . Auf den ersten Blick mag dies etwas besorgniserregend aussehen, jedoch hat die UsersGruppe etwas eingeschränkte NTFS-Rechte.

Wenn Sie beispielsweise versuchen, einen Ordner in dem C:\WindowsOrdner zu erstellen, werden Sie feststellen, dass dies nicht möglich ist. Der muss ApplicationPoolIdentityweiterhin in der Lage sein, Dateien aus den Windows-Systemordnern zu lesen (andernfalls wie könnte der Worker-Prozess wichtige DLLs dynamisch laden).

In Bezug auf Ihre Beobachtungen über das Schreiben in Ihren c:\dumpOrdner. Wenn Sie sich die Berechtigungen in den erweiterten Sicherheitseinstellungen ansehen, sehen Sie Folgendes:

Sehen Sie, dass die Sonderberechtigung geerbt wird von c:\:

Aus diesem Grund kann Ihre Site in diesen Ordner ApplicationPoolIdentitylesen und schreiben . Dieses Recht wird vom c:\Laufwerk geerbt .

In einer gemeinsam genutzten Umgebung, in der möglicherweise mehrere hundert Sites mit jeweils eigenem Anwendungspool und eigener Anwendungspoolidentität vorhanden sind, speichern Sie die Site-Ordner in einem Ordner oder Volume, in dem die UsersGruppe entfernt und die Berechtigungen so festgelegt wurden, dass nur Administratoren und die Das SYSTEM-Konto hat Zugriff (mit Vererbung).

Sie würden dann einzeln die erforderlichen Berechtigungen zuweisen, die jeweils IIS AppPool\[name]für den Site-Stammordner erforderlich sind.

Sie sollten auch sicherstellen, dass alle Ordner, die Sie erstellen, in denen Sie potenziell vertrauliche Dateien oder Daten speichern, die UsersGruppe entfernt haben. Sie sollten auch sicherstellen, dass alle von Ihnen installierten Anwendungen keine vertraulichen Daten in ihren c:\program files\[app name]Ordnern speichern und stattdessen die Benutzerprofilordner verwenden.

Also ja, auf den ersten Blick sieht es so aus, als hätte das ApplicationPoolIdentitymehr Rechte als es sollte, aber es hat tatsächlich nicht mehr Rechte als es die Gruppenmitgliedschaft vorschreibt.

Ein ApplicationPoolIdentity‚s die Gruppenmitgliedschaft kann mit Hilfe der untersucht werden SysInternals Explorer Prozesswerkzeug . Suchen Sie den Arbeitsprozess, der mit der gewünschten Anwendungspoolidentität ausgeführt wird (Sie müssen die User NameSpalte zur Liste der anzuzeigenden Spalten hinzufügen :

Zum Beispiel habe ich hier einen Pool mit dem Namen 900300Application Pool Identity von IIS APPPOOL\900300. Klicken Sie mit der rechten Maustaste auf Eigenschaften für den Prozess und wählen Sie die Registerkarte Sicherheit, die wir sehen:

Wie wir sehen können, IIS APPPOOL\900300ist ein Mitglied der UsersGruppe.

1. Klicken Sie mit der rechten Maustaste auf den Ordner.

2. Klicken Sie auf Eigenschaften

3. Klicken Sie auf die Registerkarte Sicherheit. Sie werden so etwas sehen:

4. Klicken Sie im obigen Bildschirm auf die Schaltfläche "Bearbeiten ...". Sie werden so etwas sehen:

5. Klicken Sie im obigen Bildschirm auf die Schaltfläche "Hinzufügen ...". Sie werden so etwas sehen:

6. Klicken Sie im obigen Bildschirm auf die Schaltfläche "Standorte ...". Sie werden so etwas sehen. Gehen Sie nun ganz oben in dieser Baumstruktur, wählen Sie Ihren Computernamen aus und klicken Sie auf OK.

7. Geben Sie nun "iis apppool \ your_apppool_name" ein und klicken Sie auf "Check Check Names". Wenn der Apppool vorhanden ist, wird Ihr Apppoolname im Textfeld mit Unterstreichung angezeigt. Klicken Sie auf OK.

8. Aktivieren / deaktivieren Sie den Zugriff, den Sie dem Konto gewähren müssen

9. Klicken Sie auf die Schaltfläche Übernehmen und dann auf OK.

Jeder Anwendungspool in IIs erstellt standardmäßig unter c: \ users einen eigenen sicheren Benutzerordner mit vollständiger Lese- / Schreibberechtigung. Öffnen Sie Ihren Benutzerordner und sehen Sie, welche Anwendungspoolordner vorhanden sind. Klicken Sie mit der rechten Maustaste und überprüfen Sie deren Rechte für das zugewiesene virtuelle Anwendungspoolkonto. Sie sollten sehen, dass Ihr Anwendungspoolkonto bereits mit Lese- / Schreibzugriff hinzugefügt wurde, der dem Stammverzeichnis und den Unterordnern zugewiesen ist.

Diese Art des Dateispeicherzugriffs erfolgt also automatisch und Sie sollten in der Lage sein, in die Ordner der Benutzerkonten der App-Pools zu schreiben, was Sie möchten, ohne etwas zu ändern. Aus diesem Grund wurden virtuelle Benutzerkonten für jeden Anwendungspool erstellt.

Ich habe dies versucht, um Zugriffsprobleme auf eine IIS-Website zu beheben, die sich in den Ereignisprotokollen → Windows → Anwendung wie folgt manifestierten :

Protokollname: Anwendung
Quelle: ASP.NET 4.0.30319.0
Datum: 05.01.2012 16:12:33 Uhr
Ereignis-ID: 1314
Aufgabenkategorie: Webereignis
Stufe: Information
Schlüsselwörter: Klassisch
Benutzer: N / A.
Computer: SALTIIS01

Beschreibung:
Ereigniscode: 4008 
Ereignismeldung: Die Dateiautorisierung für die Anforderung ist fehlgeschlagen. 
Veranstaltungszeit: 05.01.2012 16:12:33 Uhr 
Ereigniszeit (UTC): 06.01.2012 00:12:33 Uhr 
Ereignis-ID: 349fcb2ec3c24b16a862f6eb9b23dd6c 
Ereignisfolge: 7 
Ereigniseintritt: 3 
Ereignisdetailcode: 0 

Bewerbungs informationen: 
    Anwendungsdomäne: / LM / W3SVC / 2 / ROOT / Application / SNCDW-19-129702818025409890 
    Vertrauensstufe: Voll 
    Virtueller Anwendungspfad: / Application / SNCDW 
    Anwendungspfad: D: \ Sites \ WCF \ Application \ SNCDW \ 
    Maschinenname: SALTIIS01 

Prozessinformationen: 
    Prozess-ID: 1896 
    Prozessname: w3wp.exe 
    Kontoname: iisservice 

Anfrage Informationen: 
    Anforderungs-URL: http: //webservicestest/Application/SNCDW/PC.svc 
    Anforderungspfad: /Application/SNCDW/PC.svc 
    Benutzerhostadresse: 10.60.16.79 
    Benutzer: js3228 
    Ist authentifiziert: True 
    Authentifizierungstyp: Verhandeln 
    Thread-Kontoname: iisservice 

Am Ende musste ich der Windows- EveryoneGruppe Lesezugriff auf diesen Ordner gewähren, damit er ordnungsgemäß funktioniert.