Grundlegendes zu Identitäten in IIS

Dieser Artikel enthält Hintergrundinformationen zu Identitäten in Internetinformationsdiensten (Internet Information Services, IIS).

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

Anwendungspoolidentitäten

Um anwendungspoolidentitäten zu verstehen, müssen Sie verstehen, was eine Identität ist. Einfach ausgedrückt ist eine Identität ein Windows-Konto. Jeder Prozess, der unter 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:

• 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 netzwerkdienstähnend ist und standardmäßige Dienste mit den geringsten Rechten ausführen soll. 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 ein benutzerdefiniertes Ereignisprotokoll (MyWebAppZone) und eine Ereignisprotokollquelle (MyWebAppZone.com) zur Laufzeit erstellt. Anwendungen, die mithilfe 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.

  

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

  

  Wenn Sie die ProcMon-Ablaufverfolgung gleichzeitig ausführen, finden Sie häufig, dass NT AUTHORITY\NETWORK SERVICE nicht über die erforderlichen Lese- und Schreibzugriffsberechtigungen 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.

  

• 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

  

  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 in den Szenarien 1 und 2 bereits 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 Lastenausgleichsumgebung 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 Lastenausgleichsumgebung gehostet wird, die zwei Server umfasst und die Kerberos-Authentifizierung verwendet, um den Client zu identifizieren.

  

  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 beispielsweise "Server1" lautet, wird er als "Server1$" dargestellt. Dieses Computerkonto wird automatisch erstellt, wenn ein Computer einer Domäne beitritt. Wenn N-Server vorhanden sind, müssen Sie daher die 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 überwinden, können Sie die Anwendung unter einer benutzerdefinierten Windows-Identität (Domäne) 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 das Konfigurieren einer Anwendungspoolidentität und das Vornehmen aller erforderlichen Änderungen. Wenn IIS einen Arbeitsprozess startet, muss ein Token erstellt werden, das vom Prozess verwendet wird. Wenn dieses Token erstellt wird, fügt IIS die IIS_IUSRS Mitgliedschaft automatisch zur Laufzeit dem Workerprozesstoken hinzu. Die Konten, die als Anwendungspoolidentitäten ausgeführt werden, müssen nicht mehr explizit teil der IIS_IUSRS Gruppe sein. Wenn Sie eine Website erstellen und dann auf den physischen Standort C:\inetpub\wwwrootverweisen, werden die folgenden Benutzer und Gruppen automatisch 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 von Lesevorgängen &
Vertrauenswürdiger Installer	Vollzugriff

Wenn Sie dieses Feature deaktivieren und der IIS_IUSRS Gruppe manuell Konten hinzufügen möchten, legen Sie in der datei "ApplicationHost.config" den Wert "manualGroupMembership" auf "true" fest. Das folgende Beispiel zeigt, wie dies mit dem Standardanwendungspool erfolgen kann:

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

Grundlegendes zur Konfigurationsisolation

IIS-Arbeitsprozesse haben keinen Lesezugriff auf die ApplicationHost.config Datei. Daher fragen Sie sich vielleicht, wie sie beliebige Konfigurationssätze in dieser Datei lesen können.

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

Hinweis

Weitere Informationen zur SID finden Sie unter Sicherheits-IDs.

Dadurch wird verhindert, dass IIS-Arbeitsprozesse aus Anwendungspool A Konfigurationsinformationen in der ApplicationHost.config Datei lesen können, die für Anwendungspool B vorgesehen ist.

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 das Zulassen des Zugriffs aller Anwendungspools auf ApplicationHost.config die Anwendungspoolisolation unterbrechen. Wenn jedem Anwendungspool direkter Zugriff auf die ApplicationHost.config Datei gewährt wurde, könnten diese Pools vertrauliche Informationen problemlos aus anderen Anwendungspools heraus hacken, indem sie den folgenden Befehl ausführen:

appcmd list APPPOOL "DefaultAppPool" /text:*

IUSR - anonyme Authentifizierung

Die anonyme Authentifizierung ermöglicht Benutzern den Zugriff auf öffentliche Bereiche der Website, ohne zur Eingabe eines Benutzernamens oder Kennworts aufgefordert zu werden. In IIS 7.0 und höheren Versionen wird ein integriertes Konto verwendet, IUSRum anonymen Zugriff zu ermöglichen. 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>

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

• Sie müssen sich nicht mehr darum kümmern, dass Kennwörter für dieses Konto ablaufen.
• Sie können xcopy/o verwenden, um Dateien zusammen mit ihrem Besitz und den ACL-Informationen nahtlos auf verschiedene Computer zu kopieren.

Sie können Ihrer Website auch anonyme Authentifizierung bereitstellen, indem Sie ein bestimmtes Windows-Konto oder eine Anwendungspoolidentität anstelle eines Kontos IUSR verwenden.

IUSR versus Connect als

Stellen Sie eine Verbindung her, wie es eine Option in IIS ist, 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, betrachten 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 den Abschnitt "Verbinden" als Abschnitt, um über einen Test Domänenbenutzer auf diese Ressource zuzugreifen. Wenn sich der Benutzer anmeldet, wird er mithilfe eines IUSR-Kontos authentifiziert. Der Zugriff auf den Websiteinhalt erfolgt jedoch über die Benutzeranmeldeinformationen, die im Abschnitt "Verbinden " erwähnt werden.

Um es einfacher auszudrucken, 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 der Inhalt auf einer Netzwerkfreigabe befindet. In solchen Fällen können Sie keine integrierten Konten verwenden, um auf die Netzwerkfreigabe zuzugreifen. Stattdessen müssen Sie dazu ein bestimmtes Konto (Domäne) verwenden.

ASP.NET Identitätswechsel

Identitätswechsel bedeutet im wahrsten Sinne des Wortes, dass man vorgibt, eine andere Person zu sein. Technisch gesehen 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 Kontos IUSR . 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 anonyme Authentifizierung verwendet und eine der folgenden Bedingungen zutrifft:

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

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

Wenn Sie die Identität eines bestimmten Benutzers für alle Anforderungen auf allen Seiten einer ASP.NET Anwendung annehmen möchten, 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 durch 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 vorgibt, 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 IUSR des Kontos bereitgestellt. Sie können die Identitätswechselidentität ganz einfach mitHilfe von ProcMon nachverfolgen. Wenn Sie beispielsweise eines der CreateFile-Ereignisse untersuchen, das dem w3wp.exe Prozess entspricht, den Sie untersuchen, finden Sie das Identitätswechselkonto, wie im folgenden Screenshot dargestellt.