針對 CredSSP 進行疑難排解
當您評估 Azure Stack HCI 管理和維護工作時，Contoso 的資訊安全小組正在檢查新作業模型的安全性相關含意。 其中一個特別值得注意的領域是驗證。 Contoso 依賴 AD DS 作為 Windows 和 Linux 工作負載的身分識別提供者，並以 Kerberos 作為主要驗證通訊協定。 資訊安全小組要求您找出可能相依於其他驗證通訊協定的 Azure Stack HCI 工作，並判斷其使用方式的潛在含意。 在整個評估中，您遇到幾個強制您暫時切換到 CredSSP 型驗證的案例。 現在，您想要驗證 CredSSP 的需求，並記錄有關其使用方式的任何可能考量。
Azure Stack HCI 中 CredSSP 驗證的角色概觀
CredSSP 的主要目的是為了輔助涉及用戶端、伺服器和遠端資源等三個元件的遠端委派案例。 使用 CredSSP 時，使用者會向用戶端驗證，此用戶端會將使用者的認證委派給伺服器，而後者會使用這些認證來存取遠端資源。 使用 Windows 遠端管理 (WinRM) 和 PowerShell 遠端時，通常需要這類委派。
注意
不同於 Kerberos，藉由限制使用委派認證來存取的遠端服務，CredSSP 會將認證傳遞給伺服器，而不需要任何條件約束。 由於此功能，讓 CredSSP 的設定較簡單，但並不提供與 Kerberos 相同的保護層級。 如果伺服器遭到入侵，則可能會使用使用者認證來取得其他網路資源的存取權。
注意
CredSSP 驗證可作為環境的因應措施，在此情況下，執行 Kerberos 委派不是可行的選項。 設定 Kerberos 限制委派需要存取 AD DS 的特殊權限。
某些 Azure Stack HCI WinRM 型作業需要委派，其中包括執行 Windows Admin Center 型的「建立叢集」精靈和設定叢集感知更新 (CAU)。 在這種情況下，您可以暫時啟用管理電腦與 Azure Stack HCI 伺服器之間的 CredSSP。
注意
完成依賴其功能的工作之後，您必須停用 CredSSP。
在 Azure Stack HCI 中管理 CredSSP 並進行疑難排解
設定 WinRM 型 CredSSP 設定的方法包括 WinRM 公用程式、群組原則及 Windows PowerShell。 無論選擇哪一種方法，都必須啟用用戶端和伺服器的 CredSSP 委派。 CredSSP 也需要伺服器上的 HTTPS 接聽程式。 此外，AD DS 伺服器和用戶端電腦物件必須包含服務主體名稱 (SPN) 與 WSMAN 服務類別相關聯的屬性值。
若要啟用 CredSSP 型的使用者認證委派給伺服器，請在用戶端電腦上提高權限的 PowerShell 工作階段中執行下列命令 (其中 <server_FQDN_name> 預留位置代表伺服器) 的完整 DNS 名稱：
Enable-WsmanCredSSP -Role Client -DelegateComputer <server_FQDN_name>
若要在伺服器上啟用 CredSSP 型委派 (例如透過主控台工作階段或遠端桌面)，然後在提高權限的 PowerShell 工作階段中執行下列命令：
Enable-WsmanCredSSP -Role Server
用戶端和伺服器電腦的 SPN 屬性設定的驗證和疑難排解流程都相同。 在這兩種情況下，請從提高權限的命令提示字元中執行下列命令開始 (其中 <computer_name> 預留位置代表您要識別 SPN 的電腦名稱)：
setspn -Q WSMAN/<computer_name>
結果應包含 WSMAN/<computer_name> 和 WSMAN/<computer_FQDN_name>。 如果不是這種情況，請在提升權限的命令提示字元中執行下列命令 (其中 <computer_name> 預留位置代表您註冊 SPN 的電腦名稱)：
setspn -S WSMAN/<computer_name> <computer_name>
在 Azure Stack HCI 中管理 CredSSP 和進行疑難排解的過程中，您也應該牢記下列驗證和授權考量：
- 需要閘道系統管理員角色權限，以進行許多委派相關的工作，包括從 Windows Admin Center 中啟用和停用 CredSSP，或執行建立叢集的精靈。
- 主控 Windows Admin Center 的電腦應該是與受控 Azure Stack HCI 叢集相同 AD DS 網域的成員。