Grundlegendes zu Identitäten in IIS

Dieser Artikel enthält Hintergrundinformationen zu Identitäten in Internetinformationsdienste (IIS).

Ursprüngliche Produktversion:   Internetinformationsdienste
Ursprüngliche KB-Nummer:   4466942

Anwendungspoolidentitäten

Um Anwendungspoolidentitäten zu verstehen, müssen Sie wissen, was eine Identität ist. Einfach ausgedrückt ist eine Identität ein Windows Konto. Jeder Prozess, der in Windows ausgeführt wird, wird unter einer Identität ausgeführt. Die Anwendungen werden vom Arbeitsprozess mithilfe einer Windows Identität ausgeführt. Die verwendete Windows Identität hängt von der Anwendungspoolidentität ab, bei der es sich um eines der folgenden Konten handeln kann:

Windows Identitätskonten.

  • Lokales System: Vertrauenswürdiges Konto mit hohen Berechtigungen und zugriff auf Netzwerkressourcen.
  • Netzwerkdienst: Eingeschränktes oder eingeschränktes Dienstkonto, das zum Ausführen standardmäßiger Dienste mit den geringsten Rechten verwendet wird. Dieses Konto verfügt über weniger Berechtigungen als ein lokales Systemkonto. Dieses Konto hat Zugriff auf Netzwerkressourcen.
  • Lokaler Dienst: Eingeschränktes oder eingeschränktes Dienstkonto, das dem Netzwerkdienst ähnelt und für die Ausführung standardmäßiger Dienste mit den geringsten Rechten vorgesehen ist. Dieses Konto hat keinen Zugriff auf Netzwerkressourcen.
  • ApplicationPoolIdentity: Wenn ein neuer Anwendungspool erstellt wird, erstellt IIS ein virtuelles Konto mit dem Namen des neuen Anwendungspools, das den Arbeitsprozess des Anwendungspools unter diesem Konto ausführt. Dies ist auch ein Konto mit den geringsten Rechten.
  • Benutzerdefiniertes Konto: Zusätzlich zu diesen integrierten Konten können Sie auch ein benutzerdefiniertes Konto verwenden, indem Sie den Benutzernamen und das Kennwort angeben.

