Szolgáltatásminőség (RPC)
Az ügyfélprogramok az RpcBindingSetAuthInfoEx függvényt használhatják a RpcBindingSetAuthInfo függvény helyett hitelesített kötés létrehozásához. Ha igen, akkor az RpcBindingSetAuthInfoEx utolsó paramétereként egy RPC_SECURITY_QOS szerkezetre mutató mutatót adnak át. Ez a struktúra a szolgáltatás minőségével kapcsolatos információkat tartalmaz. Az ügyfélprogramok megadhatják az identitáskövetést is, és kiválaszthatják a megszemélyesítés típusát.
A RPC_SECURITY_QOS-struktúra képességek használatával beállíthatja, hogy az ügyfél-kiszolgáló alkalmazás mely részei legyenek hitelesítve. Ha RPC_C_QOS_CAPABILITIES_DEFAULT van kiválasztva, az RPC futásidejű kódtár az SSP alapértelmezett értékének megfelelően hitelesíti az ügyfelet vagy a kiszolgálót. Alapértelmezés szerint a Kerberos protokoll SSP az ügyfelet és a kiszolgálót is hitelesíti. A Microsoft által biztosított összes többi SSP esetében az alapértelmezett az ügyfél hitelesítése a kiszolgálón, de nem a kiszolgáló hitelesítése az ügyfél számára.
Ha az ügyfélnek és a kiszolgálónak mindig hitelesítenie kell egymást, állítsa a képességeketRPC_SECURITY_QOS struktúra tagját RPC_C_QOS_CAPABILITIES_MUTUAL_AUTH. Egyes biztonsági szolgáltatók nem támogatják a kölcsönös hitelesítést. Ha RPC_C_QOS_CAPABILITIES_MUTUAL_AUTH van megadva az ilyen biztonsági szolgáltatókhoz, a rendszer hibát ad vissza távoli eljáráshívás esetén. Az SCHANNEL SSP használatakor a Képességek tagot is beállíthatja RPC_C_QOS_CAPABILITIES_ANY_AUTHORITY. Ez az állandó azt határozza meg, hogy az SSP akkor is érvényesítse a távoli eljáráshívást, ha az ügyfél hitelesítési tanúsítványát kiállító hitelesítésszolgáltató nem található az SSP főtanúsítvány-tárolójában. Az alapértelmezett beállítás a tanúsítvány elutasítása, ha az SSP nem ismeri fel a hitelesítésszolgáltatót. A hitelesítésszolgáltató egy független vállalat vagy szervezet, például a VeriSign, amely hitelesítési tanúsítványokat ad ki.
Az alkalmazások beállíthatják az RPC futásidejű kódtár által használt identitáskövetést is. A programok általában statikus identitáskövetésihasználnak. Statikus nyomkövetés esetén az ügyfél hitelesítő adatai akkor vannak beállítva, amikor meghívja az RpcBindingSetAuthInfo függvényt. Az RPC futásidejű kódtára ezután ezeket a hitelesítő adatokat használja a kötésen futó összes RPC-híváshoz, függetlenül a hívó szál vagy a hívási folyamat identitásának változásaitól. Az alkalmazások dinamikus identitáskövetésiis kiválaszthatnak. A dinamikus identitáskövetés arra utasítja az RPC futásidejű kódtárat, hogy a hívó szál hitelesítő adatait használja az egyes hívások idején a kötési leíró helyett. Az alapértelmezett identitáskövetés statikus.
Ha az ügyfél identitása nem változik, a statikus identitáskövetés jobb teljesítményjellemzőkkel rendelkezhet, és mentheti az RPC futási idejét, hogy minden alkalommal ellenőrizze, hogy a hívó szál identitása megegyezik-e a biztonsági rendszernek adott identitással. Ha a híváslánc identitása megváltozhat a hívások között, és a kiszolgálónak el kell ismernie ezeket a módosításokat, a legjobb, ha dinamikus identitáskövetést ad meg – az RPC futási ideje csendesen és hatékonyan követi nyomon az Ön identitását, és ha az identitás megváltozik, az Ön nevében kezeli a módosítást.
Jegyzet
A ncalrpc hívások esetében a statikus és a dinamikus identitáskövetés különböző teljesítményjellemzőkkel rendelkezik, és a körülményektől függően bármelyik gyorsabb lehet.
A QOS-specifikáció részeként az ügyfélprogram beállíthatja azt a megszemélyesítési típust is, amelyet egy kiszolgálóprogram a nevében el tud végezni. További információ: Ügyfél megszemélyesítése.
A RPC_SECURITY_QOS struktúra verziószám mezőjét mindig RPC_C_SECURITY_QOS_VERSION kell beállítani.