使用 Microsoft Entra 應用程式 Proxy 針對 Kerberos 限制委派 （KCD） 設定進行疑難解答

單一登錄方法會因一個應用程式而異。 Microsoft Entra 應用程式 Proxy 預設會提供 Kerberos 限制委派 （KCD）。 使用者使用 Kerberos 向私人應用程式進行驗證。

本文提供單一參考點，以針對最常見的問題進行疑難解答。 本文也涵蓋較複雜實作問題的診斷。

本文會進行下列假設。

• 部署 Microsoft Entra 應用程式 Proxy，以及對非 KCD 應用程式的一般存取。 如需詳細資訊，請參閱 開始使用應用程式 Proxy。
• 已發佈的應用程式是以 網際網路資訊服務 （IIS） 和 Microsoft 實作 Kerberos 為基礎。
• 伺服器和應用程式主機位於單一 Microsoft Entra 網域中。 如需跨網域和樹系案例的詳細資訊，請參閱 KCD 白皮書。
• 應用程式會在已啟用預先驗證的 Microsoft Entra ID 租用戶中發佈。 用戶應該使用表單型驗證進行驗證。 本文未涵蓋豐富的客戶端驗證案例。

必要條件

簡單的設定錯誤或一般錯誤會導致大部分的問題。 在疑難解答之前，請先檢查搭配應用程式 Proxy 使用 KCD 單一登錄中的所有必要條件。

連線 or 主機不限於僅與特定本機站臺域控制器 （DC） 通訊。 檢查所使用的DC，因為它可能會變更。

跨網域案例依賴將連接器主機導向至可能位於局域網路周邊外部的DC的轉介。 在這些情況下，同樣重要的是，也會將流量傳送至代表其他個別網域的DC。 如果沒有，委派會失敗。

避免連接器主機與DC之間的主動入侵預防系統 （IPS） 或入侵檢測系統 （IDS） 裝置。 這些裝置太侵入性，並干擾核心遠端過程調用 （RPC） 流量。

簡單案例中的測試委派。 您引進的變數越多，您可能必須面對的變數越多。 若要節省時間，請將測試限制為單一連接器。 在問題解決之後新增更多連接器。

某些環境因素也可能對問題造成影響。 若要避免這些因素，請在測試期間盡可能將架構降到最低。 例如，設定錯誤的內部防火牆 存取控制 清單 （ACL） 很常見。 可能的話，請直接從連接器傳送所有流量到 DC 和後端應用程式。

定位連接器的最佳位置盡可能接近其目標。 測試時內嵌的防火牆會增加不必要的複雜性，並延長您的調查時間。

哪些顯示 KCD 問題？ 有數個常見的指示，指出 KCD 單一登錄失敗。 問題的第一個跡象會出現在瀏覽器中。

這兩個影像都顯示相同的徵兆：單一登錄失敗。 拒絕使用者存取應用程式。

疑難排解

將疑難解答分成三個階段。

用戶端預先驗證

透過瀏覽器驗證的外部使用者。 KCD 單一登入 （SSO） 必須能夠預先向 Microsoft Entra ID 進行驗證才能運作。 如果發生任何問題，請測試並解決這項功能。 預先驗證階段與 KCD 或已發佈的應用程式無關。 藉由檢查主旨帳戶是否存在於 Microsoft Entra 識別碼中，即可輕鬆更正任何差異。 檢查應用程式未停用或封鎖。 瀏覽器中的錯誤回應足以說明原因。

委派服務

從 Kerberos 金鑰發佈中心 （KCD） 取得使用者的 Kerberos 服務票證專用網連接器。

用戶端與 Azure 前端之間的外部通訊與 KCD 沒有任何影響。 這些通訊只會確保 KCD 能夠運作。 應用程式 Proxy 服務會提供有效的使用者標識碼，用來取得 Kerberos 票證。 如果沒有此標識碼，就無法使用 KCD 並失敗。