Unterschiede zwischen Anwendungspoolidentitäten

  • Szenario 1: Ereignisprotokollzugriff

    In diesem Szenario verfügen Sie über eine Webanwendung, die zur Laufzeit ein benutzerdefiniertes Ereignisprotokoll (MyWebAppZone) und eine Ereignisprotokollquelle (MyWebAppZone.com) erstellt. Anwendungen, die mit einer der Identitäten ausgeführt werden, können mithilfe vorhandener Ereignisquellen in das Ereignisprotokoll schreiben. Wenn sie jedoch unter einer anderen Identität als dem lokalen System ausgeführt werden, können sie aufgrund unzureichender Registrierungsberechtigungen keine neuen Ereignisquellen erstellen.

    Meine Web App-Zone.

    Wenn Sie die Anwendung beispielsweise unter "Netzwerkdienst" ausführen, erhalten Sie die folgende Sicherheitsausnahme:

    Screenshot des Serverfehlers.

    Wenn Sie die ProcMon-Ablaufverfolgung gleichzeitig ausführen, stellen Sie häufig fest, dass NT AUTHORITY\NETWORK SERVICE nicht über die erforderlichen Lese- und Schreibzugriffsrechte für den folgenden Registrierungsunterschlüssel verfügt:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\

    Dies ist der Speicherort in der Registrierung, an dem alle Einstellungen eines Ereignisprotokolls gespeichert werden.

    Screenshot von Process Monitor 1.

  • Szenario 2: Registrierungszugriff

    Abgesehen vom lokalen System haben keine anderen Anwendungspoolidentitäten Schreibzugriff auf die Registrierung. In diesem Szenario haben Sie eine einfache Webanwendung entwickelt, die den Namen des Internetzeitservers ändern und anzeigen kann, mit dem Windows automatisch synchronisiert wird. Wenn Sie diese Anwendung unter "Lokaler Dienst" ausführen, wird eine Ausnahme angezeigt. Wenn Sie die ProcMon-Ablaufverfolgung überprüfen, stellen Sie fest, dass die Anwendungspoolidentität "NT AUTHORITY\LOCAL SERVICE" im folgenden Registrierungsunterschlüssel keinen Lese- und Schreibzugriff hat:

    HKEY_LOCAL_MACHINE** **\SOFTWARE\Microsoft\Windows\CurrentVersion\DateTime\Servers

    Screenshot von Process Monitor 2.

    Wenn Sie das MyWebAppZone-Ereignisprotokoll (aus Szenario 1) überprüfen, wird das folgende Fehlerereignis protokolliert. Es enthält eine Requested registry access is not allowed Fehlermeldung.

    Exception Type: SecurityException  
    Message: Requested registry access is not allowed.  
    Stack Trace  
    at Microsoft.Win32.RegistryKey.OpenSubKey(String name, Boolean writable)  
    at Identities.ChangeTimeServer.Page_Load(Object sender, EventArgs e)  
    at System.Web.UI.Control.LoadRecursive()  
    at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)  
    at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)  
    at System.Web.UI.Page.ProcessRequest()  
    at System.Web.UI.Page.ProcessRequest(HttpContext context)  
    at ASP.changetimeserver_aspx.ProcessRequest(HttpContext context) in c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\fd06117a\f8c94323\App_Web_ysqbhk00.2.cs:line 0  
    at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()  
    at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
    
  • Szenario 3: Benutzerdefiniertes Konto in kerberos-Authentifizierung und Lastenausgleichsumgebung

    Sie haben bereits in Szenarien 1 und 2 einige der Unterschiede zwischen den integrierten Konten gesehen. Lassen Sie uns nun besprechen, was ein benutzerdefiniertes Konto ist und wie es Vorteile gegenüber integrierten Konten hat, wenn Sie mit der Kerberos-Authentifizierung in einer Umgebung mit Lastenausgleich arbeiten.

    Mit diesem Ansatz führen Sie Ihre Anwendung in einem Anwendungspool aus, der für die Ausführung mithilfe einer bestimmten Windows-Identität konfiguriert ist. Betrachten Sie das folgende Diagramm, in dem eine Anwendung in einer Umgebung mit Lastenausgleich gehostet wird, die zwei Server enthält und die Kerberos-Authentifizierung verwendet, um den Client zu identifizieren.

    Screenshot der Kerberos-Authentifizierung in einer Umgebung mit Lastenausgleich.

    Damit die Kerberos-Authentifizierung funktioniert, müssen Sie SPN für beide Server mithilfe ihres Computerkontos einrichten. Wenn der Anwendungspool unter einem integrierten Konto ausgeführt wird, werden die Computeranmeldeinformationen im Netzwerk angezeigt. Wenn der Computername z. B. Server1 ist, wird er selbst als "Server1$" angezeigt. Dieses Computerkonto wird automatisch erstellt, wenn ein Computer einer Domäne beitritt. Wenn N-Server vorhanden sind, müssen Sie daher N-Anzahl von SPNs festlegen, die ihrem jeweiligen Computerkonto entsprechen.

    Registrieren eines SPN bei einem Computerkonto:

    setspn -a HTTP/HOSTNAME MachineAccount$
    

    Beispiel:

    setspn -a HTTP/MyWebAppZone.com Server1$
    

    Um diesen Nachteil zu umgehen, können Sie die Anwendung unter einer benutzerdefinierten Windows (Domänen-)Identität ausführen und dann den SPN auf nur dieses bestimmte Domänenkonto im Domänencontroller festlegen.

    Registrieren eines SPN bei einem Domänenkonto:

    setspn -a HTTP/HOSTNAME domain\account
    

    Beispiel:

    setspn -a HTTP/MyWebAppZone.com contoso.com\account_alias
    

Standardberechtigungen und Benutzerrechte in wwwroot

IiS 7.0 und höhere Versionen erleichtern außerdem die Konfiguration einer Anwendungspoolidentität und nehmen alle erforderlichen Änderungen vor. Wenn IIS einen Arbeitsprozess startet, muss er ein Token erstellen, das vom Prozess verwendet wird. Wenn dieses Token erstellt wird, fügt IIS die Mitgliedschaft automatisch IIS_IUSRS zur Laufzeit dem Workerprozesstoken hinzu. Die Konten, die als Anwendungspoolidentitäten ausgeführt werden, müssen kein expliziter Teil der Gruppe mehr IIS_IUSRS sein. Wenn Sie eine Website erstellen und dann auf den physischen Standort C:\inetpub\wwwroot verweisen, werden die folgenden Benutzer und Gruppen automatisch zu den Zugriffssteuerungslisten der Website hinzugefügt.

Benutzer/Gruppen Zulässige Berechtigungen
ERSTELLER-BESITZER Spezielle Berechtigungen
SYSTEM Vollzugriff
Administratoren Vollzugriff
Benutzer Read & execute, List folder contents, Read
IIS_USRS & ausführen lesen
TrustedInstaller Vollzugriff

Wenn Sie dieses Feature deaktivieren und der Gruppe manuell Konten hinzufügen IIS_IUSRS möchten, legen Sie den Wert "manualGroupMembership" in der dateiApplicationHost.config auf "true" fest. Das folgende Beispiel zeigt, wie dies für den Standardanwendungspool möglich ist:

<applicationPools> 
    <add name="DefaultAppPool"> 
        <processModel manualGroupMembership="true" />
    </add>
</applicationPools>

Grundlegendes zur Konfigurationsisolation

IIS-Arbeitsprozesse haben keinen Lesezugriff auf die ApplicationHost.config Datei. Sie fragen sich also vielleicht, wie sie konfigurationsgruppen in dieser Datei lesen können.

Die Antwort ist die Verwendung des Konfigurationsisolationsfeatures in IIS 7.0 und höher. Anstatt den IIS-Arbeitsprozessen zu ermöglichen, ApplicationHost.config direkt zu lesen, wenn sie die Konfigurationsdateihierarchie lesen, generiert der Windows Prozessaktivierungsdienst (PROCESS Activation Service, WAS) gefilterte Kopien dieser Datei. Jeder IIS-Arbeitsprozess verwendet diese Kopien als Ersatz fürApplicationHost.config, wenn die Konfiguration innerhalb des IIS-Arbeitsprozesses gelesen wird. Diese Dateien werden standardmäßig im Verzeichnis generiert %SystemDrive%\inetpub\Temp\appPools und heißen {AppPoolName}.config. Diese Dateien sind so konfiguriert, dass nur der Zugriff auf die IIS-Arbeitsprozesse im entsprechenden Anwendungspool mithilfe der IIS APPPOOL\AppPoolName Sicherheits-ID (SID) des Anwendungspools ermöglicht wird.

Hinweis

Weitere Informationen zur SID finden Sie im Thema "Sicherheitsbezeichner" auf der Microsoft Docs-Website.

Screenshot der Verwendung des Anwendungspools für die Konfigurationsisolation.

Dadurch wird verhindert, dass IIS-Arbeitsprozesse aus Anwendungspool A Konfigurationsinformationen in der für Anwendungspool B vorgesehenen ApplicationHost.configdatei lesen können.

ApplicationHost.config können vertrauliche persönliche Informationen enthalten, z. B. den Benutzernamen und das Kennwort für benutzerdefinierte Anwendungspoolidentitäten oder den Benutzernamen und das Kennwort für virtuelle Verzeichnisse. Daher würde die Anwendungspoolisolation aufgehoben, wenn alle Anwendungspools auf ApplicationHost.config zugreifen können. Wenn jedem Anwendungspool direkter Zugriff auf die ApplicationHost.config-Datei gewährt wurde, könnten diese Pools vertrauliche Informationen ganz einfach aus anderen Anwendungspools hacken, indem sie den folgenden Befehl ausführen:

appcmd list APPPOOL "DefaultAppPool" /text:*

Screenshot der Verwendung des Befehls &quot;appcmd&quot;.

IUSR – anonyme Authentifizierung

Mit der anonymen Authentifizierung können Benutzer auf öffentliche Bereiche der Website zugreifen, ohne zur Eingabe eines Benutzernamens oder Kennworts aufgefordert zu werden. In IIS 7.0 und höher wird ein integriertes Konto IUSR für anonymen Zugriff verwendet. Für dieses integrierte Konto ist kein Kennwort erforderlich. Es ist die Standardidentität, die verwendet wird, wenn die anonyme Authentifizierung aktiviert ist. In der ApplicationHost.config-Datei sehen Sie die folgende Definition:

<authentication>
     <anonymousAuthentication enabled="true" userName="IUSR" />
 </authentication>

Dadurch wird IIS angewiesen, das neue integrierte Konto für alle anonymen Authentifizierungsanforderungen zu verwenden. Die größten Vorteile hierfür sind die folgenden:

  • Sie müssen sich keine Gedanken mehr darüber machen, dass Kennwörter für dieses Konto ablaufen.
  • Sie können xcopy /o verwenden, um Dateien zusammen mit ihren Besitzer- und ACL-Informationen nahtlos auf verschiedene Computer zu kopieren.

Sie können ihre Website auch anonym authentifizieren, indem Sie ein bestimmtes Windows Konto oder eine Anwendungspoolidentität anstelle eines IUSR Kontos verwenden.

IUSR im Vergleich zu Verbinden as

Verbinden eine Option in IIS, mit der Sie entscheiden können, welche Anmeldeinformationen Sie für den Zugriff auf die Website verwenden möchten. Sie können entweder die authentifizierten Benutzeranmeldeinformationen oder bestimmte Benutzeranmeldeinformationen verwenden. Um den Unterschied zu verstehen, berücksichtigen Sie das folgende Szenario:

Sie verfügen über eine Standardwebsite, die für die Verwendung der anonymen Authentifizierung konfiguriert ist. Ihre Websiteinhalte befinden sich jedoch auf einem anderen Server, und Sie verwenden die Verbinden als Abschnitt, um über einen Domänenbenutzer auf diese Ressource Test zuzugreifen. Wenn sich der Benutzer anmeldet, wird er mithilfe eines IUSR-Kontos authentifiziert. Der Zugriff auf den Websiteinhalt erfolgt jedoch über die Benutzeranmeldeinformationen, die in Verbinden als Abschnitt erwähnt werden.

Vereinfacht gesagt ist die anonyme Authentifizierung der Mechanismus, der von der Website verwendet wird, um einen Benutzer zu identifizieren. Wenn Sie dieses Feature verwenden, muss der Benutzer jedoch keine Anmeldeinformationen angeben. Es kann jedoch ein ähnliches Szenario geben, in dem sich die Inhalte in einer Netzwerkfreigabe befinden. In solchen Fällen können Sie keine integrierten Konten verwenden, um auf die Netzwerkfreigabe zuzugreifen. Stattdessen müssen Sie hierfür ein bestimmtes Konto (Domäne) verwenden.

ASP.NET Identitätswechsel

Im wahrsten Sinne des Wortes bedeutet Identitätswechsel den Vorgang, sich als eine andere Person auszugeben. Technisch ist es ein ASP.NET Sicherheitsfeature, das die Möglichkeit bietet, die Identität zu steuern, unter der Anwendungscode ausgeführt wird. Der Identitätswechsel tritt auf, wenn ASP.NET Code im Kontext eines authentifizierten und autorisierten Clients ausführt. IIS bietet anonymen Zugriff auf Ressourcen mithilfe eines IUSR Kontos. Nachdem die Anforderung an ASP.NET übergeben wurde, wird der Anwendungscode mithilfe der Anwendungspoolidentität ausgeführt.

Der Identitätswechsel kann sowohl über IIS als auch ASP.NET Code aktiviert werden, wenn die Anwendung die anonyme Authentifizierung verwendet und eine der folgenden Bedingungen zutrifft:

  • Wenn IMPERSONATION diese Option deaktiviert ist, wird die Anwendungspoolidentität verwendet, um den Anwendungscode auszuführen.
  • Wenn IMPERSONATION diese Option aktiviert ist, wird der NT AUTHORITY\IUSR Anwendungscode ausgeführt.

Wenn impersonation sie über IIS aktiviert ist, wird das folgende Tag in der Web.config-Datei der Anwendung hinzugefügt, um die Identität des IIS-authentifizierten Kontos oder Benutzers zu imitieren: <identity impersonate="true" />

Um die Identität eines bestimmten Benutzers für alle Anforderungen auf allen Seiten einer ASP.NET Anwendung zu imitieren, können Sie die Benutzernamen- und Kennwortattribute im <identity> Tag der Web.config-Datei für diese Anwendung angeben.

<identity impersonate="true" userName="accountname" password="password" />

Informationen zum Implementieren des Identitätswechsels über ASP.NET Code finden Sie unter Implementieren des Identitätswechsels in einer ASP.NET Anwendung.

Öffnen Sie den IIS-Arbeitsprozess einer Testwebsite, die die Identität eines Test lokalen Benutzers annimmt, und überprüfen Sie, ob Sie das Identitätswechselkonto finden können, unter dem der Anwendungscode ausgeführt wird.

Die Anwendungspoolidentität der Anwendung wird auf ApplicationPoolIdentity festgelegt, und die anonyme Authentifizierung wird mithilfe eines IUSR Kontos bereitgestellt. Sie können die Identitätsidentität mit ProcMon ganz einfach nachverfolgen. Wenn Sie z. B. eines der CreateFile-Ereignisse untersuchen, die dem w3wp.exe Prozess entsprechen, den Sie untersuchen, finden Sie das Identitätswechselkonto, wie im folgenden Screenshot dargestellt.

Details zum Identitätswechsel in Ereigniseigenschaften.