針對 Kerberos 限制委派進行疑難排解

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

本文說明如何針對 KCD 設定中最常見的問題進行疑難解答。 其中包含您可以針對更複雜的實作採取診斷步驟。

本文會做出以下假設：

• Microsoft Entra 應用程式 Proxy 已部署，且具有非 KCD 應用程式的一般存取權。

  如需詳細資訊，請參閱 開始使用應用程式 Proxy。

• 已發佈的應用程式是以 Internet Information Services（IIS）和 Microsoft 的 Kerberos 實作為基礎。

• 伺服器和應用程式主機位於單一Microsoft Entra 網域中。

  如需跨網域和樹系案例的詳細資訊，請參閱 使用應用程式 Proxy 瞭解 Kerberos 限制委派的白皮書。

• 應用程式會在預先驗證功能已啟用的 Microsoft Entra 租用戶中發布。 用戶應該使用表單型驗證進行驗證。

  本文未涵蓋豐富的客戶端驗證案例。

考慮事項

下列清單描述 KCD 設定的基礎考慮，並搭配 Microsoft Entra 應用程式 Proxy 使用：

• 基本設定錯誤或一般錯誤會導致大部分的問題。 開始進行疑難解答之前，請先檢查 使用 KCD SSO 搭配應用程式 Proxy 中的所有必要條件。

• 連接器主機不僅限於只與特定的本地網站域控制器進行通訊。 檢查您使用的直流電（DC），因為它可能會變更。

• 跨域情境依賴於轉介機制，將連接器主機導向到可能位於局域網路邊界外的DC。 在這些情況下，同樣重要的是將流量傳送至負責管理其他相關網域的資料中心（DC）。 如果您未這麼做，委派會失敗。

• 由於核心遠端程序呼叫（RPC）流量干擾，應避免在連接器主機和域控制器（DC）之間使用主動入侵防禦系統（IPS）或入侵檢測系統（IDS）裝置。

• 在簡單情境中的測試委派。 您在案例中引進的變數越多，組態和疑難解答就越複雜。 若要節省時間，請將測試限制為單一連接器。 在問題解決之後新增更多連接器。

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

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

• 什麼是 KCD 問題？ 數個常見錯誤表示 KCD SSO 失敗。 問題的第一個跡象會出現在瀏覽器中。

  下列兩個螢幕快照都顯示 SSO 失敗的相同徵兆：拒絕使用者存取應用程式。

  此螢幕快照顯示了一個 KCD 配置錯誤的範例，其中不正確的 Kerberos 限制委派錯誤已被標示出來。

  

疑難排解

您可以在三個階段中針對 KCD 問題進行疑難解答。 依照下列順序檢查 KCD 程式的這些部份：

• 用戶端預先驗證
• 委派服務
• 目標應用程式

用戶端預先驗證

用戶端預先驗證 是指透過瀏覽器在應用程式中驗證的外部使用者。 必須具備預先驗證至 Microsoft Entra ID 的能力，才能使 KCD SSO 正常運作。

先測試客戶端預先驗證，並解決任何問題。 預先驗證階段與 KCD 或已發佈的應用程式無關。 藉由檢查目標帳戶是否存在於 Microsoft Entra ID 中，即可輕鬆更正任何差異。 請檢查應用程式是否無法使用或被封鎖。 瀏覽器中的錯誤回應通常足以說明原因。

委派服務

Kerberos 委派服務是專用網連接器，可從 Kerberos 密鑰發佈中心 （KDC） 取得 Kerberos 服務票證。 應用程式用戶會透過票證向應用程式進行驗證。

用戶端與 Azure 前端之間的外部通訊不會影響限制委派。 這些通訊只會確保 KCD 能夠運作。 應用程式 Proxy 服務會獲得可取得 Kerberos 票證的有效使用者標識碼。 如果沒有此標識碼，KCD 就無法發生，SSO 會失敗。

瀏覽器錯誤訊息提供登入失敗原因的實用資訊。 記錄TransactionID和Timestamp的值，以回應應用程式登入。 此資訊有助於將行為與應用程式 Proxy 事件記錄檔中顯示的事件相互關聯。

事件記錄檔中的對應專案是事件標識碼 13019 或 12027。 若要檢視連接器事件記錄檔，請移至 [應用程式和服務記錄]>>>>。

若要針對限制委派問題進行疑難解答：

1. 在應用程式地址的內部域名系統 (DNS) 中，使用 A 記錄，而不是 CNAME 記錄。
2. 確認連接器主機已配置許可權，以委派給目標帳戶的服務主體名稱（SPN）。 確認已選取 [使用任何驗證通訊協定 ]。 如需詳細資訊，請參閱 SSO 設定。
3. 確認只有一個SPN實例存在於 Microsoft Entra ID 中。 若要確認單一 SPN，請在任何網域成員主機上的命令提示字元中執行 setspn -x。
4. 檢查是否強制執行限制 所發行 Kerberos 令牌大小上限的 網域原則。 如果令牌大小超過設定最大值，原則會停止連接器取得令牌。
5. 執行網路追蹤來擷取連接器主機與網域 KCD 之間的交換，是取得問題詳細數據的下一個最佳步驟。 如需詳細資訊，您可以檢閱深入的白皮書《Microsoft Entra 應用程式 Proxy 疑難解答》。

