我們有幾個使用 Windows 驗證的 IIS 託管網站。我們的一些使用者可以登入其中一個站點，但在另一個站點中會遇到永無止境的身份驗證質詢（第二個站點在第一個站點的 iframe 中使用）。我們發現無法登入的使用者正在使用 Kerberos 驗證（其他 NTLM）。所有網站都使用相同的授權設定（useAppPoolCredentials 設定為 true）。因此，使用者可以訪問一個站點，但無法訪問具有相同設定的第二個站點。應用程式集區標識使用者位於管理員群組和 IIS_IUSRS 群組。我還嘗試使用網域使用者帳戶從虛擬機器登入站點，但由於 Kerberos 的原因，得到了相同的永無止境的身份驗證提示。我讀過 Chiranth Ramaswamy 關於 IIS 身份驗證的文章，但遺憾的是找不到問題的解決方案。有什麼辦法可以解決這個問題嗎？
編輯：我們還有第二台具有相同網站和設定的伺服器。
EDIT2：我發現如果我使用相同的網域使用者帳戶，我可以登入不在登入中寫入網域名稱。因此「UserName」有效，而「DomainName\UserName」則無效
答案1
在那裡進行故障排除相當不錯，更多詳細資訊會很有幫助，包括如何設定 Curb、還有哪些網站以及正在使用的 URL。
簡而言之：我認為 Kerb 已經崩潰了。為了使其正常工作，您可以使用 IP 位址而不是名稱。 （Kerb 僅在您使用名稱而不是 IP 位址時才起作用）。
我懷疑您沒有在應用程式集區帳戶的上下文中解碼票證（順便說一下，該帳戶幾乎永遠不應該是管理員）。
這可能是因為 SPN 重複，或者 Curb 的某些其他方面被破壞。
也可能是用戶端瀏覽器設定（例如「啟用整合 Windows 驗證」）與 PAC 腳本和/或區域設定。
所以！購物清單：
如果使用 IE，請檢查網站載入到的區域。
如果使用 IE，請檢查啟用整合 Windows 設定。
重新啟動損壞的用戶端（或至少
klist purge），然後從用戶端取得失敗連線的 netmon 或wireshark 追蹤。這可能會識別一些 KDC 回應問題，即傳回的 Kerberos 錯誤，這提供了有關可能破壞 Curb 的線索如果您使用 useAppPoolCredentials，那麼您很可能使用過 SetSPN。檢查涉及網站名稱的所有 SPN 的重複項。
最後，如果您不使用委派，請考慮刪除 useAppPoolCredentials，因為預設情況下，如果沒有 SPN 覆蓋，系統帳戶將解碼所有應用程式集區的票證。
答案2
重新啟動伺服器後，我發現 useApplicationCredentials 回傳為 false。我將其更改為 true 並重新啟動 IIS。之後就不會出現這個問題了。但我不確定這是否是巧合。我們在另一台伺服器上也遇到了同樣的問題。 4 台機器具有相同的 IIS 設定。 2 無法透過 Kerberos 正常運作，而 2 可以。沒有為其中任何一個配置 SPN。此外，兩個有效的 useApplicationCredentials 中都有 false。
如果不是，我將嘗試相同的方法重新啟動將 useApplicationCredentials 設為 true，然後進行 iisreset。但我很確定這不是問題。如果未設定 SPN，我無法理解為什麼 Kerberos 可以工作