Identitätswechselebenen (Autorisierung)
Die SECURITY _ IMPERSONATION _ LEVEL-Enumeration definiert vier Identitätswechselebenen, die die Vorgänge bestimmen, die 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 keine Identität des Clients 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 für das Konto des Servers im Verzeichnisdienst festgelegt wird. 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, DuplicateTokenund DuplicateTokenEx kann der Aufrufer eine Identitätswechselebene angeben. Verwenden Sie die GetTokenInformation-Funktion, um die Identitätswechselebene eines Zugriffstokensabzurufen.
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 Thread mit Identitätswechsel ein sicherungsfähiges Objektöffnet, verwendet das System das Identitätswechseltoken, um den Zugriff des Threads zu überprüfen. Analog dazu ist der Besitzer des neuen Objekts der Standardbesitzer aus dem Zugriffstokendes Clients, wenn ein Thread, der die Identität an sich nimmt, ein neues -Objekt erstellt, z. B. durch Aufrufen der CreateFile-Funktion.
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, überprüft das System immer im primären Token des Prozesses nach der Berechtigung.
- Für Funktionen, die die SE _ AUDIT _ NAME-Berechtigung erfordern, z. B. die ObjectOpenAuditAlarm-Funktion, überprüft das System immer im primären Token des Prozesses nach der Berechtigung.
- 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 dem angeforderten Zugriff gewährt werden soll.