瀏覽器錯誤訊息提供一些關於原因失敗的良好線索。 activity ID記錄回應中的和 timestamp 欄位。 此資訊有助於將行為與應用程式 Proxy 事件記錄檔中的實際事件相互關聯。

事件記錄檔中看到的對應項目會顯示為事件 13019 或 12027。 在應用程式與服務記錄>中尋找連接器事件記錄 Microsoft Microsoft>Entra 專用網> 連線 or> 管理員。

1. 在您的內部網域名稱系統 （DNS） 中使用 A 記錄作為應用程式的位址，而不是 CName。
2. 重新確認連接器主機有權委派給指定之目標帳戶的服務主體名稱 （SPN）。 重新確認 已選取 [使用任何驗證通訊協定 ]。 如需詳細資訊，請參閱 SSO 組 態一文。
3. 確認 Microsoft Entra ID 中只有一個 SPN 實例存在。 從任何網域成員主機上的命令提示字元發出問題 setspn -x 。
4. 檢查是否強制執行網域原則，以限制 所發行 Kerberos 令牌的大小上限。 如果連接器過多，原則會阻止連接器取得令牌。

擷取連接器主機與網域 Kerberos 限制委派 （KDC） 之間交換的網路追蹤，是取得問題更低階詳細數據的下一個步驟。 如需詳細資訊，請參閱 深入探討疑難解答檔。

如果票證看起來不錯，您會在記錄中看到事件，指出驗證失敗，因為應用程式傳回了 401。 此事件表示目標應用程式拒絕您的票證。 移至下一個階段。

目標應用程式

連接器所提供的 Kerberos 票證取用者。 在此階段，預期連接器會將 Kerberos 服務票證傳送至後端。 票證是第一個應用程式要求中的標頭。

1. 藉由使用入口網站中定義的應用程式內部URL，驗證應用程式是否可從連接器主機上的瀏覽器直接存取。 然後，您可以成功登入。 您可以在連接器 疑難解答 頁面上找到詳細數據。

2. 確認瀏覽器與應用程式之間的驗證使用 Kerberos。

3. 在 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 開頭。

4. 暫時從 IIS 網站上的提供者清單中移除 NTLM。 直接從連接器主機上的 Internet Explorer 存取應用程式。 NTLM 已不在提供者清單中。 您只能使用 Kerberos 存取應用程式。 如果存取失敗，應用程式組態可能會發生問題。 Kerberos 驗證無法運作。

   • 如果 Kerberos 無法使用，請檢查 IIS 中的應用程式驗證設定。 請確定 交涉 列在頂端，且NTLM就在其下方。 如果您看到 [不交涉]、[Kerberos] 或 [交涉] 或 [PKU2U]，則只有在 Kerberos 正常運作時才繼續。

     

   • 使用 Kerberos 和 NTLM，暫時停用入口網站中應用程式的預先驗證。 嘗試使用外部 URL 從因特網存取它。 系統會提示您進行驗證。 您可以使用上一個步驟中使用的相同帳戶來執行此動作。 如果沒有，後端應用程式沒有問題，而不是 KCD。

   • 在入口網站中重新啟用預先驗證。 嘗試透過其外部 URL 連線到應用程式，透過 Azure 進行驗證。 如果 SSO 失敗，您會在瀏覽器中看到禁止的錯誤訊息，並在記錄檔中看到事件 13022：

     Microsoft Entra 專用網連接器無法驗證使用者，因為後端伺服器會以 HTTP 401 錯誤回應 Kerberos 驗證嘗試。

     

   • 檢查 IIS 應用程式。 請確定已設定的應用程式集區和SPN已設定為在 Microsoft Entra ID 中使用相同的帳戶。 在 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。 如需詳細資訊，請參閱 如何設定 Web 註冊 Proxy 頁面的 Kerberos 限制委派。

下一步

在受控網域上設定 KCD。