RPC_SECURITY_QOS-Struktur (rpcdce.h)
Die RPC_SECURITY_QOS-Struktur definiert Sicherheitseinstellungen für die Dienstqualität eines Bindungshandles. Informationen zur Versionsverfügbarkeit in Windows-Editionen finden Sie unter Hinweise.
Syntax
typedef struct _RPC_SECURITY_QOS {
unsigned long Version;
unsigned long Capabilities;
unsigned long IdentityTracking;
unsigned long ImpersonationType;
} RPC_SECURITY_QOS, *PRPC_SECURITY_QOS;
Member
Version
Version der verwendeten RPC_SECURITY_QOS-Struktur . In diesem Thema wird Version 1 der RPC_SECURITY_QOS-Struktur dokumentiert. Weitere Versionen finden Sie unter RPC_SECURITY_QOS_V2, RPC_SECURITY_QOS_V3, RPC_SECURITY_QOS_V4 und RPC_SECURITY_QOS_V5 .
Capabilities
Sicherheitsdienste, die für die Anwendung bereitgestellt werden. Funktionen sind eine Reihe von Flags, die mit dem bitweisen OR-Operator kombiniert werden können.
| Wert | Bedeutung |
|---|---|
|
Wird verwendet, wenn keine anbieterspezifischen Funktionen erforderlich sind. |
|
Wenn Sie dieses Flag angeben, wird die RPC-Laufzeit die gegenseitige Authentifizierung vom Sicherheitsanbieter anfordern. Einige Sicherheitsanbieter unterstützen die gegenseitige Authentifizierung nicht. Wenn der Sicherheitsanbieter die gegenseitige Authentifizierung nicht unterstützt oder die Identität des Servers nicht eingerichtet werden kann, schlägt ein Remoteprozeduraufruf eines solchen Servers mit einem Fehler RPC_S_SEC_PKG_ERROR fehl.
Hinweis RPC verwendet den SSP, um anzugeben, welche Sicherheitsoptionen erfolgreich ausgehandelt wurden. RPC schlägt wiederum einen Aufruf fehl, für den der Sicherheitsdienstanbieter (Security Service Provider, SSP) meldet, dass er keine Option aushandeln konnte. Einige Sicherheitsanbieter sind jedoch dafür bekannt, die erfolgreiche Aushandlung einer Option zu melden, auch wenn die Option nicht erfolgreich ausgehandelt wurde. NTLM meldet beispielsweise eine erfolgreiche Aushandlung der gegenseitigen Authentifizierung aus Gründen der Abwärtskompatibilität, auch wenn die gegenseitige Authentifizierung nicht unterstützt wird. Überprüfen Sie den jeweiligen SSP, der verwendet wird, um sein Verhalten in Bezug auf Sicherheitsoptionen zu ermitteln.
|
|
Derzeit nicht implementiert. |
|
Akzeptiert die Anmeldeinformationen des Clients, auch wenn die Zertifizierungsstelle nicht in der Liste der vertrauenswürdigen Zertifizierungsstellen des Servers enthalten ist. Diese Konstante wird nur vom SCHANNEL-SSP verwendet. |
|
Wenn angegeben, weist dieses Flag die RPC-Runtime auf dem Client an, einen Fehler zu ignorieren, um einen Sicherheitskontext einzurichten, der die Delegierung unterstützt. Wenn der Client die Delegierung anfragt und das Sicherheitssystem keinen Sicherheitskontext einrichten kann, der die Delegierung unterstützt, wird normalerweise ein Fehler RPC_S_SEC_PKG_ERROR zurückgegeben. wenn dieses Flag angegeben ist, wird kein Fehler zurückgegeben.
Hinweis Nicht unterstützt unter Windows XP und früheren Clienteditionen, nicht unterstützt unter Windows 2000 und früheren Servereditionen.
|
|
Dieses Flag gibt für RPC an, dass der Server lokal für den Computer ist, der den RPC-Aufruf ausgibt. In dieser Situation weist RPC den Endpunktzuordnungser an, nur Endpunkte aufzunehmen, die vom Prinzipal registriert sind, der in den Membern ServerPrincName oder Sid angegeben ist (diese Member sind nur in RPC_SECURITY_QOS_V3, RPC_SECURITY_QOS_V4 und RPC_SECURITY_QOS_V5 verfügbar). Weitere Informationen finden Sie unter Hinweise.
Hinweis Nicht unterstützt unter Windows XP und früheren Clienteditionen, nicht unterstützt unter Windows 2000 und früheren Servereditionen.
|
|
Wenn festgelegt, verwendet die RPC-Runtime den SChannel-SSP, um smartcardbasierte Authentifizierung durchzuführen, ohne dass ein PIN-Eingabeaufforderungsdialogfeld vom Kryptografiedienstanbieter (Cryptographic Services Provider, CSP) angezeigt wird.
Beim Aufruf von RpcBindingSetAuthInfoEx muss der AuthIdentity-Parameter eine SEC_WINNT_AUTH_IDENTITY-Struktur sein, deren Member Folgendes enthalten:
|
IdentityTracking
Legt den Kontextnachverfolgungsmodus fest. Sollte auf einen der in der folgenden Tabelle dargestellten Werte festgelegt werden.
| Wert | Bedeutung |
|---|---|
|
Der Sicherheitskontext wird nur einmal erstellt und wird während der gesamten Kommunikation nie überarbeitet, auch wenn er von der Clientseite geändert wird. Dies ist das Standardverhalten, wenn RPC_SECURITY_QOS nicht angegeben ist. |
|
Der Kontext wird immer dann überarbeitet, wenn die ModifiedId im Token des Clients geändert wird. Alle Protokolle verwenden die ModifiedId (siehe Hinweis).
Windows 2000: Alle Remoteprotokolle (alle Protokolle außer ncalrpc) verwenden die AuthenticationID, auch als LogonId bezeichnet, um Änderungen an der Clientidentität nachzuverfolgen. Das ncalrpc-Protokoll verwendet ModifiedId. |
ImpersonationType
Ebene, auf der der Serverprozess die Identität des Clients annehmen kann.
| Wert | Bedeutung |
|---|---|
|
Verwendet die Standardidentitätswechselebene. |
|
Der Client stellt dem Server keine Identifikationsinformationen zur Verfügung. Der Server kann die Identität des Clients nicht annehmen oder den Client identifizieren. Viele Server lehnen Anrufe mit diesem Identitätswechseltyp ab.
Hinweis Einige Sicherheitsanbieter behandeln diesen Identitätswechseltyp möglicherweise als gleichwertig mit RPC_C_IMP_LEVEL_IMPERSONATE. Von den Windows-Sicherheitsanbietern erfolgt dies nur durch RPC_C_AUTHN_WINNT, wenn sie mit anderen Protokollsequenzen als ncalrpc verwendet werden. Dies geschieht auch durch RPC_C_AUTHN_GSS_NEGOTIATE, RPC_C_AUTHN_GSS_SCHANNEL und RPC_C_AUTHN_GSS_KERBEROS.
|
|
Der Server kann die Identität des Clients abrufen und die Identität des Clients annehmen, um Access Control List-Überprüfungen (ACL) durchzuführen, kann jedoch die Identität des Clients nicht annehmen. Weitere Informationen finden Sie unter Identitätswechselebenen .
Hinweis Einige Sicherheitsanbieter behandeln diesen Identitätswechseltyp möglicherweise als gleichwertig mit RPC_C_IMP_LEVEL_IMPERSONATE. Von den Windows-Sicherheitsanbietern erfolgt dies nur durch RPC_C_AUTHN_WINNT, wenn sie mit anderen Protokollsequenzen als ncalrpc verwendet werden. Dies geschieht auch durch RPC_C_AUTHN_GSS_NEGOTIATE, RPC_C_AUTHN_GSS_SCHANNEL und RPC_C_AUTHN_GSS_KERBEROS.
|
|
Der Server kann die Identität des Sicherheitskontexts des Clients auf seinem lokalen System annehmen, aber nicht auf Remotesystemen. |
|
Der Server kann als der Client auftreten und dabei dessen Sicherheitskontext imitieren. Der Server kann auch ausgehende Aufrufe an andere Server tätigen, während er im Auftrag des Clients handelt. Der Server kann den Sicherheitskontext des Clients auf anderen Computern verwenden, um auf lokale und Remoteressourcen als Client zuzugreifen. |
Hinweise
Die folgende Auflistung definiert die Verfügbarkeit von QOS-Versionen unter verschiedenen Windows-Betriebssystemen:
- Version 1: Windows 2000 und höher.
- Version 2: Windows XP mit Service Pack 1 (SP1) und höher.
- Version 3: Windows Server 2003 und höher.
- Version 4: Windows Vista und höher.
- Version 5: Windows 8 und höher.
Die clientseitigen Sicherheitsfunktionen RpcBindingInqAuthInfoEx und RpcBindingSetAuthInfo verwenden die RPC_SECURITY_QOS-Struktur , um die Sicherheitsqualität des Diensts für ein Bindungshandle zu ermitteln oder festzulegen.
RPC unterstützt den RPC_C_QOS_CAPABILITIES_LOCAL_MA_HINT-Hinweis. Dieser Hinweis wird nur verwendet, wenn dynamische Endpunkte und die gegenseitige Authentifizierung verwendet werden. Darüber hinaus wird es für die ncadg_ Protokollsequenzen nicht unterstützt. Wenn dieses Flag für eine ncadg_ Protokollsequenz verwendet wird, oder ohne gegenseitige Authentifizierung, wird RPC_S_INVALID_ARG vom RpcBindingSetAuthInfoEx-Funktionsaufruf zurückgegeben. Dieses Flag soll einen Denial-of-Service-Angriff verhindern. Die Verwendung dieses Flags erzwingt die RPC-Runtime, den Endpunktzuordnungsmodul nur für Endpunkte anzufordern, die vom Prinzipal registriert sind, der in den Membern ServerPrincName oder Sid angegeben ist. Dadurch wird verhindert, dass ein Angreifer auf dem lokalen Computer versucht, Ihren RPC-Client zu verleiten, um eine Verbindung mit einem Spoofendpunkt herzustellen, der in der Endpunktzuordnung registriert ist. Da der Angriff nur lokal erfolgt (z. B. von einem Terminalservercomputer mit vielen Benutzern), funktioniert das Flag auch nur für lokale RPC-Aufrufe.
Anforderungen
| Anforderung | Wert |
|---|---|
| Unterstützte Mindestversion (Client) | Windows 2000 Professional [nur Desktop-Apps] |
| Unterstützte Mindestversion (Server) | Windows 2000 Server [nur Desktop-Apps] |
| Kopfzeile | rpcdce.h (include Rpc.h) |