如果票證正常運作，記錄可能會顯示指出驗證失敗的事件，因為應用程式傳回 401 錯誤。 此事件表示目標應用程式拒絕票證。 移至疑難解答的下一個階段。

應用程式

目標應用程式會處理連接器所提供的 Kerberos 票證。 在這個階段，連接器會在後端的第一個應用程式請求中包含 Kerberos 服務票證作為標頭。

若要針對應用程式問題進行疑難解答：

1. 確定應用程式可供存取。 使用 Azure 入口網站中定義的內部 URL，直接從連接器主機上的瀏覽器登入。 如果登入成功，即可存取應用程式。

2. 檢查瀏覽器和應用程式是否使用 Kerberos 進行驗證。 從連接器主機，使用 Internet Explorer 的 DevTools （按 F12） 或 Fiddler ，透過內部 URL 存取應用程式。 在應用程式的回應中，尋找網頁授權標頭中的「Negotiate」或「Kerberos」。

   應用程式的瀏覽器回應包含一個開頭為YII的 Kerberos Blob，以確認 Kerberos 正在執行。 相反地，來自 Microsoft NT LAN Manager （NTLM） 的回應一律以 TlRMTVNTUAAB開頭。 從Base64解碼後，此回應顯示為NTLM安全性支援提供者（NTLMSSP）。 如果 Blob 開頭為 TlRMTVNTUAAB，則無法使用 Kerberos。 如果沒有，則 Kerberos 可能可用。

   注意

   如果您使用 Fiddler，則必須暫時停用 IIS 中應用程式組態上的擴充保護。

   

   此螢幕快照中的 Blob 不會以 TIRMTVNTUAAB開頭。 因此，在此範例中，可以使用 Kerberos，且 Kerberos Blob 不會以 YII開頭。

3. 在 IIS 網站上，暫時從提供者清單中移除 NTLM。 直接從連接器主機上的 Internet Explorer 存取應用程式。 NTLM 不再位於提供者清單中，因此您只能使用 Kerberos 存取應用程式。 如果存取失敗，則會指出應用程式組態的問題。 應用程式不會處理 Kerberos 驗證。

4. 如果 Kerberos 無法使用，請檢查 IIS 中的應用程式驗證設定。 請確定 交涉 列在頂端，NTLM 就在其下方。 如果您看到 Not Negotiate、Kerberos 或 Negotiate，或 PKU2U，請確保只有在 Kerberos 功能正常時才繼續。

   

5. 使用 Kerberos 和 NTLM，在入口網站中暫時停用應用程式的預先驗證。 嘗試使用外部 URL 在瀏覽器中存取應用程式。 系統會提示您進行驗證。 使用您在上一個步驟中使用的相同帳戶。 如果您無法驗證並登入，後端應用程式發生問題，而不是 KCD。

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

   Microsoft Entra private network connector can't authenticate the user because the backend server responds to Kerberos authentication attempts with an HTTP 401 error.

   

7. 檢查 IIS 應用程式。 請確定已設定的應用程式集區和 SPN 已設定為使用 Microsoft Entra 識別碼中的相同帳戶。 在 IIS 中，移至資料夾，如下列螢幕快照所示：

   

   檢查身分識別，然後確定此帳戶已使用SPN進行設定。 在命令提示字元中，例如，執行 setspn –q http/spn.contoso.com。

   

8. 在入口網站中，根據應用程式設定檢查定義的SPN。 請確定應用程式的應用程式集區使用針對目標Microsoft Entra 帳戶所設定的相同SPN。

9. 在 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))}
   

10. 如果已啟用核心模式，Kerberos 作業會改善。 但是，要求服務的票證也必須使用計算機帳戶來解密。 此帳戶也稱為 本機系統。 將此值設定為 True，當應用程式託管於伺服器陣列中的多個伺服器時，使 KCD 失效。

11. 作為另一項檢查，請停用擴充保護功能。 在某些測試案例中，擴充保護在特定組態中啟用時會導致 KCD 發生中斷。 在這些情況下，應用程式會發佈為默認網站的子資料夾。 此應用程式僅針對匿名驗證進行設定。 所有對話框都處於非使用中狀態，沒有可用的選取範圍，這表示子物件不會繼承任何使用中的設定。 建議您進行測試，但如果可能，請不要忘記將此值恢復為 啟用 。

    此額外的檢查可引導您使用已發佈的應用程式。 您可以產生更多設定為委派任務的連接器。 如需詳細資訊，請參閱深入技術指南 Microsoft Entra 應用程式 Proxy 疑難解答。

如果您仍然無法解決應用程式驗證問題，請直接在入口網站中建立支援票證。

其他案例

Microsoft Entra 應用程式 Proxy 先要求 Kerberos 票證，再將要求傳送給應用程式。 某些應用程式不支援這個驗證方法。 這些應用程式會設定為回應更傳統的驗證步驟。 第一個要求是匿名的，可讓應用程式透過 401 錯誤回應其支援的驗證類型。 您可以依照 SSO Kerberos 限制委派中所述的步驟，以完成這種類型的 Kerberos 協商設定。

在應用程式分層時，通常會使用多階驗證。 這些層包括後端和前端。 這兩層都需要驗證。 例如，您可以使用 SQL Server Reporting Services 建立階層式應用程式。 如需詳細資訊，請參閱 如何設定 Web 註冊 Proxy 頁面的 Kerberos 限制委派。

相關內容

• 在受控網域上設定 KCD