Freigeben über

Identitätswechselebenen

  • Artikel

Wenn der Identitätswechsel erfolgreich ist, bedeutet dies, dass der Client zugestimmt hat, den Server bis zu einem gewissen Grad als Client zu verwenden. Die unterschiedlichen Grade des Identitätswechsels werden als Identitätswechselebenen bezeichnet und geben an, wie viel Autorität dem Server erteilt wird, wenn er die Identität des Clients imitiert.

Derzeit gibt es vier Identitätswechselebenen: anonym, identifizieren, Identitätswechsel und Delegat. In der folgenden Liste werden die einzelnen Identitätswechselebenen kurz beschrieben:

anonym (RPC_C_IMP_LEVEL_ANONYMOUS)

Der Client ist gegenüber dem Server anonym. Der Serverprozess kann den Client imitieren, das Identitätswechseltoken enthält jedoch keine Informationen über den Client. Diese Ebene wird nur über den lokalen Interprozesskommunikationstransport unterstützt. Alle anderen Transporte fördern diese Ebene im Hintergrund, um sie zu identifizieren.

identifizieren (RPC_C_IMP_LEVEL_IDENTIFY)

Die Standardebene des Systems. Der Server kann die Identität des Clients abrufen und den Client imitieren, um ACL-Überprüfungen auszuführen.

Identitätswechsel (RPC_C_IMP_LEVEL_IMPERSONATE)

Der Server kann als der Client auftreten und dabei dessen Sicherheitskontext imitieren. Der Server kann als Client auf lokale Ressourcen zugreifen. Wenn der Server lokal ist, kann er als Client auf Netzwerkressourcen zugreifen. Wenn der Server remote ist, kann er nur auf Ressourcen zugreifen, die sich auf demselben Computer wie der Server befinden.

delegate (RPC_C_IMP_LEVEL_DELEGATE)

Die umfassendste Ebene des Identitätswechsels. Wenn diese Ebene ausgewählt wird, kann der Server (sowohl lokal als auch remote) als Client auftreten und dabei dessen Sicherheitskontext imitieren. Während des Identitätswechsels können die Anmeldeinformationen des Clients (sowohl lokal als auch im Netzwerk) an eine beliebige Anzahl von Computern übergeben werden.

Damit der Identitätswechsel auf Der Delegatebene funktioniert, müssen die folgenden Anforderungen erfüllt sein:

  • Der Client muss die Identitätswechselebene auf RPC_C_IMP_LEVEL_DELEGATE festlegen.
  • Das Clientkonto darf im Active Directory-Dienst nicht als "Konto ist vertraulich und nicht delegiert" gekennzeichnet sein.
  • Das Serverkonto muss im Active Directory-Dienst mit dem Attribut "Vertrauenswürdig für Delegierung" gekennzeichnet sein.
  • Die Computer, die den Client, den Server und alle nachgeschalteten Server hosten, müssen alle in einer Domäne ausgeführt werden.

Durch Auswählen der Identitätswechselebene teilt der Client dem Server mit, wie weit er beim Identitätswechsel des Clients gehen kann. Der Client legt die Identitätswechselebene für den Proxy fest, der für die Kommunikation mit dem Server verwendet wird.

Festlegen der Identitätswechselebene

Es gibt zwei Möglichkeiten, die Identitätswechselebene festzulegen:

Sie legen die Identitätswechselebene fest, indem Sie über den dwImpLevel-Parameter einen entsprechenden RPC_C_IMP_LEVEL_xxx-Wert an CoInitializeSecurity oder CoSetProxyBlanket übergeben.

Verschiedene Authentifizierungsdienste unterstützen den Identitätswechsel auf Delegatenebene in unterschiedlichem Umfang. Für instance unterstützt NTLMSSP den threadübergreifenden und prozessübergreifenden Identitätswechsel auf Delegatebene, aber nicht computerübergreifend. Andererseits unterstützt das Kerberos-Protokoll den Identitätswechsel auf Delegatebene über Computergrenzen hinweg, während Schannel keinen Identitätswechsel auf Delegatenebene unterstützt. Wenn Sie über einen Proxy auf Identitätswechselebene verfügen und die Identitätswechselebene auf Delegieren festlegen möchten, sollten Sie SetBlanket mit den Standardkonstanten für jeden Parameter mit Ausnahme der Identitätswechselebene aufrufen. COM wählt NTLM lokal und das Kerberos-Protokoll remote (wenn das Kerberos-Protokoll funktioniert).

Delegierung und Identitätswechsel