摘要
CVE-2022-21920的保護包含在 2022 年 1 月 11 日更新Windows更新Windows更新。 這些更新包含改良的邏輯，可偵測使用 Microsoft Negotiate 驗證通訊協定時，3 部分服務主體 名稱 的降級攻擊。
本文提供 Kerberos 驗證失敗時提供指引。
詳細資訊
安裝 2022 年 1 月 11 Windows更新及更新Windows可能會導致 3 部分 SPNs 的驗證失敗，而 Kerberos 驗證失敗。 針對這些環境，3 部分 SPNs 的 Kerberos 驗證可能一段時間沒有運作。 您可能會在用戶端系統上看到Windows事件，協助分類。
|
LSA 事件 40970 螢幕擷取畫面，找出 Microsoft 測試環境中特定 SPN 的 NTLM 後背。 |
LSA 事件 40970 文字版本 |
|
|
當與 3 部分 SPN 聯繫時，安全性系統偵測到降級嘗試 <SPN 名稱> 錯誤碼為「伺服器Windows上的SAM 資料庫沒有工作站信任關係的電腦帳戶， (0x0000018b) 」驗證遭到拒絕。 |
[動作]
Microsoft 建議您針對 3 部分 SPN 的 Kerberos 驗證失敗的原因進行分類。 Kerberos 驗證失敗的一些常見原因包括：
-
用來做為驗證目標的 SPN 格式不正確。 詳細資訊，請參閱唯一 SPNs 的名稱格式。
附註: 應用程式和 API 對於代表其服務之合法 SPN 的定義可能更嚴格或不同。
合法 SPN 的範例
HTTP/webserver
Host/machine2.contoso.com
Ldap/machine1.contoso.com/contoso.com
Service/machine1：10100
可能格式錯誤的 SPNs 範例SPN
原因
主機/主機/電腦1
主機/主機很可能是錯誤，因為「主機」通常是服務類別，而不是電腦名稱稱。 合法 SPN 可能是主機/電腦1。
Ldap/machine/contoso.com：10100
埠可以在主機名稱 ("machine") 上指定，而不是在服務實例名稱上指定。 合法 SPN 可能是「ldap/machine：10100/contoso.com」
Ldap/dc-a/DC=CONTOSO，DC=COM
某些 API 預期會提供 DNS 名稱，而非 FQDN。 例如， DsBindA 函數 (ntdsapi.h) 預期會以 DNS 名稱傳遞。 如果傳遞 FQDN，可能會導致 SPN 格式錯誤。
合法的 SPN 可能是「ldap/dc-a/contoso.com」若要解決這些問題，請考慮使用正確的 SPN，或將格式不正確的 SPN 註冊到正確的服務帳戶。
-
用來做為驗證目標的 SPN 不存在。 若要解決此問題，請考慮將 SPN 註冊到正確的服務帳戶。
-
Windows用戶端電腦沒有網網域控制站的視線 (例如 DCs 離線、無法在 DNS 中發現，或 KDC 埠的存取會) 。
-
您可能會在 NetBIOS 名稱無法使用的情況下使用 NetBIOS 名稱。 例如，從未加入網域的機器存取網域資源，NetBIOS 名稱解析會停用或無法工作。
Microsoft 建議使用使用者主體名稱 ( UPN) 功能變數名稱 系統 (DNS) 名稱，而不是 NetBIOS 名稱。
註冊 SPNs
根據應用程式與環境的設定，SPNs 可能會設定在服務帳戶的服務主體 名稱屬性或位於 Active Directory 網域的電腦帳戶上，Kerberos 用戶端正嘗試建立 Kerberos 連接。 若要讓 Kerberos 驗證能夠正確工作，目標 SPN 必須有效。
請參閱部署檔或每個特定應用程式的支援提供者，以瞭解如何啟用 Kerberos 驗證。 某些應用程式安裝程式或應用程式會自動註冊 SPNs。 開發人員和系統管理員都有不同的選項可以註冊 SPN：
-
若要手動註冊服務實例的 SPNs，請參閱 集PN。
-
若要以程式化方式註冊服務實例的 SPNs，請參閱服務如何註冊 其 SPNs ，說明如何：
-
打電話給DsGetSpn函數，為服務實例建立一或多個唯一的 SPNs。 詳細資訊，請參閱唯一 SPNs 的名稱格式。
-
打電話給DsWriteAccountSpn函數，以註冊服務登入帳戶上的名稱。
-
已知問題
目前此更新沒有已知問題。
