主體名稱

若要讓用戶端使用伺服器程式建立相互驗證的工作階段，它必須提供伺服器的預期主體名稱。 某些通訊協定，例如 Kerberos，需要任何已驗證會話的正確伺服器主體名稱。 主體是安全性系統可辨識的實體。 這包括人類使用者以及系統服務。 所有主體名稱都會針對指定的安全性支援提供者 （SSP） 採用類似的格式。 SSP 是執行安全性驗證的軟體模組。 如需詳細資訊，請參閱 SSPI 架構概觀。 為了維持一致性，安全性提供者通常會提供與用戶類似的系統服務名稱。 在某些安全性提供者下，系統服務可能沒有主體名稱。

伺服器會使用 RpcServerRegisterAuthInfo 函式，向安全性提供者註冊其主體名稱。 每個安全性提供者只能使用一個伺服器主體名稱。 如果已註冊多個名稱，則會隨機選擇並使用一個名稱。 SSP 會指定主體名稱的格式。 例如，系統服務的 Kerberos/Negotiate SSP 看起來大致如下：machine_name$@childdomain.parentdomain1.parentdomain2.COM。

產生主體名稱的建議程式是使用記載的 API（例如 DsMakeSpn 函式），而不是將主體名稱從字串拼湊在一起。 使用記載的 API 會增加不同部署環境之間的可移植性，並消除錯誤的可能性。

指定不正確的主體名稱可能會導致客戶端和伺服器無法建立已驗證的工作階段。 SCHANNEL SSP 採用兩種形式之一的主體名稱：

• 第一個 SCHANNEL 主體名稱表單是 msstd表單。 msstd 格式的名稱通常會遵循模式 msstd：servername@serverdomain.com。 這稱為電子郵件名稱屬性。 如果憑證包含電子郵件名稱屬性，且包含 at sign （@），則主體名稱為 msstd：email name。 否則，它必須包含通用名稱屬性。 內部反斜杠會加倍，就像字串系結一樣。
• 第二個 SCHANNEL 主體名稱表單是完整表單。 這是一系列符合RFC1779規範的名稱，由角括弧系結，並以反斜杠分隔。 它通常會遵循 fullsic：\<\Authority\SubAuthority\.....\Person> 或 fullsic：\<\Authority\SubAuthority\.....\ServerProgram>模式。

如果名稱不符合憑證，則會傳回ERROR_ACCESS_DENIED。 如果名稱格式無效，SCHANNEL SSP 會傳回程式代碼ERROR_INVALID_PARAMETER。

若要查詢伺服器主體名稱，應用程式可以呼叫 RpcMgmtInqServerPrincName。 這會配置以 Null 終止的字串來保存主體名稱。 在終止之前，您的應用程式必須叫用 rpcStringFree 釋放此字串佔用的記憶體。

以這種方式查詢伺服器名稱並不安全，因此應避免。 針對伺服器驗證，用戶端程式應該知道要連線到哪個伺服器，而且應該從頭開始建立伺服器主體名稱。