Welche Rolle spielt „App Pool Identity“ für einen Anwendungspool?

Wenn es um die Sicherheit von IIS 7.5 geht, führt AFAIK Folgendes aus:

App Pool Identity entscheidet, als wen meine Webanwendung ausgeführt wird.

Die Authentifizierungsmethode entscheidet, als wen die Clients authentifiziert werden.

Ich habe einen virtuellen Ordner wie folgt konfiguriert:

• Ich verwende die anonyme Authentifizierung mit der Erwartung, dass alle Clients als IUSR authentifiziert werden .
• Ich gebe IUSR die volle Kontrolle über den Ordner.
• Meine App-Pool-Identität ist als XXX-Konto festgelegt, das keine Berechtigung für den Ordner hat. (Ich habe dies absichtlich festgelegt)

Es stellt sich jedoch heraus, dass ich die Dateien in diesem Ordner nicht durchsuchen kann. Sobald ich dem XXX-Konto die Berechtigung zum Zugriff auf diesen Ordner erteile, läuft alles gut.

Welche Rolle spielt die App Pool-Identität bei der anonymen Authentifizierung? Es ist völlig unerwartet, dass ich dem App Pool Identity-Konto die Berechtigung erteilen muss, auf den Ordner zuzugreifen. Ich dachte, anonyme Authentifizierung wäre genug?

Vielen Dank.

Viele überladene Begriffe und ein Wechsel zwischen IIS 7 und 7.5.

App-Pool-Identität vs. App-Pool-Konto

Beginnen wir mit der Identität des Anwendungspools (Kleinbuchstabe I, auch bekannt als App Pool Account ):

Meiner Meinung nach ist das Anwendungspoolkonto das Konto, das zum Starten eines App-Pools verwendet wird, und die Identität, die der App-Pool annimmt, wenn er sich nicht als jemand anderes ausgibt.

Unabhängig von der Identität, die Sie dem App Pool geben, muss er die Dateien im Inhaltsordner lesen können : insbesondere alle web.config-Dateien (die Teil der IIS-Konfiguration sind und steuern, welche Dateien im Inhaltsordner enthalten sind) App Pool wird ausgeführt).

Wenn es nicht auf einen Ordner zugreifen kann, wird davon ausgegangen, dass sich dort möglicherweise eine wichtige (sich ändernde) web.config-Datei befindet, und es wird ein Fehler angezeigt. So ist die App - Pool - Konto muss lesen Zugriff auf alle Content - Ordner.

ApplicationPoolIdentity

Warum sollte das App-Pool-Konto (die Identität des App-Pools) von der App-Pool-Identität unterschieden werden? Da die besonderen Kapitale verwendete Application ist ein neues Konto Art - ein verwaltetes Dienstkonto - eingeführt und aus Standard in IIS 7.5 / Windows 2008 R2 und die von Windows 2008 SP2 als auch (aber nicht der Standardeinstellung).

Siehe Anwendungspoolidentitäten in IIS.Net

Wenn Sie eine Website unter R2 über die GUI erstellen:

• Es wird ein App-Pool zum Hosten dieser Website erstellt
• Der Kontotyp lautet "ApplicationPoolIdentity" anstelle von "Network Service" (Standardeinstellung 2008), "Local Service" oder "Local System".

Bei 2008 RTM lautete das Standardkonto für den App-Pool "Netzwerkdienst" plus eindeutige Identität / Eindeutigkeit des App-Pools. Der neue R2 / SP2 AppPoolIdentity Kontotyp ist ein Netzwerk-Service- wie Konto (dh der Computer beim Anschließen Off-Box), verhindert aber der Identitätswechsel eines anderen AppPool innerhalb derselben Box.

Zurück zur ursprünglichen Frage:

• Das App-Pool-Konto definiert, wer Ihre App ausführt, wenn sie sich nicht als jemand anderes ausgibt

• Die Authentifizierungsmethode beschreibt, wie Sie die Clients authentifizieren (um sich als solche auszugeben).

• Das anonyme Benutzerkonto definiert, wen Sie ausführen möchten, wenn Sie die Identität eines Benutzers für eine nicht authentifizierte Anforderung annehmen. IUSR ist ein solcher Benutzer.

Übrigens können Sie mit IIS 7.5 das anonyme Benutzerkonto als Anwendungspoolidentität festlegen (Eigenschaften der anonymen Authentifizierungsmethode), wodurch das Isolieren und Sichern des Inhalts für eine bestimmte Website möglicherweise einfacher wird.

Legen Sie die Berechtigungen mit IIS AppPool \ YourSiteName für das Namensformat fest. (siehe auch diesen Beitrag )

Sie sehen zwei Dinge, die in ASP.NET häufig verwirrt sind:

1. "Benutzeridentität" - Die Authentifizierung eines Benutzerkontos hat nichts mit dem Konto oder der Identität zu tun, die tatsächlich unter IIs und ASP.NET ausgeführt werden. Mit der anonymen Authentifizierung kann jeder Benutzer auf öffentliche Inhalte zugreifen, ohne den Client-Browser nach Benutzername und Kennwort zu fragen. Das anonyme IUSR-Konto, das standardmäßig in IIS authentifiziert wird, gilt nur für den Zugriff auf öffentliche Website-Inhalte. Dies hat keine Auswirkungen auf die Prozesse oder Ressourcen, die von den zugrunde liegenden IIs oder ASP.NET-Diensten verwendet werden.
2. "Anwendungsidentität" - Dies ist das tatsächliche Konto "WindowsIdentity" auf dem Server, das tatsächlich hinter IIS und ASP.NET ausgeführt wird. Hierbei handelt es sich um das Konto "Anwendungspoolidentität", das dem Pool von IIs zugewiesen und ASP.NET zugewiesen wurde. Ihr ASP.NET-Prozess wird standardmäßig unter diesem Anwendungspoolidentitätskonto (in IIs Version 7.5+ als virtuelles Konto bezeichnet) ausgeführt.

Erläuterung: Erstens ist "Authentifizierung" in ASP.NET nur ein Ereignis, das normalerweise in der Datei "web.config" eingerichtet wird und ein bestimmtes Benutzerkonto anmeldet, das von IIs als einfaches HttpContext-Objekt an ASP.NET übergeben wird. dh die aktuelle Sitzung oder den Kontext des aktuellen Benutzers. Die WindowsIdentity, mit der der ASP.NET-Prozess ausgeführt wird, wird nicht geändert. Sie übergibt lediglich ein Benutzer-ID-Token. Mit HttpContext kann Ihr Code diese ID oder diesen Namen verwenden, um Datenbankrechte für verschiedene Bereiche Ihrer Website zu speichern. Der Dateizugriff durch ASP.NET wird dadurch jedoch nicht beeinträchtigt, da die Identität des tatsächlichen Anwendungskontos "process", mit dem ASP.NET unter II ausgeführt wird, nicht geändert wird.

Dies geschieht erst, wenn Sie "Identitätswechsel" ausführen, wodurch ASP.NET angewiesen wird, den Identitätswechsel für alle Token vorzunehmen, die IIs an das System übergeben, und diese dann unter dieser Konto-ID auszuführen. Sie können einen Identitätswechsel in Ihrer web.config festlegen. Wenn Sie den Identitätswechsel in ASP.NET aktivieren, ändert sich die WindowsIdentity auf dem Arbeitsprozess zu dem authentifizierten Konto, das von IIS an ASP.NET übergeben wird, und Sie können dann auf Dateien zugreifen, natürlich basierend auf den Rechten, die Sie diesem Benutzerkonto zuweisen. Es ist wichtig zu wissen, wann dies auftritt, und ASP.NET kann zu seiner Standardprozessidentität zurückkehren, die in den aktuellen II-Versionen wieder dem Anwendungspoolidentitätskonto entspricht, das einem bestimmten Anwendungspool zugewiesen ist.

Wenn IIs nur das anonyme Benutzerkonto ohne explizite Authentifizierung in ASP.NET verwendet, startet IIs standardmäßig das Anwendungspoolidentitätskonto des zugewiesenen Anwendungspools der Website und übergibt es an ASP.NET und den Worker-Prozess, der es ausführt. Dieses Anwendungspool-Identitätskonto verarbeitet alle Anforderungen für IIS und führt ASP.NET für diese Site aus.

Wenn IIs unter diesem Setup gestartet wird und ein Benutzer darauf zugreift, authentifiziert es tatsächlich standardmäßig das anonyme IUSR-Konto, das den Zugriff auf Webseiten und andere grundlegende Ressourcen bestimmt. Dieses Konto wird jedoch NICHT an ASP.NET übergeben. Dies hat keine Auswirkungen auf die Ausführung von Application Pool Identity IIS und die Ausführung von ASP.NET unter.

Wenn Sie "Impersonate" in Ihrer Datei "web.config" auf "true" setzen, UND Sie das standardmäßige anonyme IUSR-Konto in IIs für den öffentlichen Zugriff verwenden, UND Sie die Eigenschaft "anonymousAuthentication" in der Datei "web.config" explizit auf "true" setzen (anstatt Windows zu verwenden) oder ein anderes Anmeldekonto), IIs wirft die Identität des Anwendungspools heraus und IIs und ASP.NET führen ihre Anwendungsprozesse jetzt als anonymes IUSR-authentifiziertes und imitiertes Konto aus.

Wenn Sie dies tun, werden ASP.NET und seine Prozesse jetzt unter dem IUSR-Konto ausgeführt. Das heißt, der Anwendungsprozess von ASP.NET führt sein WindowsIdentity-Konto als IUSR-Konto aus. Sie können jetzt Lese- / Schreibzugriff auf dieses anonyme IUSR-Konto und auf die Ordner anwenden, auf die dieses Konto zugreifen soll. (Hinweis: Stellen Sie jedoch sicher, dass Sie das Standardprozesskonto, das Anwendungspoolkonto für den Pool und die Rechte für diese Ordner hinzufügen. Dies entspricht der Empfehlung von Microsoft.)

Viel Glück!

Es gibt zwei Authentifizierungskontexte. Der Webserverprozess (der Ihre Webanforderungen verarbeitet) wird als Benutzer der App Pool-Identität ausgeführt. Wenn eine Anforderung für Ihren virtuellen Host eingeht, übernimmt der Anwendungspool die Identität des Benutzers, der in den "Anonymen Authentifizierungsanmeldeinformationen" der jeweiligen Site aufgeführt ist - standardmäßig IUSR.

Alle Skripte, die auf Ihrer Website ausgeführt werden, werden als IUSR ausgeführt. Die Protokollierung und bestimmte andere Funktionen werden jedoch als App-Pool-Benutzer ausgeführt (standardmäßig der Netzwerkdienst - obwohl dies kürzlich geändert wurde, um einen speziellen virtuellen App-Pool-Benutzer zu verwenden). Die App Pool-Identität (Netzwerkdienst) muss in der Lage sein, die Dateien in Ihrem Verzeichnis aufzulisten, da bestimmte Überprüfungen im Anforderungsstapel durchgeführt werden, bevor die Steuerung an Ihr Skript übergeben wird.

Es wird empfohlen, eine Site pro Pool auszuführen und die App-Pool-Identität so festzulegen, dass sie als derselbe Benutzer wie der anonyme Benutzer Ihrer Website ausgeführt wird. Es ist möglich, aus dem anonymen Benutzerkontext (IUSR) auszubrechen und die Berechtigungen auf die der App Pool-Identität selbst zu erhöhen.