Identitätswechselebenen
Wenn der Identitätswechsel erfolgreich ist, bedeutet dies, dass der Client zugestimmt hat, den Server zu einem gewissen Grad als Client zuzulassen. Die unterschiedlichen Identitätswechselgrade werden als Identitätswechselebenen bezeichnet und geben an, wie viel Autorität dem Server erteilt wird, wenn er die Identität des Clients angibt.
Derzeit gibt es vier Identitätswechselebenen: anonym, Identifizieren, Annehmen der Identität und Delegieren von . In der folgenden Liste werden die einzelnen Identitätswechselebenen kurz beschrieben:
-
anonymous (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 prozessübergreifenden Kommunikationstransport unterstützt. Alle anderen Transporte stufen diese Ebene automatisch zur Identifizierung herauf.
-
identify (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.
-
impersonate (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.
-
delegat (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 netzwerkseitig) an eine beliebige Anzahl von Computern übergeben werden.
Damit der Identitätswechsel auf 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 kann nicht delegiert werden" gekennzeichnet werden.
- Das Serverkonto muss im Active Directory-Dienst mit dem Attribut "Vertrauenswürdig für delegierung" gekennzeichnet werden.
- Die Computer, auf denen der Client, der Server und alle "Downstreamserver" gehostet werden, müssen alle in einer Domäne ausgeführt werden.
Durch Auswahl 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 auf dem Proxy fest, den er für die Kommunikation mit dem Server verwendet.
Festlegen der Identitätswechselebene
Es gibt zwei Möglichkeiten, die Identitätswechselebene festzulegen:
- Der Client kann ihn über einen Aufruf von CoInitializeSecurityprozessweit festlegen.
- Ein Client kann die Sicherheit auf Proxyebene für eine Schnittstelle eines Remoteobjekts über einen Aufruf von IClientSecurity::SetBlanket (oder der Hilfsfunktion CoSetProxyBlanket)festlegen.
Sie legen die Identitätswechselebene fest, indem Sie einen entsprechenden RPC _ C _ IMP _ LEVEL _ xxx-Wert über den dwImpLevel-Parameter an CoInitializeSecurity oder CoSetProxyBlanket übergeben.
Verschiedene Authentifizierungsdienste unterstützen den Identitätswechsel auf Delegatebene in unterschiedlichen Ausmaßen. NTLMSSP unterstützt beispielsweise thread- und prozessübergreifenden Identitätswechsel auf Delegatebene, jedoch nicht computerübergreifend. Andererseits unterstützt das Kerberos-Protokoll Identitätswechsel auf Delegatebene über Computergrenzen hinweg, während Schannel keinen Identitätswechsel auf Delegatebene unterstützt. Wenn Sie über einen Proxy auf Identitätswechselebene verfügen und die Identitätswechselebene auf Delegate festlegen möchten, sollten Sie SetBlanket mithilfe der Standardkonstanten für jeden Parameter außer der Identitätswechselebene aufrufen. COM wählt NTLM lokal und das Kerberos-Protokoll remote aus (wenn das Kerberos-Protokoll funktioniert).