Identitätswechselebenen (Autorisierung)

Die SECURITY_IMPERSONATION_LEVEL-Enumeration definiert vier Identitätswechselebenen, die bestimmen, welche Vorgänge ein Server im Clientkontext ausführen kann.

Ebene des Identitätswechsels	BESCHREIBUNG
SecurityAnonymous	Der Server kann die Identität des Clients nicht annehmen oder identifizieren.
SecurityIdentification	Der Server kann die Identität und die Berechtigungen des Clients abrufen, aber die Identität des Clients nicht annehmen.
SecurityImpersonation	Der Server kann die Identität des Sicherheitskontexts des Clients auf dem lokalen System annehmen.
SecurityDelegation	Der Server kann die Identität des Sicherheitskontexts des Clients auf Remotesystemen annehmen.

 

Der Client einer Named Pipe-, RPC- oder DDE-Verbindung kann die Identitätswechselebene steuern. Beispielsweise kann ein Named Pipe-Client die CreateFile-Funktion aufrufen, um ein Handle für eine Named Pipe zu öffnen und die Identitätswechselebene des Servers anzugeben.

Wenn die Named Pipe-, RPC- oder DDE-Verbindung remote ist, werden die an CreateFile übergebenen Flags zum Festlegen der Identitätswechselebene ignoriert. In diesem Fall wird die Identitätswechselebene des Clients durch die vom Server aktivierten Identitätswechselebenen bestimmt, die durch ein Flag im Serverkonto im Verzeichnisdienst festgelegt werden. Wenn der Server beispielsweise für die Delegierung aktiviert ist, wird die Identitätswechselebene des Clients auch dann auf Delegierung festgelegt, wenn die an CreateFile übergebenen Flags die Identitätswechselebene angeben.

DDE-Clients verwenden die DdeSetQualityOfService-Funktion mit der SECURITY_QUALITY_OF_SERVICE-Struktur , um die Identitätswechselebene anzugeben. Die SecurityImpersonation-Ebene ist die Standardeinstellung für Named Pipe-, RPC- und DDE-Server. Mit den Funktionen ImpersonateSelf, DuplicateToken und DuplicateTokenEx kann der Aufrufer eine Identitätswechselebene angeben. Verwenden Sie die GetTokenInformation-Funktion , um die Identitätswechselebene eines Zugriffstokens abzurufen.

Auf der SecurityImpersonation-Ebene erfolgen die meisten Aktionen des Threads im Sicherheitskontext des Identitätswechseltokens des Threads und nicht im primären Token des Prozesses , der den Thread besitzt. Wenn beispielsweise ein Identitätswechselthread ein sicherungsfähiges Objekt öffnet, verwendet das System das Identitätswechseltoken, um den Zugriff des Threads zu überprüfen. Wenn ein Identitätswechselthread ein neues Objekt erstellt, z. B. durch Aufrufen der CreateFile-Funktion , ist der Besitzer des neuen Objekts der Standardbesitzer aus dem Zugriffstoken des Clients.

In den folgenden Situationen verwendet das System jedoch das primäre Token des Prozesses anstelle des Identitätswechseltokens des aufrufenden Threads:

• Wenn ein Identitätswechselthread die CreateProcess-Funktion aufruft, erbt der neue Prozess immer das primäre Token des Prozesses.
• Für Funktionen, die die SE_TCB_NAME-Berechtigung erfordern, z. B. die LogonUser-Funktion , sucht das System immer nach den Berechtigungen im primären Token des Prozesses.
• Für Funktionen, die die SE_AUDIT_NAME-Berechtigung erfordern, z. B. die ObjectOpenAuditAlarm-Funktion , überprüft das System immer nach den Berechtigungen im primären Token des Prozesses.
• In einem Aufruf der OpenThreadToken-Funktion kann ein Thread angeben, ob die Funktion das Identitätswechseltoken oder das primäre Token verwendet, um zu bestimmen, ob der angeforderte Zugriff gewährt werden soll.