AD FS 疑難排解 - 整合式 Windows 驗證
整合式 Windows 驗證允許使用者使用 Windows 認證登入，並使用 Kerberos 或 NTLM 體驗單一登入 (SSO)。
整合式 windows 驗證失敗的原因
整合式 windows 驗證失敗的主要原因有三個。 它們是：- 服務主體名稱 (SPN) 設定錯誤 - 通道系結權杖 - Internet Explorer 設定
SPN 設定錯誤
服務主體名稱 (SPN) 是服務執行個體的唯一識別碼。 SPN 由 Kerberos 驗證用於將服務執行個體與服務登入帳戶相關聯。 這允許用戶端應用程式要求服務對帳戶進行驗證，即使用戶端沒有帳戶名稱。
SPN 如何與 AD FS 一起使用的範例如下：
- web 瀏覽器査詢 Active Directory 以確定哪個服務帳戶正在執行 sts.contoso.com
- Active Directory 告訴瀏覽器它是 AD FS 服務帳戶。
- 瀏覽器將取得 AD FS 服務帳戶的 Kerberos 票證。
如果 AD FS 服務帳戶的 SPN 設定錯誤或錯誤，則可能會導致問題。 查看網路追蹤，您可能會看到錯誤，例如 KRB 錯誤：KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN。
使用網路追蹤 (如 Wireshark)，您可以確定瀏覽器試圖解析的 SPN，然後使用命令列工具 setspn - Q <spn>，您可以在該 SPN 上進行查詢。 可能找不到它，或者它可能被指派至 AD FS 服務帳戶以外的其他帳戶。
您可以透過查看 AD FS 服務帳戶的屬性來驗證 SPN。
通道系結權杖
就目前而言，當用戶端應用程式使用 Kerberos、Digest 或 NTLM 透過 HTTPS 向伺服器驗證自身時，首先會建立傳輸層安全性 (TLS) 通道，並且使用此通道進行驗證。
通道系結權杖是 TLS 已受到保護的外部通道之屬性，用於將外部通道繫結至透過用戶端驗證的內部通道上的交談。
如果發生了「中間人」攻擊，並且他們正在解密和重新加密 SSL 流量，那麼金鑰將不相符。 AD FS 將確定在 web 瀏覽器和它自己之間有什麼東西。 這將導致 Kerberos 驗證失敗，並且將提示使用者使用 401 對話方塊，而不是 SSO 體驗。
可能的原因如下：
- 位於瀏覽器和 AD FS 之間的任何內容
- Fiddler
- 執行 SSL 橋接的反向 Proxy
根據預設，AD FS 將此設定為「允許」。 您可以使用 PowerShell cmdlet Set-ADFSProperties -ExtendedProtectionTokenCheck None 變更此設定
如需此方面的詳細資訊，請參閱 AD FS 安全規劃和部署的最佳做法。
Internet Explorer 設定
注意
如果您正在使用 Chrome，請將其新增至 WIA 支援的使用者代理程式清單中。
根據預設，Internet Explorer 的行為方式如下：
- Internet Explorer 將從 AD FS 接收 401 回應，其在標頭中具有單字 NEGOTIATE。
- 這告訴 web 瀏覽器取得要傳送回 AD FS 的 Kerberos 或 NTLM 票證。
- 根據預設，如果標頭中有單字 NEGOTIATE，IE 將嘗試在沒有使用者互動的情况下執行此動作 (SPNEGO)。 它只適用於内部網路網站。
主要有兩件事可以防止這種情況的發生。
IE 的屬性中未選中 [啟用整合式 Windows 驗證]。 這位於 Internet 選項 - >進階 - > 安全性下。
安全性區域設定不正確
FQDN 不在内部網路區域中
AD FS URL 不在内部網路區域中。
