使用 Microsoft Entra 應用程式 Proxy 針對 Kerberos 限制委派 （KCD） 設定進行疑難解答
單一登錄方法會因一個應用程式而異。 Microsoft Entra 應用程式代理預設會提供 Kerberos 限制委派（KCD）。 使用者使用 Kerberos 向私人應用程式進行驗證。
本文提供單一參考點，以針對最常見的問題進行疑難解答。 它也涵蓋診斷更複雜的實作問題。
本文會進行下列假設。
- 部署 Microsoft Entra 應用程式代理及對非 KCD 應用程式的一般存取。 如需詳細資訊，請參閱 開始使用應用程式 Proxy。
- 已發佈的應用程式是以 Internet Information Services （IIS） 和 Microsoft 的 Kerberos 實作為基礎。
- 伺服器和應用程式主機位於單一Microsoft Entra 網域中。 如需跨網域和樹系案例的詳細資訊，請參閱 KCD 白皮書。
- 應用程式在啟用了預先驗證的 Microsoft Entra 租用戶中發佈。 用戶應該使用表單型驗證進行驗證。 本文未涵蓋豐富的客戶端驗證案例。
先決條件
簡單的設定錯誤或一般錯誤會導致大部分的問題。 在進行疑難解答之前，請先檢查 使用 KCD 單一簽到搭配應用程式 Proxy 的所有必要條件。
連接器主機並不限於只與特定本地站點域控制器（DC）通訊。 檢查所使用的DC，因為它可能會變更。
跨網域案例依賴將連接器主機導向至可能位於局域網路周邊外部的DC的轉介。 在這些情況下，同樣重要的是將流量傳送至代表其他各自網域的DC。 如果沒有，委派會失敗。
避免在連接器主機與數據中心（DC）之間使用主動入侵防禦系統（IPS）或入侵檢測系統（IDS）裝置。 這些裝置太侵入性，並干擾核心遠端過程調用 （RPC） 流量。
簡單情境中的測試委派。 您引進的變數越多，您可能必須面對的變數越多。 若要節省時間，請將測試限制為單一連接器。 在問題解決之後新增更多連接器。
某些環境因素也可能對問題造成影響。 若要避免這些因素，請在測試期間盡可能將架構降到最低。 例如，設定錯誤的內部防火牆訪問控制清單 （ACL） 很常見。 可能的話，請直接從連接器傳送所有流量到 DC 和後端應用程式。
定位連接器的最佳位置盡可能接近其目標。 測試時內嵌的防火牆會增加不必要的複雜性，並延長您的調查時間。
哪些顯示 KCD 問題？ 有幾個常見的跡象顯示 KCD 單一登錄正在失敗。 問題的第一個跡象會出現在瀏覽器中。
這兩個影像都顯示相同的徵兆：單一登錄失敗。 拒絕使用者存取應用程式。
故障排除
將疑難解答分成三個階段。
用戶端預先驗證
透過瀏覽器驗證的外部使用者。 KCD 單一登入 （SSO） 必須能夠預先驗證Microsoft Entra ID 才能運作。 如果發生任何問題，請測試並解決這項功能。 預先驗證階段與 KCD 或已發佈的應用程式無關。 藉由檢查目標帳戶是否存在於 Microsoft Entra ID 中，即可輕鬆更正任何差異。 檢查應用程式未停用或封鎖。 瀏覽器中的錯誤回應足以說明原因。
委派服務
用於從 Kerberos 金鑰發佈中心 (KCD) 取得使用者 Kerberos 服務票證的私人網路連接器。
用戶端與 Azure 前端之間的外部通訊與 KCD 沒有任何影響。 這些通訊只會確保 KCD 能夠運作。 應用程式 Proxy 服務會提供有效的使用者標識碼，用來取得 Kerberos 票證。 如果沒有此標識碼，就無法使用 KCD 並失敗。
瀏覽器錯誤訊息提供一些有用的線索，幫助了解為何會失敗的原因。 記錄回應中的 activity ID 和 timestamp 欄位。 此資訊有助於將行為與應用程式 Proxy 事件記錄檔中的實際事件相互關聯。
事件記錄檔中看到的對應項目會顯示為事件 13019 或 12027。 在 應用程式和服務記錄中尋找連接器事件記錄，>Microsoft>Microsoft Entra 私有網路>連接器>管理員。
- 在您的內部網域名稱系統 （DNS） 中使用 A 記錄作為應用程式的位址，而不是
CName。 - 重新確認連接器主機有權委派給指定之目標帳戶的服務主體名稱 （SPN）。 重新確認 已選取「使用任何驗證通訊協定」。 如需詳細資訊，請參閱 SSO 組態一文。
- 確認Microsoft Entra ID 中只有一個SPN實例存在。 從任何網域成員主機上的命令提示字元發出
setspn -x。 - 檢查網域原則是否已被強制執行，以限制所發行 Kerberos 令牌的最大大小 。 如果連接器過多，原則會阻止連接器取得令牌。
擷取連接器主機與網域 Kerberos 限制委派 （KDC） 之間交換的網路追蹤，是取得問題更低階詳細數據的下一個步驟。 如需詳細資訊，請參閱 深入探討疑難解答檔。
如果票證系統正常，您會在日誌中看到一個事件，指出驗證失敗，因為應用程式傳回了 401 錯誤。 此事件表示目標應用程式拒絕您的票證。 移至下一個階段。
目標應用程式
連接器所提供的 Kerberos 票證取用者。 在此階段，預期連接器會將 Kerberos 服務票證傳送至後端。 票證是第一個應用程式要求中的標頭。
藉由使用入口網站中定義的應用程式內部URL，驗證應用程式是否可從連接器主機上的瀏覽器直接存取。 然後，您可以成功登入。 您可以在連接器 疑難解答 頁面上找到詳細數據。
確認瀏覽器與應用程式之間的驗證使用 Kerberos。
在 Internet Explorer 中執行 DevTools （F12），或使用連接器主機 Fiddler。 使用內部 URL 移至應用程式。 若要確定交涉或 Kerberos 存在，請檢查應用程式回應中傳回的提供的 Web 授權標頭。
從瀏覽器回應應用程式中返回的下一個 Kerberos Blob 會以 YII開頭。 這些字母會告訴您 Kerberos 正在運行。 另一方面，Microsoft NT LAN Manager（NTLM）由 TlRMTVNTUAAB開始，從Base64解碼時會讀出NTLM安全性支援提供者（NTLMSSP）。 如果您在 Blob 開頭看到 TlRMTVNTUAAB，則無法使用 Kerberos。 如果您看不到 TlRMTVNTUAAB，那麼 Kerberos 可能是可用的。
注意
如果您使用 Fiddler，此方法會要求您暫時停用 IIS 中應用程式組態上的擴充保護。
此圖中的 Blob 不是從 TIRMTVNTUAAB開始。 因此，在此範例中，可以使用 Kerberos，而 Kerberos Blob 的開頭不是 YII。
暫時從 IIS 網站上的提供者清單中移除 NTLM。 直接從連接器主機上的 Internet Explorer 存取應用程式。 NTLM 已不在提供者清單中。 您只能使用 Kerberos 存取應用程式。 如果存取失敗，應用程式組態可能會發生問題。 Kerberos 驗證無法運作。
如果 Kerberos 無法使用，請檢查 IIS 中的應用程式驗證設定。 請確保 協商 列在頂端，且NTLM就在其下方。 如果您看到 Not Negotiate、Kerberos 或 Negotiate，或 PKU2U，請確保只有在 Kerberos 功能正常時才繼續。
使用 Kerberos 和 NTLM，暫時停用入口網站中應用程式的預先驗證。 嘗試使用外部 URL 從因特網存取它。 系統會提示您進行驗證。 您可以使用上一個步驟中使用的相同帳戶來執行此動作。 如果有的話，問題出在後端應用程式，而不是 KCD。
在入口網站中重新啟用預先驗證。 嘗試透過其外部 URL 連線到應用程式，透過 Azure 進行驗證。 如果 SSO 失敗，您會在瀏覽器中看到禁止的錯誤訊息，並在記錄檔中看到事件 13022：
Microsoft Entra 專用網連接器無法驗證使用者，因為後端伺服器會以 HTTP 401 錯誤回應 Kerberos 驗證嘗試。
檢查 IIS 應用程式。 請確定已設定的應用程式集區和 SPN 已設定為使用 Microsoft Entra 識別碼中的相同帳戶。 在 IIS 中流覽，如下圖所示。
在了解身分識別後，請確保此帳戶已設定為具有所述的 SPN。 例如
setspn –q http/spn.wacketywack.com。 在命令提示字元中輸入下列文字。
檢查 SPN 是否符合入口網站中應用程式的設定。 請確定應用程式的應用程式集區使用針對目標Microsoft Entra 帳戶所設定的相同SPN。
移至 IIS，然後選取應用程式的 [組態編輯器] 選項。 瀏覽至 system.webServer/security/authentication/windowsAuthentication。 請確定值 UseAppPoolCredentials 為 True 。
將值變更為 true 。 執行 命令，從後端伺服器移除所有快取的 Kerberos 票證。
Get-WmiObject Win32_LogonSession | Where-Object {$_.AuthenticationPackage -ne 'NTLM'} | ForEach-Object {klist.exe purge -li ([Convert]::ToString($_.LogonId, 16))}
如果您將核心模式保留為啟用狀態，則會改善 Kerberos 作業的效能。 但它也會使用機器帳戶來解密被請求服務的票證。 此帳戶也稱為本機系統帳戶。 將此值設定為 True，當應用程式託管於伺服器陣列中的多個伺服器時，使 KCD 失效。
另一項檢查方法是停用 擴展 保護。 在某些情況下，在特定設定中啟用 擴充 保護後，KCD 出現故障。 在這些情況下，應用程式會發佈為默認網站的子資料夾。 此應用程式僅針對匿名驗證進行設定。 所有對話框都會呈現灰色，這表示子物件不會繼承任何使用中的設定。 建議您測試，但不要忘了盡可能將此值還原至 啟用。
此額外的檢查可引導您使用已發佈的應用程式。 您可以建立更多也設定為委派的連接器。 如需詳細資訊，請參閱更深入的技術解析，針對 Microsoft Entra 應用程式 Proxy 進行疑難解答。
如果您仍然無法取得進展，Microsoft支援可協助您。 直接在平台內建立支援票證。
其他案例
Microsoft Entra 應用程式 Proxy 會先要求 Kerberos 票證，再將其要求傳送至應用程式。 有些應用程式不喜歡這個驗證方法。 這些應用程式預期會進行更傳統的談判。 第一個要求是匿名的，可讓應用程式透過 401 回應其支援的驗證類型。 您可以使用本檔案中所述的步驟來啟用這種類型的 Kerberos 交涉：單一登入的 Kerberos 限制委派。
多重跳躍驗證通常用於分層應用程式的情境。 這些階層包括後端和前端。 這兩層都需要驗證。 例如，SQL Server Reporting Services。 如需詳細資訊，請參閱 如何設定 Kerberos 限制委派以用於 Web 註冊代理頁面。