共用方式為


服務品質(RPC)

用戶端程式可以使用 RpcBindingSetAuthInfoEx 函式,而不是 RpcBindingSetAuthInfo 函式來建立已驗證的系結。 如果這樣做,則會將指標傳遞至 RPC_SECURITY_QOS 結構,做為 rpcBindingSetAuthInfoEx 的最後參數。 此結構包含服務品質的相關信息。 用戶端程式也可以指定身分識別追蹤,並選取模擬類型。

使用 功能RPC_SECURITY_QOS 結構的成員來設定用戶端/伺服器應用程式的哪些部分已經過驗證。 如果選取RPC_C_QOS_CAPABILITIES_DEFAULT,RPC 執行時間連結庫會根據 SSP 的預設值來驗證客戶端或伺服器。 根據預設,Kerberos 通訊協定 SSP 會驗證客戶端和伺服器。 Microsoft提供之所有其他 SSP 的預設值是向伺服器驗證用戶端,但不會向客戶端驗證伺服器。

如果客戶端和伺服器應該一律向彼此驗證,請將 RPC_SECURITY_QOS 結構 功能成員設定為RPC_C_QOS_CAPABILITIES_MUTUAL_AUTH。 某些安全性提供者可能不支援相互驗證。 如果為這類安全性提供者指定了RPC_C_QOS_CAPABILITIES_MUTUAL_AUTH,則會在進行遠端過程調用時傳回錯誤。 使用 SCHANNEL SSP 時,也可以將 功能 成員設定為RPC_C_QOS_CAPABILITIES_ANY_AUTHORITY。 這個常數會指定 SSP 應該驗證遠端過程調用,即使發行用戶端驗證憑證的證書頒發機構單位不在 SSP 的跟證書存儲中也一樣。 如果 SSP 無法辨識證書頒發機構單位,則預設值為拒絕憑證。 證書頒發機構單位是發行驗證憑證的獨立公司或組織,例如 VeriSign。

應用程式也可以設定 RPC 執行時間連結庫所使用的身分識別追蹤。 程式通常會使用 靜態身分識別追蹤。 使用靜態追蹤時,客戶端的認證會在呼叫 rpcBindingSetAuthInfo 函式時設定。 RPC 運行時間連結庫接著會針對系結上的所有 RPC 呼叫使用這些認證,不論呼叫線程或呼叫進程的身分識別變更為何。 應用程式也可以選取 動態身分識別追蹤。 動態身分識別追蹤會指示 RPC 執行時間連結庫在每個呼叫時使用呼叫線程的認證,而不是系結句柄。 默認身分識別追蹤是靜態的。

如果用戶端的身分識別不會變更,靜態身分識別追蹤可能會有更好的效能特性,而且可以儲存 RPC 運行時間,每次呼叫線程上的身分識別是否與提供給安全性系統的身分識別相同。 如果呼叫線程的身分識別可能會在呼叫之間變更,而且伺服器需要辨識這些變更,最好是指定動態身分識別追蹤—RPC 運行時間安靜且有效率地追蹤您身分識別,如果身分識別變更,則會代表您管理該變更。

注意

針對 ncalrpc 呼叫,靜態和動態身分識別追蹤有不同的效能特性,視情況而定,可能更快。

 

在 QOS 規格中,用戶端程式也可以設定伺服器程式可以代表其執行的模擬類型。 如需詳細資訊,請參閱 客戶端模擬

RPC_SECURITY_QOS 結構的版本號碼字段應該一律設定為 RPC_C_SECURITY_QOS_VERSION。