針對 Internet Explorer 中的 Kerberos 失敗進行疑難解答

本文可協助您在存取設定為在 Internet Explorer 中使用 Kerberos 驗證的網站時，隔離並修正各種錯誤的原因。 潛在問題的數目幾乎和可用來解決這些問題的工具數目一樣大。

Kerberos 失敗時的常見徵兆

您嘗試存取已設定 Windows 整合式驗證且預期使用 Kerberos 驗證通訊協議的網站。 在此情況下，您的瀏覽器會立即提示您輸入認證，如下所示：

雖然您輸入有效的使用者名稱和密碼，但系統會再次提示您 (三個提示總計) 。 然後，您會看到一個畫面，指出不允許您存取所需的資源。 畫面會顯示類似下列錯誤的 HTTP 401 狀態代碼：

未授權
HTTP 錯誤 401。 要求的資源需要用戶驗證。

在 Microsoft Internet Information Services (IIS) 伺服器上，網站記錄包含以 401.2 狀態代碼結尾的要求，例如下列記錄：

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken  
DateTime IP GET /whoami.aspx - 80 – IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 2 5 1270  
DateTime IP GET /whoami.aspx - 80 - IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 2 5 8

或者，畫面會顯示 401.1 狀態代碼，例如下列記錄：

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken  
DateTime IP GET /whoami.aspx - 80 - IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 2 5 105  
DateTime IP GET /whoami.aspx - 80 - IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 1 2148074245 18

判斷是否使用 Kerberos

當您針對 Kerberos 驗證失敗進行疑難解答時，建議您將設定簡化為最低限度。 也就是說，一個用戶端、一部伺服器，以及一個在預設埠上執行的 IIS 月臺。 此外，您可以遵循一些基本的疑難解答步驟。 例如，使用測試頁面來驗證所使用的驗證方法。 如果您使用 ASP.NET，您可以建立此 ASP.NET 驗證測試頁面。

如果您使用傳統 ASP，您可以使用下列Testkerb.asp頁面：

<%
    authType=UCase(Request.ServerVariables("AUTH_TYPE"))
    authHeader=Request.ServerVariables("HTTP_AUTHORIZATION")
    response.write " Authentication Method : " & authType & "<BR>"
    LenAuthHeader = len(authHeader)
    response.write " Protocol : "
    if Len(authType ) =0 then response.write " Anonymous" else if authType<>"NEGOTIATE" then response.write authType else if LenAuthHeader>1000 then response.write "Kerberos" else response.write  "NTLM"
%>

您也可以使用下列工具來判斷是否使用 Kerberos：

• 琴師
• HttpWatch
• 網路監視器
• 瀏覽器中的開發人員工具

如需如何產生這類追蹤的詳細資訊，請參閱 客戶端追蹤。

使用 Kerberos 時，用戶端傳送的要求會很大， (超過 2,000 個字節) ，因為 HTTP_AUTHORIZATION 標頭包含 Kerberos 票證。 下列要求適用於使用 Kerberos 型 Windows 驗證來驗證傳入用戶的頁面。 GET 要求的大小超過 4,000 個字節。

如果使用NTLM交握，要求會小很多。 下列用戶端擷取會顯示NTLM驗證要求。 GET 要求 (小於 1,400 個字節) 。

判斷 Kerberos 驗證失敗之後，請依指定的順序檢查下列每個專案。

檢查 Kerberos 驗證是否失敗的事項

下列各節說明可用來檢查 Kerberos 驗證是否失敗的專案。

用戶端和伺服器是否位於相同的網域中

使用 Kerberos 需要網域，因為 Kerberos 票證是由域控制器 (DC) 傳遞。 在下列情況下，也可以使用進階案例：

• 客戶端和伺服器不在相同的網域中，而是位於相同樹系的兩個網域中。
• 用戶端和伺服器位於兩個不同的樹系中。

雖然 Kerberos 委派過去是用來運作一節，但在我的兩個樹系之間失敗的原因 一節中會討論這些可能的案例。

