Identitätswechselstufen (Autorisierung)

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

Identitätswechselebene	Beschreibung
SecurityAnonymous	Der Server kann die Identität des Clients nicht imitieren oder identifizieren.
SecurityIdentification	Der Server kann die Identität und die Berechtigungen des Clients abrufen, aber nicht die Identität des Clients imitieren.
SecurityImpersonation	Der Server kann den Sicherheitskontext des Clients im lokalen System imitieren.
SecurityDelegation	Der Server kann den Sicherheitskontext des Clients auf Remotesystemen imitieren.

 

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

Wenn die benannte Pipe-, RPC- oder DDE-Verbindung remote ist, werden die An CreateFile- übergebenen Flags ignoriert, um die Identitätswechselebene festzulegen. 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ätswechselstufe 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 benannte Pipe-, RPC- und DDE-Server. Mit den funktionen ImpersonateSelf, DuplicateTokenund DuplicateTokenEx funktionen kann der Aufrufer eine Identitätswechselebene angeben. Verwenden Sie die GetTokenInformation Funktion, um die Identitätswechselebene eines Zugriffstokensabzurufen.

Auf der SecurityImpersonation-Ebene treten die meisten Aktionen des Threads im Sicherheitskontext des Identitätswechseltokens des Threads statt 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 des Zugriffstokens des Clients.

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

• Wenn ein Identitätswechselthread die CreateProcess--Funktion aufruft, erbt der neue Prozess immer das primäre Token des Prozesses.
• Bei 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 auf die 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.