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 verstehen, 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 unter Verwendung einer Windows-Identität ausgeführt. Die verwendete Windows-Identität ist von der Anwendungspoolidentität abhängig, bei der es sich um eines der folgenden Konten handeln kann:

• Lokales System: Vertrauenswürdiges Konto, das über hohe Berechtigungen verfügt und auch Zugriff auf Netzwerkressourcen hat.
• Netzwerkdienst: Eingeschränktes oder eingeschränktes Dienstkonto, das zum Ausführen von Standarddiensten mit den geringsten Berechtigungen 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 von Standarddiensten 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.

  

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

  

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

  

• 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, erhalten Sie eine Ausnahme. Wenn Sie die ProcMon-Ablaufverfolgung überprüfen, stellen Sie fest, dass die Anwendungspoolidentität "NT AUTHORITY\LOCAL SERVICE" im folgenden Registrierungsunterschlüssel nicht über Lese- und Schreibzugriff verfügt:

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

  

  Wenn Sie das MyWebAppZone-Ereignisprotokoll (aus Szenario 1) überprüfen, wird das folgende Fehlerereignis protokolliert. Sie 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 der Kerberos-Authentifizierung und umgebung mit Lastenausgleich

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

  Bei diesem Ansatz führen Sie Ihre Anwendung in einem Anwendungspool aus, der für die Ausführung mit 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.

  

  Damit die Kerberos-Authentifizierung funktioniert, müssen Sie den 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 lautet, wird er als "Server1$" angezeigt. Dieses Computerkonto wird automatisch erstellt, wenn ein Computer einer Domäne beitritt. Wenn also N Server vorhanden sind, müssen Sie 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 beseitigen, können Sie die Anwendung unter einer benutzerdefinierten Windows-Identität (Domäne) ausführen und dann den SPN nur auf 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 Workerprozess startet, muss ein Token erstellt werden, das vom Prozess verwendet wird. Wenn dieses Token erstellt wird, fügt IIS automatisch die IIS_IUSRS Mitgliedschaft zum Workerprozesstoken zur Laufzeit 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 den physischen Standort auf C:\inetpub\wwwrootverweisen, werden die folgenden Benutzer und Gruppen automatisch den Zugriffssteuerungslisten der Website hinzugefügt.

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

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

Grundlegendes zur Konfigurationsisolation

IIS-Workerprozesse haben keinen Lesezugriff auf die ApplicationHost.config-Datei . Sie fragen sich also vielleicht, wie sie die 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-Workerprozessen 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 von 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-Workerprozesse im entsprechenden Anwendungspool mithilfe der Sicherheits-ID (SID) des IIS APPPOOL\AppPoolName Anwendungspools zugelassen wird.

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

ApplicationHost.config können vertrauliche personenbezogene Informationen enthalten, z. B. den Benutzernamen und das Kennwort für benutzerdefinierte Anwendungspoolidentitäten oder den Benutzernamen und das Kennwort für virtuelle Verzeichnisse. Aus diesem Grund würde die Isolation des Anwendungspools unterbrochen, wenn alle Anwendungspools auf ApplicationHost.config zugreifen können. Wenn jedem Anwendungspool direkten 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 bereitzustellen. Für dieses integrierte Konto ist kein Kennwort erforderlich. Dies 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 aufgefordert, das neue integrierte Konto für alle anonymen Authentifizierungsanforderungen zu verwenden. Dies hat die größten Vorteile:

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

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

IUSR im Vergleich zu Connect as

Verbinden als ist 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 Anmeldeinformationen des authentifizierten Benutzers 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 , 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 als erwähnt sind.

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 auf einer Netzwerkfreigabe befinden. In solchen Fällen können Sie keine integrierten Konten für den Zugriff auf die Netzwerkfreigabe verwenden. Stattdessen müssen Sie dafür ein bestimmtes Konto (Domäne) verwenden.

ASP.NET Identitätswechsel

Im wahrsten Sinne des Wortes bedeutet Identitätswechsel die Handlung, vorzugeben, eine andere Person zu sein. Technisch gesehen handelt es sich um 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 über ASP.NET Code aktiviert werden, wenn die Anwendung anonyme Authentifizierung verwendet und eine der folgenden Bedingungen zutrifft:

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

Wenn impersonation ü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 Des Benutzers: <identity impersonate="true" / anzugeben.>

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 ü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 angibt, und überprüfen Sie, ob Sie das Identitätswechselkonto finden können, unter dem der Anwendungscode ausgeführt wird.

Die Anwendungspoolidentität der Anwendung ist auf ApplicationPoolIdentity festgelegt, und die anonyme Authentifizierung wird mithilfe IUSR des Kontos bereitgestellt. Sie können den Identitätswechsel mithilfe von ProcMon problemlos nachverfolgen. Wenn Sie beispielsweise eines der CreateFile-Ereignisse untersuchen, das dem w3wp.exe Prozess entspricht, den Sie untersuchen, können Sie das Identitätswechselkonto finden, wie im folgenden Screenshot gezeigt.