共用方式為

Snego

  • 發行項

Snego，其驗證服務標識碼是RPC_C_AUTHN_GSS_NEGOTIATE，實際上不會提供驗證服務本身。 相反地，它會採用驗證服務清單，並交涉將在用戶端和伺服器之間運作的服務。 Snego 不會使用驗證參數，而是會傳遞至所選的驗證服務，這會執行實際驗證。 Snego於1998年12月由互聯網工程工作隊（IETF）標準化，檔 RFC 2478。

當您不知道遠端計算機可以提供哪些驗證服務時，Snego 會很有用。

若要使用 Snego，用戶端和伺服器都必須將 Snego 指定為驗證服務。 伺服器會將RPC_C_AUTHN_GSS_NEGOTIATE指定為 dwAuthnSvc 成員，asAuthSvc 數位列參數中傳遞至 coInitializeSecurity的其中一個SOLE_AUTHENTICATION_SERVICE 結構成員。 用戶端可以呼叫coSetProxyBlanketSnego，並將RPC_C_AUTHN_GSS_NEGOTIATE傳遞為 dwAuthnSvc 參數。 用戶端也應該透過傳遞至 pAuthInfo 參數之 SEC_WINNT_AUTH_IDENTITY_EX 結構的 PackageList 成員，為 Snego 提供可能的驗證服務清單，以 呼叫 coSetProxyBlanket。 如果 pAuthInfoNULL，Snego 會從電腦上安裝的安全性套件撰寫驗證服務清單。 然後 Snego 會將驗證服務清單傳送至伺服器、比較清單與伺服器的可用驗證服務，並挑選要用於連線的驗證服務。

注意

安全通道不能位於 Snego 使用的驗證服務清單中。

 

當用戶端呼叫 coInitializeSecurity 時，也可以指定 Snego。 dwAuthnSvc 和 pAuthInfo coSetProxyBlanket 參數會透過 pAuthList 參數傳遞至CoInitializeSecurity 的 SOLE_AUTHENTICATION_INFO 結構成員。 這些成員值的詳細數據與上一段所述相同。

如果使用 Snego，則呼叫 CoQueryProxyBlanket 或 CoQueryClientBlanket 會傳回 Snego 作為驗證服務，而不是 Snego 為建立連線所挑選的實際驗證服務。

COM 和安全性套件