Prozess- und Anforderungsidentität in ASP.NET

In diesem Artikel werden die Zugriffsrechte aufgeführt, die dem standardmäßigen Prozesskonto gewährt werden, und einige Fälle beschrieben, in denen diese Rechte für bestimmte Aufgaben möglicherweise zu restriktiv sind.

In der standardmäßigen Installation von ASP.NET unter Microsoft Windows 2000 und Microsoft Windows XP führt ASP.NET Webanwendungscode in einem Workerprozess aus. Die Identität dieses Prozesses verwendet standardmäßig ein lokales Konto, das ASPNET-Konto genannt wird (der vollständige Name lautet "aspnet_wp account"). In Betaversionen von ASP.NET ist "System" die Prozessidentität, ein leistungsstarkes administratives Konto, das viele Zugriffsrechte auf dem Computer beinhaltet. Für eine mit weniger Berechtigungen ausgestattete Standardinstallation verwendet die Originalversion von ASP.NET das schwächere ASPNET-Konto, das für die meisten Webanwendungen geeignet ist.

Hinweis: Wenn Sie die Microsoft-Internetinformationsdienste (IIS) 6.0 einsetzen, werden Ihre ASP.NET-Webanwendungen im Sicherheitskontext des Kontos "NetworkService" ausgeführt.

Konfigurieren der Prozessidentität

Sie können die Prozessidentität im Abschnitt <processModel> der Datei "Machine.config" im Unterverzeichnis "Config" des Installationsstammverzeichnisses konfigurieren. Die Attribute userName und password steuern die Identität des Prozesses. Die Standardwerte für diese Attribute lauten wie folgt: Die Werte machine und AutoGenerate weisen ASP.NET an, das integrierte ASPNET-Konto und ein nach dem Zufallsprinzip vergebenes, verschlüsseltes strenges Kennwort zu verwenden, das in der lokalen Sicherheitsautorität (Local Security Authority, LSA) für dieses Konto gespeichert ist.

Wenn Sie einen Prozess verwenden möchten, der über mehr Zugriffsrechte verfügt, können Sie das Attribut userName auf System setzen, wodurch der ASP-NET-Workerprozess mit derselben Identität wie der Prozess "Inetinfo.exe" ausgeführt wird. Der Prozess "Inetinfo.exe" wird standardmäßig unter der Identität "System" ausgeführt. Wenn Sie den ASP.NET-Workerprozess so konfigurieren, dass er die Identität "System" verwendet, kann der ASP.NET-Workerprozess auf fast alle Ressourcen auf dem lokalen Computer zugreifen. Auf Computern, auf denen Windows 2000 oder Windows XP ausgeführt wird, verfügt das Konto "System" ebenfalls über Netzwerk-Anmeldeinformationen und kann als Computerkonto auf Netzwerkressourcen zugreifen. Um den Prozess so zu konfigurieren, dass er unter der Identität "System" ausgeführt wird, ändern Sie das Attribut userName im Abschnitt <processModel> folgendermaßen:

Standardberechtigungen für das ASPNET-Konto

Das ASPNET-Konto wird als lokales Konto erstellt, wenn Sie ASP.NET installieren. Das ASPNET-Konto gehört nur zu der Benutzergruppe auf diesem Computer. Deshalb hat das ASPNET-Konto alle Rechte, die zu dieser Benutzergruppe gehören, und kann auf alle Ressourcen zugreifen, auf die die Benutzergruppe zugreifen kann. Das ASPNET-Konto übernimmt die folgenden Benutzerrechte von der Benutzergruppe:

• SeChangeNotifyPrivilege
• SeUndockPrivilege
• SeInteractiveLogonRight
• SeNetworkLogonRight

Zusätzlich zu diesen Rechten werden dem ASPNET-Konto auch folgende Rechte standardmäßig zugewiesen:

• SeServiceLogonRight
• SeBatchLogonRight
• SeDenyInteractiveLogonRight

ASP.NET gewährt spezifische Vollzugriffsberechtigungen für das ASPNET-Konto für folgende Ordner:

• Temporäre ASP.NET-Dateien
• %windir%\temp