IIS 是否設定為使用整合式驗證

已在 Internet Explorer 中啟用整合式驗證

所使用的 URL 是否解析為可傳送認證的安全性區域

請一律針對下列網站執行此檢查：

• 與瀏覽器的近端內部網路區域相符的網站。
• [信任的網站] 區域中的網站。

您可以檢查瀏覽器決定要包含網站的區域。 若要這樣做，請開啟 Internet Explorer 的 [ 檔案 ] 選單，然後選取 [ 屬性]。 [ 屬性] 視窗會顯示瀏覽器決定要包含您要瀏覽之網站的區域。

您可以檢查包含網站的區域是否允許自動登入。 若要這樣做，請開啟 Internet Explorer 的 [ 因特網選項 ] 功能表，然後選取 [ 安全性] 索引 標籤。選取所需的區域之後，請選取 [自定義層級 ] 按鈕以顯示設定，並確定已選取 [自動登入 ]。 (一般而言，預設會針對內部網路和信任的網站區域) 開啟此功能。

IIS 伺服器是否設定為傳送 WWW-Authenticate：Negotiate 標頭

如果 IIS 未傳送此標頭，請使用 IIS 管理員主控台透過 NTAuthenticationProviders 組態屬性設定 Negotiate 標頭。 如需詳細資訊，請參閱 Windows 驗證提供者 <提供者>。 您可以透過 IIS 管理員中 Windows 驗證詳細資料的 提供者 設定來存取主控台。

用戶端和伺服器是否安裝在同一部計算機上

根據預設，此組態中不會啟用 Kerberos。 若要變更此行為，您必須設定 DisableLoopBackCheck 登錄機碼。 如需詳細資訊，請參閱 KB 926642。

用戶端是否可以取得 Kerberos 票證

