Snego

  • 發行項

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

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

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

注意

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

 

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

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

COM 和安全性套件