Zusätzlich gewährt ASP.NET dem Microsoft .NET Framework-Installationsverzeichnis die Leseberechtigung.

Im Folgenden sind die Zugriffssteuerungslisten (Access Control Lists, ACLs) aufgelistet, die für das ASPNET-Konto benötigt werden. Die Standardinstallationen von Windows 2000 und Microsoft .NET Framework beinhalten folgende Zugriffssteuerungslisten:

• Speicherort: %installroot%\temporäre ASP.NET-Dateien
  Zugriffstyp: Lese-/Schreibzugriff auf den Ordner und Ordnerinhalt auflisten auf den Stammordner des Verzeichnisses
  Konto: Prozesskonto und konfigurierte Identitätswechselkonten
  Beschreibung: Dies ist die dynamische Kompilierungsposition von ASP.NET. Innerhalb dieses Speicherorts wird Anwendungscode in einem getrennten Verzeichnis für jede Anwendung erzeugt. Sie können das Attribut tempDir im Abschnitt <compilation> verwenden, um den Stammspeicherort zu konfigurieren.
  
  Hinweis: Wenn Sie "machine.config" so abändern, dass temporäre ASP.NET-Dateien an einem anderen Speicherort gespeichert werden, muss das ASPNET-Konto über den Zugriffstyp Ordnerinhalt auflisten auf der Stammebene des Laufwerks verfügen.
• Speicherort: %windir%\temp
  Zugriffstyp: Lese-/Schreibzugriff
  Konto: Prozesskonto
  Beschreibung: Dies ist der Speicherort, den XML-Webdienste (XML = Extensible Markup Language) verwenden, um Serialisierungsproxys zu erzeugen.