您可以使用 Kerberos 清單 (KLIST) 工具來確認用戶端電腦可以取得指定服務主體名稱的 Kerberos 票證。 在此範例中，SPN) (服務主體名稱是 HTTP/web-server。

當 Kerberos 票證要求失敗時，不會使用 Kerberos 驗證。 可能會發生 NTLM 後援，因為 DC 不知道所要求的 SPN。 如果 DC 無法連線，則不會發生任何 NTLM 後援。

若要宣告SPN，請參閱下列文章：

當您設定裝載於 Internet Information Services 上的 Web 應用程式時，如何使用 SPN。

網頁伺服器是否使用預設 (80) 以外的埠

根據預設，Internet Explorer 不會在 SPN 中包含用來要求 Kerberos 票證的埠號碼資訊。 如果您使用 IIS 在不同的埠和身分識別下裝載多個月臺，可能會發生問題。 在此設定中，即使所有SPN都已在Active Directory 中正確宣告，Kerberos驗證也只能用於特定月臺。 若要修正此問題，您必須設定登錄 FEATURE_INCLUDE_PORT_IN_SPN_KB908209 值。 (如需如何宣告密鑰的資訊，請參閱 Internet Explorer 功能密鑰 一節。) 此設定會強制 Internet Explorer 在用來要求 Kerberos 票證的 SPN 中包含埠號碼。

Internet Explorer 是否使用預期的 SPN

如果網站是使用別名名稱 (CNAME) 來存取，Internet Explorer 會先使用 DNS 解析將別名名稱解析為計算機名稱， (ANAME) 。 計算機名稱接著會用來建置SPN並要求 Kerberos 票證。 即使在 Internet Explorer 網址列中輸入的 URL 是 http://MYWEBSITE，如果 MYWEBSITE 是 MYSERVER ( (ANAME) 的 CNAME) 別名，Internet Explorer 仍會要求 HTTP/MYSERVER 的 SPN。 您可以使用 FEATURE_USE_CNAME_FOR_SPN_KB911149 登錄機碼來變更此行為。 (如需如何宣告密鑰的資訊，請參閱 Internet Explorer 功能金鑰 。)

網路監視器追蹤是檢查與 Kerberos 票證相關聯之 SPN 的好方法，如下列範例所示：

- Http: Request, GET /whoami.aspx , Using GSS-API Authorization
    Command: GET
  - URI: /whoami.aspx
     Location: /whoami.aspx
    ProtocolVersion: HTTP/1.1
    Accept:  image/gif, image/jpeg, image/pjpeg, application/x-ms-application, application/xaml+xml, application/x-ms-xbap, */*
    Accept-Language:  en-US,en;q=0.5
    UserAgent:  Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 10.0; WOW64; Trident/7.0; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 3.5.30729)
    Accept-Encoding:  gzip, deflate
    Host:  web-server
    Connection:  Keep-Alive
  - Authorization: Negotiate
   - Authorization:  Negotiate YIILcAYGKwYBBQUCoIILZDCCC2CgMDAuBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICHgYKKwYBBAGCNwICCqKCCyoEggsmYIILIgYJKoZIhvcSAQICAQBuggsRMIILDaADAgEFoQMCAQ6iBwMFACAAAACjggRtYYIEaTCCBGWgAwIBBaEOGwxPREVTU1kuTE9DQUyiKjAooAMCAQKhITAfGwRIVFRQG
      WhiteSpace:  
    - NegotiateAuthorization:
       Scheme: Negotiate
     - GssAPI: 0x1
      - InitialContextToken:
       + ApplicationHeader:
       + ThisMech: SpnegoToken (1.3.6.1.5.5.2)
       - InnerContextToken: 0x1
        - SpnegoToken: 0x1
         + ChoiceTag:
         - NegTokenInit:
          + SequenceHeader:
          + Tag0:
          + MechTypes: Prefer MsKerberosToken (1.2.840.48018.1.2.2)
          + Tag2:
          + OctetStringHeader:
          - MechToken: 0x1
           - MsKerberosToken: 0x1
            - KerberosInitToken:
             + ApplicationHeader:
             + ThisMech: KerberosToken (1.2.840.113554.1.2.2)
             - InnerContextToken: 0x1
              - KerberosToken: 0x1
                 TokId: Krb5ApReq (0x100)
               - ApReq: KRB_AP_REQ (14)
                + ApplicationTag:
                + SequenceHeader:
                + Tag0:
                + PvNo: 5
                + Tag1:
                + MsgType: KRB_AP_REQ (14)
                + Tag2: 0x1
                + ApOptions:
                + Tag3:
                - Ticket: Realm: ODESSY.LOCAL, Sname: HTTP/web-server.odessy.local
                 + ApplicationTag:
                 + SequenceHeader:
                 + Tag0:
                 + TktVno: 5
                 + Tag1:
                 + Realm: ODESSY.LOCAL
                 + Tag2: 0x1
                 + Sname: HTTP/web-server.odessy.local
                 + Tag3: 0x1
                 + EncPart:
                + Tag4:

應用程式集區身分識別是否符合與SPN相關聯的帳戶

當 Kerberos 票證從 Internet Explorer 傳送至 IIS 伺服器時，會使用私鑰加密票證。 私鑰是密碼的哈希，用於與 SPN 相關聯的用戶帳戶。 因此，只有在此帳戶下執行的應用程式可以譯碼票證。

下列程式是 Kerberos 驗證演算法的摘要：

1. Internet Explorer 會使用輸入到網址列中的 URL 來判斷 SPN。

2. SPN 會透過安全性支援提供者介面 (SSPI) API (InitializeSecurityContext) 傳遞至負責 Windows 安全性 (本地安全機構子系統服務 (LSASS) 程式) 的系統元件。 在這個階段，您可以看到 Internet Explorer 程式代碼未實作任何程式代碼來建構 Kerberos 票證。 Internet Explorer 只會呼叫 SSPI API。

3. LSASS 會使用傳入的SPN，向 DC 要求 Kerberos 票證。 如果 DC 可以提供已知 SPN) (要求，則會建立 Kerberos 票證。 然後，它會使用從與SPN相關聯之帳戶的用戶帳戶密碼哈希建構的密鑰來加密票證。 LSASS 接著會將票證傳送至用戶端。 就 Internet Explorer 而言，票證是不透明的 Blob。

4. Internet Explorer 會將 LSASS 所提供的 Kerberos 票證封裝在標頭中 Authorization: Negotiate ，然後將票證傳送至 IIS 伺服器。

5. IIS 會處理要求，並使用指定的主機標頭，將它路由傳送至正確的應用程式集區。

6. 應用程式集區會嘗試使用 SSPI/LSASS API 並遵循下列條件來解密票證：

   • 如果票證可以解密，Kerberos 驗證就會成功。 與票證相關聯的所有服務 (模擬、如果票證允許，則委派等) 可用。

   • 如果無法解密票證，則會傳回 Kerberos 錯誤 (KRB_AP_ERR_MODIFIED) 。 此錯誤是一般錯誤，表示票證在傳輸期間以某種方式變更。 因此，票證無法解密。 此錯誤也會記錄在 Windows 事件記錄檔中。

如果您未明確宣告 SPN，Kerberos 驗證只能在下列其中一個應用程式集區身分識別下運作：

• 網路服務
• ApplicationPoolIdentity
• 另一個系統帳戶，例如 LOCALSYSTEM 或 LOCALSERVICE

但不建議使用這些身分識別，因為它們是安全性風險。 在此情況下，Kerberos 票證是使用在 Active Directory 中建立的預設 SPN 來建置，在此情況下，當計算機 (時，IIS 在) 上執行的伺服器會新增至網域。 此預設SPN會與電腦帳戶相關聯。 在 IIS 下，計算機帳戶會對應至網路服務或 ApplicationPoolIdentity。

如果您的應用程式集區必須使用所列身分識別以外的身分識別，請使用 SETSPN) 宣告SPN (。 然後將它與用於應用程式集區身分識別的帳戶產生關聯。 常見的錯誤是建立具有不同帳戶的類似SPN。 例如：

• SETSPN http/mywebsite UserAppPool1
• SETSPN http/mywebsite UserAppPool2

此設定將無法運作，因為沒有確定性的方式可得知 HTTP/mywebsite SPN 的 Kerberos 票證是否會使用 UserAppPool1 或 UserAppPool2 密碼加密。 此設定通常會產生KRB_AP_ERR_MODIFIED錯誤。 若要判斷您是否處於這個不正確的重複 SPN 案例中，請使用下列文章中記載的工具：

為什麼您在 AD 2012 R2 和 AD 2016 中仍然可以有重複的 SPN

從 Windows Server 2008 開始，您也可以使用適用於 Windows 的 SETSPN 更新版本，以便在您為目標帳戶宣告新的 SPN 時，使用 setspn –X 命令來偵測重複的 SPN。 如需詳細資訊，請參閱 Setspn。

我們也建議您檢閱下列文章：

• Kerberos 驗證問題 - 服務主體名稱 (SPN) 問題 - 第 1 部分

• Kerberos 驗證問題 - 服務主體名稱 (SPN) 問題 - 第 2 部分

• Kerberos 驗證問題 - 服務主體名稱 (SPN) 問題 - 第 3 部分

Kerberos 驗證在 IIS 7 和更新版本中是否失敗，即使它在 IIS 6 中運作

核心模式驗證是在 IIS 7 中引進的功能。 它提供下列優點：

• 效能會提高，因為不再進行核心模式到使用者模式的轉換。
• Kerberos 票證譯碼是使用電腦帳戶而非應用程式集區身分識別來進行。 這項變更可讓您在不同的身分識別下執行多個應用程式集區，而不需要宣告SPN。

為什麼委派會失敗，雖然 Kerberos 驗證可運作

在此案例中，請檢查下列專案：

• 用於 URL 的 Internet Explorer 區域。 只有內部網路和信任的網站區域才允許 Kerberos 委派。 (換句話說，Internet Explorer 只有在判斷的區域是內部網路或信任的網站時，才會在呼叫 InitializeSecurityContext 時設定ISC_REQ_DELEGATE旗標。)

• 裝載您網站之 IIS 應用程式集區的使用者帳戶必須在 Active Directory 內設定 [信任的委派 ] 旗標。

如果委派仍然失敗，請考慮使用適用於 IIS 的 Kerberos Configuration Manager。 此工具可讓您診斷和修正 Kerberos 驗證的 IIS 組態，以及目標帳戶上相關聯 SPN 的 IIS 設定。 如需詳細資訊，請 參閱 README.md。 您可以從 這裡下載此工具。

為什麼我在使用 Kerberos 驗證時會收到不正確的效能

Kerberos 是舊版 Windows Server 中的要求型驗證通訊協定，例如 Windows Server 2008 SP2 和 Windows Server 2008 R2。 這表示客戶端必須傳送 Kerberos 票證 (，這可以是相當大型的 Blob，) 每個對伺服器提出的要求。 這與依賴NTLM的驗證方法相反。 根據預設，NTLM 是以會話為基礎。 這表示當瀏覽器開啟伺服器的 TCP 連線時，只會驗證一個要求。 相同 TCP 連線上的每個後續要求將不再需要驗證，即可接受要求。 在較新版本的 IIS 中，從 Windows 2012 R2 開始，Kerberos 也是以會話為基礎。 只有新 TCP 連線的第一個要求必須由伺服器驗證。 後續要求不需要包含 Kerberos 票證。

如果您在 IIS 7 和更新版本下執行，您可以使用 authPersistNonNTLM 屬性來變更此行為。 如果屬性設定為 true，Kerberos 會變成以會話為基礎。 否則，它會以要求為基礎。 其效能會變差，因為我們每次都必須包含較大的數據量以傳送至伺服器。 如需詳細資訊，請參閱以 要求為基礎與會話型 Kerberos 驗證 (或 AuthPersistNonNTLM 參數) 。

為什麼我的兩個樹系之間的 Kerberos 委派失敗，雖然它過去可以運作

請試想下列案例：

• 您應用程式的使用者位於樹系 A 內的網域中。
• 您的應用程式位於樹系 B 內的網域中。
• 樹系之間有信任關係。

在此案例中，Kerberos 委派可能會停止運作，即使它先前用來運作，而且您尚未對樹系或網域進行任何變更。 Kerberos 驗證在此案例中仍然有效。 只有委派失敗。

此問題可能是因為 Microsoft 在 2019 年 3 月和 2019 年 7 月發行的 Windows Server 安全性更新所導致。 這些更新已停用不受限制的 Kerberos 委派， (能夠將 Kerberos 令牌從應用程式委派給後端服務，) 跨樹系界限來委派所有新的和現有的信任。 如需詳細資訊，請參閱 匯報 Windows Server 中傳入信任之間的 TGT 委派。

Internet Explorer 功能金鑰

這些機碼是開啟或關閉瀏覽器某些功能的登錄機碼。 金鑰位於下列登入位置：

• HKEY_USERS\<UserSID>\Software\Microsoft\Internet Explorer\Main\FeatureControl – 如果定義於使用者層級
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\ - 如果是在計算機層級定義，則為

應根據您要開啟或關閉功能，在其中一個位置建立功能密鑰：

• 適用於電腦上的所有使用者
• 僅適用於特定帳戶

這些金鑰應該建立在各自的路徑下。 在機碼內，應該宣告名為 iexplorer.exe 的 DWORD 值。 每個索引鍵的預設值應該是 true 或 false，視功能的所需設定而定。 根據預設，功能索引鍵 FEATURE_INCLUDE_PORT_IN_SPN_KB908209 和 FEATURE_USE_CNAME_FOR_SPN_KB911149的值都是 false。 為了完整起見，以下是範例導出登錄，方法是將功能密鑰在 Kerberos 票證中包含埠號碼設為 true：

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_INCLUDE_PORT_IN_SPN_KB908209]
"iexplore.exe"=dword:00000001

其他相關資訊

Windows 整合式驗證疑難解答的診斷頁面