• Speicherort: Anwendungsverzeichnis
  Zugriffstyp: Lesen
  Konto: Prozesskonto und konfigurierte Identitätswechselkonten
  Beschreibung: Dies ist der Speicherort für den Anwendungsinhalt (nur Lesezugriff erforderlich).
  Weitere Informationen hierzu finden Sie auf folgender Website von Microsoft:
  http://msdn.microsoft.com/library/en-us/dnnetsec/html/SecNetHT01.asp

  (http://msdn.microsoft.com/library/en-us/dnnetsec/html/SecNetHT01.asp)
• Speicherort: Stammverzeichnis der Website ("%systemdrive%\inetpub\wwwroot" oder der Pfad, auf den die Standardwebsite verweist)
  Zugriffstyp: Lesen
  Konto: Prozesskonto und konfigurierte Identitätswechselkonten
  Beschreibung: ASP.NET versucht, Konfigurationsdateien zu lesen und Änderungen auf "Laufwerk:\inetpub\wwwroot\web.config" zu überwachen.
• Speicherort: %installroot%-Hierarchie
  Zugriffstyp: Lesen
  Konto: Prozesskonto und konfigurierte Identitätswechselkonten
  Beschreibung: ASP.NET muss in der Lage sein, auf .NET Framework-Assemblys der Datei "Machine.config" (im Unterverzeichnis "\Config" unter "%installroot%") zuzugreifen.
• Speicherort: %windir%\assembly
  Zugriffstyp: Lesen
  Konto: Prozesskonto oder konfigurierte Identitätswechselkonten
  Beschreibung: Dies ist der globale Assemblycache, der die freigegebenen Assemblys enthält.

Weitere Informationen über standardmäßige Zugriffssteuerungslisten für Windows 2000-Computer finden Sie im Microsoft-Whitepaper "Default Access Control Settings in Windows 2000" (Standardmäßige Zugriffssteuerungseinstellungen in Windows 2000), siehe Abschnitt Informationsquellen.

Hinweis: Standardmäßig hat das ASPNET-Konto generell nicht die entsprechenden Zugriffsrechte, um einige der in diesem Artikel beschriebenen Aufgaben durchzuführen.

Zugreifen auf Ressourcen

In den folgenden Abschnitten wird beschrieben, wie verschiedene Ressourcen verwendet werden. Sie können auf viele dieser Ressourcen lokal zugreifen, wenn Sie Identitätswechsel aktivieren und der Ressource Zugriff auf das imitierte Konto gewähren. Der Identitätswechsel funktioniert jedoch oft nicht, wenn Sie versuchen, auf Remoteressourcen zuzugreifen, es sei denn, die Anwendung verwendet einen Authentifizierungsmechanismus, der delegiert werden kann, wie etwa Kerberos- oder Standardauthentifizierung. Sie können außerdem COM+-Dienste verwenden, um auf Ressourcen zuzugreifen, wie im Abschnitt Ausführen von Code mit einer festen Identität beschrieben.

Verwenden von Dateiressourcen

Um einer Anwendung, die mit dem ASPNET-Konto ausgeführt wird, das Schreiben in Dateien zu ermöglichen, können Sie einen bestimmten Benutzer in einem Code imitieren, bevor Sie in die Dateien schreiben oder dem ASPNET-Konto Schreibberechtigungen zuweisen. Sie können Schreibberechtigungen für eine einzelne Datei oder für Verzeichnishierarchien zuweisen.

Wichtig: Wenn Sie dem ASPNET-Konto Schreibberechtigungen für eine einzelne Datei oder für Verzeichnishierarchien zuweisen, können alle ASP.NET-Webanwendungen, die auf dem ASPNET-Konto auf dem Server ausgeführt werden, in diese Datei oder in die Verzeichnishierarchien schreiben. Weitere Informationen zum Imitieren eines bestimmten Benutzers in einem Code finden Sie in folgendem Artikel der Microsoft Knowledge Base Gehen Sie folgendermaßen vor, um die Zugriffssteuerungsliste (Access Control List, ACL) für eine Datei zu ändern:

1. Öffnen Sie Windows Explorer.
2. Markieren Sie die Datei oder den Ordner, für die bzw. den Sie Berechtigungen ändern möchten.
3. Klicken Sie im Menü Datei auf Eigenschaften.
4. Klicken Sie auf die Registerkarte Sicherheit. Aktivieren Sie die Kontrollkästchen für die Zugriffssteuerungslisten-Berechtigungen.

Sie können auch ein Skript oder das Befehlszeilenprogramm "Cacls.exe" (in Windows enthalten) verwenden, um die Zugriffssteuerungsliste für eine Datei zu ändern.

ASP.NET 1.1 verwendet den Ordner "<Laufwerkname>\Dokumente und Einstellungen\<Computername>\ASPNET" zum Speichern der Prozessdateien (dabei steht <Laufwerkname> für das Laufwerk Ihres Computers, auf dem ASP.NET installiert ist, und <Computername> für den Namen Ihres Computers).

Aktivieren des Identitätswechsels

Mit dem Identitätswechsel führen Sie Anwendungen im Sicherheitskontext der Anforderungseinheit aus, entweder als authentifizierter Benutzer oder als anonymer Benutzer. In ASP.NET ist der Identitätswechsel optional und ist nicht standardmäßig aktiviert. Um Identitätswechsel auf der Ebene des Computers oder der Anwendung zu aktivieren, fügen Sie folgende Konfigurationsanweisung im Bereich <system.web> der Datei "Machine.config" oder "Web.config" hinzu:

Verwendung von Datenbanken

Anwendungen, die die SQL-Authentifizierung verwenden, um die Verbindung zu einer Datenbank herzustellen, sind normalerweise vom Wechsel zum ASPNET-Konto nicht betroffen. Dies gilt auch für Anwendungen, die integrierte Authentifizierung und Identitätswechsel verwenden. Wenn eine Anwendung jedoch keinen Identitätswechsel durchführt und die Windows-Authentifizierung verwendet, müssen Sie dem ASPNET-Konto Zugriff auf die Datenbank gewähren.

Sie können das ASPNET-Konto nicht verwenden, wenn Sie versuchen, sich gegenüber Microsoft SQL Server mithilfe der integrierten Windows-Authentifizierung über Named Pipes zu authentifizieren. Sie können das ASPNET-Konto jedoch erfolgreich mit der integrierten Windows-Authentifizierung über den TCP-Transport (TCP = Transmission Control Protocol) verwenden.

Wenn eine Anwendung eine Microsoft Access-Datenbank verwenden muss, muss das ASPNET-Konto in die Datenbankdatei schreiben können. Administratoren müssen die Dateiberechtigungen dementsprechend anpassen.

Verwenden des Ereignisprotokolls

Anwendungen, die in das Anwendungsereignisprotokoll schreiben müssen, können dies tun, während sie unter dem ASPNET-Konto ausgeführt werden. Wenn eine Anwendung eine neue Ereignisprotokollkategorie erstellen muss, muss die Anwendung einen neuen Registrierungsschlüssel unter der Registrierungsstruktur HKEY_LOCAL_MACHINE erstellen, was das ASPNET-Konto nicht kann.

Um eine Kategorie zur Laufzeit zu erstellen, müssen Sie Identitätswechsel aktivieren, und Sie müssen anschließend ein Konto imitieren, das mehr Zugriffsrechte besitzt. Alternativ kann ein Administrator die Kategorie erstellen, und die Anwendung kann zur Laufzeit in die Kategorie schreiben.

Wenn Anwendungen neue Ereignisprotokollkategorien erstellen müssen, erstellen Sie die Kategorien bei der Installation. Nachdem die Kategorie erstellt ist, kann das ASPNET-Konto in das Ereignisprotokoll der Anwendung schreiben.

Verwenden von "System.DirectoryServices" und Active Directory

Wenn eine Webanwendung auf Active Directory zugreifen muss, kann die Anwendung einen Identitätswechsel in einer Umgebung verwenden, die eine Delegierung unterstützt. Alternativ kann die Anwendung dem DirectoryEntry-Konstruktor im System.DirectoryServices-Namespace explizite Anmeldeinformationen liefern, um auf Active Directory zuzugreifen. Wenn die Anwendung explizite Anmeldeinformationen verwendet, sollten Anwendungen Anmeldeinformationen entsprechend speichern, indem sie eine Methode wie z. B. COM+-Konstruktionszeichenfolgen verwenden oder auch Windows-Datenschutzanwendungs-APIs (Application Programming Interfaces).

Verwenden von Leistungsindikatoren

Das ASPNET-Konto verfügt über ausreichende Berechtigungen, um in Leistungsindikatorendaten zu schreiben (aber nicht, um sie zu lesen). Wenn die Anwendung Leistungsindikatorendaten lesen oder Leistungsindikatorenkategorien erstellen muss, sind Administrator- oder Hauptbenutzerberechtigungen erforderlich.

Wenn eine Anwendung neue Leistungsindikatorenkategorien erstellen muss, erstellen Sie die Kategorien bei der Installation. Nachdem die Kategorien erstellt wurden, kann das ASPNET-Konto in die Indikatoren schreiben.

Sie können das Systemmonitor-Tool ("Perfmon.exe") immer noch verwenden, um ASP.NET-Leistungsindikatoren zu überwachen, wenn Sie das ASPNET-Konto verwenden.

Gehen Sie in Windows 2000 wie folgt vor:

1. Starten Sie den Registrierungseditor.
2. Gehen Sie zu folgendem Registrierungsschlüssel:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ASP.NET_1.1.4322\Names
3. Klicken Sie auf die Registerkarte Sicherheit.
4. Fügen Sie die Identität des Workerprozesses mit folgenden Berechtigungen hinzu:
   • Wert abfragen
   • Wert festlegen
   • Unterschlüssel erstellen
   • Unterschlüssel auflisten
   • Benachrichtigen
   • Lesekontrolle

In Windows Server 2003 fügen Sie die Identität zur Gruppe "IIS_WPG" hinzu.

Starten von Out-of-Process-COM-Servern

Anwendungen, die Out-Of-Process-COM-Server starten müssen, während sie unter dem ASPNET-Konto ausgeführt werden, können dem Konto Startberechtigungen spezifisch mithilfe des Tools "Dcomcnfg.exe" zuweisen.

Debugging-Probleme

Sie können standardmäßig nicht von einer Clientanwendung in einen XML-Webdienstaufruf einsteigen. Um in XML-Webdienste einzusteigen, müssen Sie das ASPNET-Konto zur Gruppe "Debuggerbenutzer" auf dem Computer hinzufügen, auf dem der XML-Webdienst ausgeführt wird.

Ausführen von Code mit einer festen Identität

In COM+-Diensten können Sie Code mit einer festen Identität ausführen. Sie können die Klasse ServicedComponent des System.EnterpriseServices-Namespace verwenden, um verwaltete Codekomponenten zu schreiben, die COM+-Dienste verwenden. Sie können mit Rechten ausgestattete Funktionalität in einer Klasse einschließen, die von ServicedComponent abgeleitet ist, und anschließend diese Klasse als eine COM+-Serveranwendung mit einer konfigurierten Identität ausführen.

Kompilieren von CodeBehind-Dateien auf UNC-Freigaben

Sie können in ASP.NET verschiedene Methoden verwenden, um Anwendungsdateien zu entwickeln:

• Sie können HTML (Hypertext Markup Language) in einer .aspx-Datei verwenden, und Sie können anschließend den Code für die Seite in einer vorkompilierten Assembly im "Bin"-Verzeichnis speichern. Dies ist das Microsoft Visual Studio .NET-Modell.
• Sie können den gesamten Code und den HTML-Inhalt in einer einzigen Quelldatei verpacken, die bei Bedarf kompiliert wird.
• Sie können die HTML-Präsentation in einer ASP.NET-Datei platzieren und anschließend jeden zugeordneten Quellcode für diese Datei dynamisch mithilfe eines src-Attributs in der <%@ Assembly %>-Richtlinie kompilieren.

Hinweis: Wenn sich Anwendungsinhalt auf einer Netzwerkfreigabe befindet, startet der Compiler im ASPNET-Konto und hat keine Netzwerk-Anmeldeinformationen, um auf die Datei zuzugreifen. Wenn Sie Netzwerkfreigaben verwenden, können Sie das src-Attribut nicht verwenden, um auf eine Datei zu zeigen. Sie müssen stattdessen eine der anderen Methoden verwenden.

Verwenden von ASP.NET auf einem primären Domänencontroller oder einem Reservedomänencontroller

Wenn Sie ASP.NET 1.1 auf einem Domänencontroller einsetzen, werden Ihre ASP.NET-Webanwendungen standardmäßig im Sicherheitskontexts des Kontos "IWAM_<Computername>" ausgeführt (dabei steht <Computername> für den Namen Ihres Computers).

Weitere Informationen finden Sie in folgendem Artikel der Microsoft Knowledge Base: Zurück zum Anfang

Lesen der IIS-Metabasis

Das ASPNET-Konto kann die Microsoft Internet Information Services (IIS)-Metabasis nicht lesen. Wenn eine Anwendung auf Metabasiseinstellungen zugreifen muss, können Sie Lesezugriff auf Metabasisknoten selektiv gewähren, indem Sie das Tool "Metaacl.exe" verwenden.

Wenn eine Anwendung .disco-Dateien verwenden muss, die von der Fähigkeit abhängen, die IIS-Metabasis zu lesen, um Suchdienste zu bieten, müssen Sie Lesezugriff auf die Metabasis für das ASPNET-Konto gewähren.

Verwenden von "System.Management" und WMI

Die Windows-Verwaltungsinstrumentation (Windows Management Instrumentation, WMI) ist eine leistungsstarke administrative Funktion, die Sie verwenden können, um Windows-Computer zu verwalten und zu überwachen. Wenn jedoch ASP.NET-Anwendungen unter dem ASPNET-Konto ausgeführt werden, hat dieses Konto nur dieselben standardmäßigen Zugriffsberechtigungen wie Mitglieder der Gruppe "Jeder". Diese Berechtigungen beinhalten das Lesen von WMI-Daten, das Lesen von Anbieterdaten und das Ausführen von Methoden für Anbieter auf dem lokalen Computer. Weitere Informationen über den WMI-Sicherheitsmechanismus finden Sie in der WMI-Plattform-SKD-Dokumentation oder auf der MSDN-Website.

Hinweis: Unter Windows 2000 ohne Service Pack 3 (SP3) oder höher, oder unter Windows XP ohne Service Pack 1 (SP1) oder höher funktionieren ASP.NET-Webanwendungen, die unter dem ASPNET-Konto ausgeführt werden, möglicherweise nicht, und Sie erhalten eventuell eine Fehlermeldung des Typs "Zugriff verweigert (0x80041003)". Dies tritt auf, da das Konto nicht genügend Berechtigungen besitzt, um auf bestimmte WMI-Namespaces zuzugreifen. Installieren Sie Windows XP SP1 oder höher oder Windows 2000 SP3 oder höher, um dieses Problem zu beheben. Gehen Sie folgendermaßen vor, um das Problem zu umgehen:

1. Öffnen Sie das Snap-In "Computerverwaltung" der Microsoft Management Console (MMC).
2. Erweitern Sie den Eintrag Dienste, und wählen Sie WMI-Steuerung.
3. Klicken Sie mit der rechten Maustaste auf WMI-Steuerung, und klicken Sie dann auf Eigenschaften.
4. Klicken Sie im Dialogfeld Eigenschaften von WMI-Steuerung auf die Registerkarte Sicherheit.
5. Erweitern Sie Root, wählen Sie CIMV2, und klicken Sie anschließend auf Sicherheit.
6. Klicken Sie im Dialogfeld Sicherheit auf Erweitert.
7. Klicken Sie im Dialogfeld Zugriffsseinstellungen auf Hinzufügen. Wählen Sie Name des lokalen Computers\ASPNET, und klicken Sie anschließend auf OK.
8. Stellen Sie sicher, dass im Dialogfeld Berechtigungseintrag die Option Übernehmen für auf Dieser und untergeordnete Namespaces eingestellt ist.
9. Vergewissern Sie sich, dass die Kontrollkästchen 'Konto aktivieren' zulassen and 'Remoteaktivierung' zulassen aktiviert sind.
10. Klicken Sie in jedem Dialogfeld auf OK, bis Sie zum Dialogfeld Eigenschaften von WMI-Steuerung zurückgekehrt sind.
11. Wiederholen Sie die Schritte 5 bis 10 für weitere WMI-Namespaces, auf die Ihre Anwendung zugreifen wird.
12. Starten Sie IIS neu. Führen Sie dazu IISRESET von der Eingabeaufforderung aus.

ASP.NET erzeugt standardmäßig verschlüsselte, strenge Kennwörter für das ASPNET-Konto. Es ist daher sicher, das Problem auf diese Art und Weise zu umgehen, vorausgesetzt, das ASPNET-Kontokennwort ist nicht zwischen Computern freigegeben und wird nicht auf einen anderen Wert als den Standardwert zurückgesetzt.

Interaktion mit dem Desktop

Wenn IIS-Dienste so konfiguriert sind, dass sie eine Interaktion mit dem Desktop zulassen, hat das ASPNET-Konto aufgrund der freigegebenen Zugriffssteuerungsliste (Discretionary Access Control List, DACL) auf der standardmäßigen Arbeitsstation und dem standardmäßigen Desktop nicht die erforderlichen Rechte, um auf den Desktop zuzugreifen. Administratoren können diese DACLs ändern oder den Prozess mit einem Konto ausführen, das über die Berechtigung verfügt, auf diese Objekte zuzugreifen.

Entfernen von ASP.NET

Wenn Sie ASP.NET entfernen, wird das ASPNET-Konto deaktiviert und bleibt im System. Sie können das ASPNET-Konto löschen, wenn Sie nicht vorhaben, ASP.NET neu zu installieren.

Wenn Sie ASP.NET neu installieren, nachdem Sie das ASPNET-Konto explizit gelöscht haben, wird ein neues ASPNET-Konto erstellt, das über neue Sicherheitsbezeichner (Security Identifier, SID) verfügt. Demzufolge sind alle Zugriffssteuerungslisten, die sich auf das frühere ASPNET-Konto bezogen, für das neue ASPNET-Konto nicht mehr gültig.

Weitere Informationen über die standardmäßigen Zugriffssteuerungslisten in Windows 2000 finden Sie im folgenden Microsoft-Whitepaper: Weitere Informationen finden Sie in den folgenden Artikeln der Microsoft Knowledge Base: