SMB 簽章與 LDAP 通道繫結 ── 在實務中補齊 NTLM 對策的「剩餘一半」

「已經開始稽核 NTLM 了,直打 IP 位址的地方也在修正中。那麼,在把所有相依性全部消除之前,該如何防備中繼攻擊？」──在發布上一篇文章「NTLM 廢除會讓業務應用程式停擺嗎」之後,收到最多的就是這個問題。

答案就是本文要探討的SMB 簽章與LDAP 簽章・LDAP 通道繫結。這兩者都不是「停用 NTLM」的措施,而是「即使 NTLM 仍然存在,也不讓竊取的驗證資訊被橫向轉發(中繼攻擊)得逞」的防禦手段。其中一方的 SMB 簽章,在 Windows 11 24H2 / Windows Server 2025 上的預設值已經實際改變,即使什麼都不做,也會隨著作業系統更新一起到來。另一方的 LDAP 簽章・通道繫結,預設值本身並未改變,只要管理員不動手收緊,就會一直維持寬鬆的狀態。也就是說,SMB 是「要提前因應,還是等 OS 更新出事之後再處理」的問題,而 LDAP 則是「自己要在什麼時候收緊」的問題。

本文是 NTLM 系列的第三篇。NTLM 的稽核步驟整理於第一篇,協定的運作機制則整理於第二篇。

1. 先講結論

• SMB 簽章是為所有 SMB 訊息附加竄改偵測簽章的機制。簽章中包含整個訊息的雜湊值,以及傳送端與接收端的身分,可用來防範中繼攻擊與冒充攻擊。¹
• 預設值已經改變了。Windows 11 版本 24H2 的 Enterprise、Pro、Education 版本,預設傳送與接收兩端都必須簽章;Windows Server 2025 預設僅傳送端必須簽章(Home 版本則兩端皆非必須)。²
• 簽章必須化與訪客存取停用是配套進行的。不支援簽章的 NAS,或以訪客連線為前提的機器,會在作業系統更新之際發生連線錯誤。錯誤碼為 0xc000a000(STATUS_INVALID_SIGNATURE)或訪客封鎖訊息(4.3 節)。²
• LDAP 簽章是讓網域控制站能夠拒絕「不要求簽章的 SASL 繫結」與「明文的簡單繫結」的機制。因為未簽章的 LDAP 流量容易受到重播攻擊與中間人攻擊的威脅。³
• LDAP 通道繫結是將 LDAPS(SSL/TLS)上的 Windows 驗證(SASL 繫結)綁定到 TLS 通道的機制。用於這項綁定的數值稱為通道繫結權杖(CBT)。不具備 CBT 的簡單繫結不屬於驗證對象(第 6 章)。可透過登錄值 LdapEnforceChannelBinding(0/1/2)或群組原則來控制。⁴
• 兩者都以「判讀稽核事件 → 修正連線來源 → 切換為強制」三個階段推進。LDAP 簽章可透過事件 2887、2889,通道繫結可透過事件 3039、3040 與稽核事件 3074、3075 來鎖定連線來源(第 5、6 章)。³⁴
• 重要的前提是,這些更新不會擅自改變預設值。Microsoft 針對 2020 年 3 月以後的一系列 LDAP 更新明確表示「不會變更 LDAP 簽章・通道繫結的預設原則」。收緊設定是管理員的工作。⁴

2. 為什麼需要簽章 ── 中繼攻擊的「剩餘一半」

正如第二篇文章中所寫,NTLM 根本的弱點在於缺乏相互驗證。用戶端無法驗證伺服器的身分,因此攻擊者可以「假冒真正的伺服器」讓用戶端進行驗證,再把收到的驗證回應原封不動地橫向轉發給真正的伺服器。這就是中繼攻擊,Microsoft 自己也明確指出 NTLM 及 NTLMv2 驗證對 SMB 中繼、中間人攻擊都很脆弱。⁵

只要完全停用 NTLM,這種攻擊就不會成立,但正如第一篇文章所述,盤點相依性並加以修正需要以數個月為單位的時間。在這段期間裡的防禦手段,就是簽章。

flowchart LR
    CL["用戶端"]
    AT["攻擊者<br/>偽裝伺服器"]
    SV["真正的伺服器"]

    CL -->|"① 驗證回應"| AT
    AT -->|"② 直接轉發"| SV
    SV -.->|"③ 若必須簽章:<br/>沒有工作階段金鑰的攻擊者<br/>無法產生正確簽章而失敗"| AT

圖1: 中繼攻擊與 SMB 簽章的關係

重點在於,簽章所用的金鑰(工作階段金鑰)是驗證的結果,只有用戶端與真正的伺服器才會持有。僅僅中繼了驗證回應的攻擊者並不持有工作階段金鑰,因此在簽章必須的環境中無法偽造後續的訊息。SMB 簽章封鎖對 SMB 的中繼,LDAP 簽章與通道繫結則分別封鎖對網域控制站 LDAP/LDAPS 的中繼。

還有一個實務上要注意的地方。簽章的效果並不獨立於驗證協定的選擇之外。由於工作階段金鑰源自密碼,若以 NTLMv2 而非 Kerberos 進行驗證,作為簽章基礎的金鑰就會變弱。Microsoft 也將使用 Kerberos、不以 IP 位址或 CNAME 連線共用資料夾,列為讓 SMB 簽章效果最大化的條件。¹ 這是因為以 IP 位址,或以未註冊對應 SPN 的別名連線時,使用的會是 NTLM 而非 Kerberos(若想繼續使用別名,SPN 的註冊方式在第一篇文章中有說明)。也就是說,降低 NTLM 相依性與簽章必須化並不是不同的措施,而是同一項措施的兩個輪子。

3. SMB 簽章 ── 運作機制,以及已經改變的預設值

3.1. 一分鐘搞懂運作機制

SMB 簽章使用工作階段金鑰與加密套件,為連線中流動的每一則訊息附加簽章。簽章會在 SMB 標頭中包含整則訊息的雜湊值,若途中遭到竄改,雜湊值就會不一致。由於雜湊值也包含傳送端與接收端的身分,因此也能偵測冒充行為。¹

演算法隨著世代不斷強化。SMB1 使用 MD5,SMB 2.02 改為 HMAC-SHA-256,SMB 3.0 改為 AES-CMAC,而 Windows Server 2022 與 Windows 11 更導入了以 AES-128-GMAC 為基礎的簽章加速。¹ 如果「簽章=變慢」的印象還停留在 SMB1 時代,值得先放下這個成見,重新實測一次。

設定要用「是否必須(Require)」來思考,而不是「啟用／停用」。在 SMB 2.x 以後,EnableSecuritySignature 設定會被忽略,唯一有意義的是 RequireSecuritySignature。而且只要用戶端或伺服器其中一方將簽章設為必須,該連線就會被簽章。只有在雙方都未設為必須時,連線才不會被簽章。¹

3.2. 預設值判斷表

這張表不需要全部讀完。請先確認貴公司端末與伺服器的作業系統與版本,只閱讀與自己相符的那一列即可。Edition(版本)與 Version(功能版本)可以在「設定 > 系統 > 關於」中確認(「Edition」會顯示 Pro / Home / Enterprise / Education 等,「Version」則會顯示 24H2 等資訊)。

上面三列是 Microsoft 文件中明確記載的預設值。² 最下面一列則是一直以來的行為,網域控制站會要求所有連線進來的對象使用 SMB 簽章。群組原則與登入指令碼的散發,一直都是以簽章為前提運作的。¹

只有 Home 版本不受這次預設值變更影響。由於傳送與接收都不會變成必須,即使更新到 24H2,Home 端末也不會因簽章必須化而發生連線錯誤(這並不保證未來不會變更,但至少不包含在 24H2 這個時間點的「收緊範圍」內)。² 反過來說,即使同樣是 24H2,不同版本的行為也會不同。在釐清「更新之後就連不上共用資料夾了」這類申告時,不能只看 Version,請優先確認 Edition。

這張表在實務上的意義是:更新到 Windows 11 24H2(Enterprise、Pro、Education)之後,該台電腦所發出的所有 SMB 連線都會變成必須簽章(Home 版本不在此列)。如果公司內部的檔案伺服器是 Windows,不會發生任何問題(因為 Windows 所有版本都支援簽章)。真正會出事的,是不支援簽章、或已停用簽章的第三方機器,也就是舊款 NAS、複合機的掃描存放目標設定、內嵌 Linux 的 Samba 之類的對象。

4. 將 SMB 簽章推進為「必須」的步驟

4.1. 確認目前狀態

# 用戶端(傳送)端的簽章要求
Get-SmbClientConfiguration | FL RequireSecuritySignature

# 伺服器(接收)端的簽章要求
Get-SmbServerConfiguration | FL RequireSecuritySignature

True 代表必須,False 代表非必須。² 若以群組原則管理,設定位置為 電腦設定\Windows 設定\安全性設定\本機原則\安全性選項 中的「Microsoft 網路用戶端:一律以數位方式簽署通訊」(用戶端)與「Microsoft 網路伺服器:一律以數位方式簽署通訊」(伺服器)。原則名稱中的「一律(always)」代表「必須」。¹

4.2. 先找出「無法簽章的對象」(稽核)

在 Windows 11 版本 24H2 以後,可以啟用用來偵測不支援簽章或加密的第三方用戶端・伺服器的稽核功能。¹

# 伺服器端: 偵測不支援簽章的用戶端
Set-SmbServerConfiguration -AuditClientDoesNotSupportSigning $true

# 用戶端: 偵測不支援簽章的伺服器
Set-SmbClientConfiguration -AuditServerDoesNotSupportSigning $true

以相同機制也能建立偵測不支援加密之對象的稽核(-AuditClientDoesNotSupportEncryption / -AuditServerDoesNotSupportEncryption),¹ 但那是為未來將 SMB 加密設為必須做準備,與簽章的路線圖是不同的軌道。支援簽章卻不支援加密的機器並不少見,因此請不要把加密的稽核事件混入簽章完成與否的判斷中。

記錄位置如下。¹

確認事件的步驟共有以下三個:

1. 以 eventvwr.msc 開啟事件檢視器,在左側樹狀目錄中開啟 事件檢視器 > 應用程式與服務記錄檔 > Microsoft > Windows > SMBClient > Audit(要查看伺服器端時,則是同一層級的 SMBServer > Audit)。
2. 在右側窗格選擇「篩選目前的記錄檔」,在「所有事件識別碼」欄位輸入 31998,31999(伺服器端則輸入 3021,3022)。
3. 開啟剩下的事件,即可看到不支援簽章之對象的相關資訊。將這些資訊逐一記錄到機器清單中。

若要用 PowerShell 一併擷取,做法如下。

# 用戶端: 偵測到不支援簽章之伺服器的稽核事件
Get-WinEvent -FilterHashtable @{ LogName='Microsoft-Windows-SMBClient/Audit'; Id=31998,31999 } -ErrorAction SilentlyContinue |
    Select-Object TimeCreated, Id, Message

# 伺服器端: 偵測到不支援簽章之用戶端的稽核事件
Get-WinEvent -FilterHashtable @{ LogName='Microsoft-Windows-SMBServer/Audit'; Id=3021,3022 } -ErrorAction SilentlyContinue |
    Select-Object TimeCreated, Id, Message

剛啟用稽核、還沒有任何記錄時,Get-WinEvent 會回傳找不到符合事件的錯誤(上面之所以加上 -ErrorAction SilentlyContinue,就是為了處理這種情況)。篩選條件的寫法整理於「使用 Get-WinEvent 有效率地調查事件記錄」。

在群組原則中,對應的設定位於 電腦設定\系統管理範本\網路 底下的 Lanman Server / Lanman Workstation 中的「Audit client does not support signing」等項目。¹ 第一篇文章中提到的稽核期間思路(持續執行到業務循環一輪為止),在這裡同樣適用。

4.3. 事先掌握事故模式

在簽章必須的環境中連線到無法簽章的對象時,會出現以下錯誤。²

0xc000a000
STATUS_INVALID_SIGNATURE
加密簽章無效。

另外還有一點容易被忽略,就是訪客存取。簽章必須化也伴隨著訪客存取的停用。連線到設定為免驗證(訪客)存取的 NAS 時,會出現如下的錯誤。²

因為您組織的安全性原則已封鎖未經驗證的訪客存取,
所以無法存取這個共用資料夾。

處理的優先順序很明確。首要做法是在機器端啟用 SMB 簽章,並改用認證資訊而非訪客身分驗證。雖然在用戶端執行 Set-SmbClientConfiguration -RequireSecuritySignature $false 可以規避簽章錯誤(0xc000a000)那一側的問題,但訪客封鎖是由簽章以外的另一項用戶端設定(禁止不安全的訪客登入)所造成,單純放寬簽章要求並不會解決這個問題。Microsoft 並不建議以停用簽章,或以訪客帳戶使用簽章,作為對第三方機器的權宜之計。² 若真的要放寬設定,請將其視為「直到該機器更換為止,有明確期限的例外」來處理。

4.4. 部署順序

另外,隨著 24H2 以後的端末愈來愈多,「用戶端預設必須簽章」的比例也會隨之增加,因此實質上的截止期限是由 OS 更新計畫決定的。若貴組織正因 Windows 10 支援結束而遷移到 Windows 11 24H2 以後的版本,請將這項驗證納入遷移的前置作業(「Windows 10 支援結束的選擇」)。

5. LDAP 簽章 ── 保護通往網域控制站的路徑

本章與下一章的討論主軸都是「繫結」的種類,因此先確認以下兩個用語。

換句話說,「將 LDAP 簽章設為必須」意味著:要求 SASL 繫結必須簽章,並拒絕以明文連線進行的簡單繫結。

談完 SMB,接下來是 LDAP。傳往網域控制站(以及 AD LDS)的未簽章 LDAP 流量,容易受到重播攻擊與中間人攻擊的威脅。若攻擊者將攔截・竄改後的封包轉發給伺服器,伺服器可能會依據偽造的請求做出判斷。³

所謂強制執行 LDAP 簽章,就是讓目錄伺服器拒絕以下兩種繫結。³

1. 不要求簽章(完整性驗證)的 SASL 繫結(SASL 包含 Negotiate、Kerberos、NTLM、Digest)
2. 以明文(非 SSL/TLS)連線進行的簡單繫結

5.1. 事件 ID 速查表(LDAP 簽章・通道繫結共通)

先整理本章與第 6 章會出現的事件 ID。這些事件全部都記錄在網域控制站的「Directory Service」記錄檔(事件檢視器 > 應用程式與服務記錄檔 > Directory Service)中。這張表可以直接拿來作為稽核設計的依據。

使用區分很單純。用來查看「還剩下多少件」的是彙總事件(2887、3040),用來查看「來自哪裡」的是個別事件(2889、3039、3074、3075)。在件數歸零之前,不要推進到強制執行。以下,5.2 節詳細說明 LDAP 簽章的部分,第 6 章詳細說明通道繫結的部分。

5.2. 先稽核 ── 事件 2886/2887/2889

網域控制站的 Directory Service 記錄檔中,從一開始就有可用的線索。5.1 節速查表中與 LDAP 簽章有關的是 2886、2887、2888、2889 這四個事件,其中 2887 顯示「還有多少未簽章繫結」,2889 顯示「這些繫結來自哪裡」(2888 則是設定拒絕之後的彙總)。³

只有 2889 這一項預設不會出現。將診斷設定「16 LDAP Interface Events」提升為2(Basic)之後,才會開始記錄。³ 流程是先看 2887 的彙總,確認「究竟有多少未簽章繫結」,若不為零,就啟用 2889 來鎖定連線來源。要注意的是,2889 並非彙總,而是每次發生該類繫結就記錄一次,因此在遺留繫結出現頻率高的環境中,會一口氣塞滿 Directory Service 記錄檔。鎖定連線來源之後,請將診斷設定調回原本的層級(預設為 0)。若打算持續開啟,請先確保記錄檔的轉發與保留機制到位。

典型的連線來源包括與 LDAP 整合的業務系統(驗證整合、人事系統整合)、複合機的 LDAP 通訊錄搜尋,以及網路設備的 LDAP 驗證。尤其複合機・設備類的「LDAP 伺服器設定」經常是明文的簡單繫結,請優先懷疑這一項。修正方式是將機器・應用程式端的設定切換為 LDAPS(636 埠)或已簽章的 SASL 繫結。

5.3. 強制執行

修正完所有連線來源之後,就用群組原則強制執行。³

• 網域控制站端: 將 Default Domain Controller Policy 中 安全性選項 裡的「網域控制站:LDAP 伺服器簽章要求」設定為「需要簽章」
• 用戶端: 將「網路安全性:LDAP 用戶端簽章要求」設定為「需要簽章」

可以用 ldp.exe 來確認。連線到 389 埠並嘗試進行簡單繫結,若出現以下錯誤,就代表設定已經生效。³

Ldap_simple_bind_s() failed: Strong Authentication Required

6. LDAP 通道繫結 ── LDAPS 一側的防禦

「我們公司已經改用 LDAPS 了,應該沒問題」──而通道繫結,正是要堵住這裡殘留的破洞。LDAPS 會加密通訊,但光靠這一點,無法完全防止「讓用戶端進行驗證,再把驗證資訊中繼到攻擊者自己另一條 TLS 連線」這種形式的中繼攻擊。通道繫結權杖(CBT)透過將驗證與該 TLS 通道本身綁定,使得中繼到另一條通道的行為可以被偵測出來。

精確地說,對象是在 LDAPS 上進行 NTLM 或 Kerberos 等 Windows 驗證(SASL 繫結)的連線。簡單繫結本來就不具備 CBT,因此不屬於這項驗證的對象。保護 LDAPS 上簡單繫結的,是 TLS 加密與認證資訊管理本身;即使設定為 Always,使用簡單繫結的用戶端也不會出現在 CBT 的稽核事件中。

控制方式是透過網域控制站的登錄值,或對應的群組原則來進行。⁴

用於稽核的事件如下(這是把 5.1 節速查表中通道繫結的部分,連內容一併寫出來)。2020 年 3 月 10 日的更新新增了與通道繫結相關的事件,2023 年以後的更新更進一步擴充了稽核事件。⁴

推進方式與 LDAP 簽章相同,Microsoft 的指引也是「在所有網域控制站的 Directory Service 記錄檔中,監控簽章失敗的 2889、通道繫結失敗的 3039,以及稽核事件 3074、3075,鎖定有問題的機器並向供應商確認,確認可以因應之後再強制執行」。⁴

有一點想特別強調:Microsoft 並沒有透過這些更新改變預設值。官方明確表示,2020 年 3 月 10 日的更新以及此後一段時間的更新,都不會變更 LDAP 簽章・LDAP 通道繫結的預設原則。⁴ 與(在 24H2 中預設值已經改變的)SMB 簽章形成對比,LDAP 這一側只要管理員不親自收緊,就會一直維持寬鬆的狀態。反過來說,這也代表在還能自行選擇收緊時機的期間,可以有計畫地推進。

7. 業務應用程式與機器的修正方式(判斷表)

以下依原因分類,整理稽核中發現的連線來源。

若自行開發的 .NET 應用程式有操作 LDAP,首先要懷疑的是「是否以明文方式送出簡單繫結」。

// 不良範例: 對明文 389 埠進行簡單繫結。強制執行 LDAP 簽章後會被拒絕
var conn = new LdapConnection("dc01.corp.example.com");
conn.AuthType = AuthType.Basic;
conn.Bind(new NetworkCredential(user, password));

// 良好範例1: 要求 Negotiate+簽章・加密(只要 SPN 與名稱解析齊全,就會選用 Kerberos)
var conn = new LdapConnection("dc01.corp.example.com");
conn.AuthType = AuthType.Negotiate;
conn.SessionOptions.Signing = true;
conn.SessionOptions.Sealing = true;
conn.Bind();  // 以執行中的帳戶進行驗證

// 良好範例2: 若要使用簡單繫結,務必改用 LDAPS
var id = new LdapDirectoryIdentifier("dc01.corp.example.com", 636);
var conn2 = new LdapConnection(id);
conn2.SessionOptions.SecureSocketLayer = true;
conn2.AuthType = AuthType.Basic;
conn2.Bind(new NetworkCredential(user, password));

良好範例 1 中的 Negotiate 會優先選用 Kerberos,但不會強制使用。若連線目標是 IP 位址,或 SPN 未註冊・重複,就會靜悄悄地回退到 NTLM(即使如此,簽章・加密的要求本身仍然有效)。要確認是否成功以 Kerberos 進行驗證,最可靠的方式是用 klist 檢查是否已取得對應服務的票證。若環境中已啟用第一篇文章所述的 NTLM 稽核(傳送 NTLM 流量=全部稽核),沒有出現事件 8001 也可以作為旁證。但請注意,若稽核原則仍處於停用狀態,「沒有出現 8001」本身並沒有意義。另外,良好範例 2 的簡單繫結雖然會以 TLS 加密,但如第 6 章所述,屬於 CBT 驗證對象的是 Windows 驗證那一側。若在網域環境中可以選擇,請以良好範例 1 為基本做法。若透過 DirectoryEntry(ADSI),明確指定 AuthenticationTypes.Secure | AuthenticationTypes.Signing | AuthenticationTypes.Sealing 是最可靠的方式。NTLM 系列第一篇文章中提到的原則(連線目標要寫 FQDN 而非 IP 位址),作為讓 Kerberos 上的 SASL 繫結得以成立的前提,在這裡同樣適用。

8. 總結

• SMB 簽章與 LDAP 簽章・通道繫結,是在消除 NTLM 相依性期間也不讓中繼攻擊得逞的防禦手段,同時也是NTLM 廢除後仍會保留的長期強化措施(簽章的竄改偵測與通道繫結,對 Kerberos 驗證的工作階段同樣有效)。應與降低 NTLM 相依性視為同一項措施的兩個輪子來推進。¹⁵
• SMB 簽章的預設值已經改變。Windows 11 24H2(Enterprise/Pro/Education)傳送與接收皆為必須,Windows Server 2025 則是傳送必須。OS 更新計畫本身就是截止期限。²
• 事故的模式是固定的:不支援簽章機器的 0xc000a000,以及訪客存取遭封鎖。可透過 24H2 以後的稽核功能事先找出來。²¹
• LDAP 方面,透過事件 2887、2889(簽章)與 3039、3040、3074、3075(通道繫結)鎖定連線來源,修正完畢後再強制執行。³⁴
• LDAP 這一側的預設值不會因更新而改變。只要管理員不收緊,就會一直維持寬鬆狀態。請趁還能有計畫地推進時盡早進行。⁴
• 自家應用程式只要消除「明文簡單繫結」與「直接使用 IP 位址」,大部分問題就能解決。

相關文章

• NTLM廢除會讓業務應用程式停擺嗎 ── 稽核記錄的擷取方式,以及消除相依性的順序
• 圖解NTLM與Kerberos ── 為什麼驗證會「回退」到NTLM
• 網路磁碟機與 UNC 路徑的陷阱 ── 業務應用程式處理檔案伺服器(共用資料夾)的實務
• 使用 Get-WinEvent 有效率地調查事件記錄 ── 篩選的速度決定調查所需的時間
• Windows 10支援結束後的現實解方 ── ESU、LTSC、換機的判斷表
• Windows 應用程式開發中遵守最低限度安全性的檢核表

相關諮詢領域

合同會社小村軟體提供伴隨 SMB 簽章・LDAP 簽章強制執行而來的業務應用程式改修,以及驗證・檔案共用相關連線故障調查等服務。

• Windows 應用程式開發
• 缺陷調查・原因分析
• 既有資產活用・遷移支援
• 聯絡我們

參考連結

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

常見問題

整理諮詢這個主題時常見的問題。

將 SMB 簽章設為必須之後,檔案伺服器會變慢嗎？

簽章的運算成本並非零,但演算法隨著世代不斷改進。相較於 SMB1 的 MD5,SMB 2.02 改用 HMAC-SHA-256,SMB 3.0 改用 AES-CMAC,而 Windows Server 2022 與 Windows 11 更導入了以 AES-128-GMAC 為基礎的簽章加速。此外,網域控制站原本就會要求所有連線到 SYSVOL 與 NETLOGON 的對象使用 SMB 簽章,群組原則的散發一直以來都是以簽章為前提運作。在以效能為由推遲之前,建議先在試點端末上強制啟用並實際量測。能明顯感受到差異的情況,大多集中在連續傳輸大型檔案等特定使用方式上。

升級到 Windows 11 24H2 之後就無法連上 NAS 了。是 SMB 簽章造成的嗎？

典型情況正是如此。Windows 11 版本 24H2 的 Enterprise、Pro、Education 版本,傳送與接收兩端的 SMB 簽章預設都變成必須,因此連線到不支援簽章(或已停用簽章)的第三方 NAS 時,會出現 0xc000a000(STATUS_INVALID_SIGNATURE)錯誤而失敗。此外,簽章必須化也伴隨著訪客存取的停用,因此在設定為免驗證使用的 NAS 上,會出現「因為組織的安全性原則封鎖了未經驗證的訪客存取」之類的錯誤。第一種對策是在 NAS 端啟用 SMB 簽章,並改用認證資訊而非訪客身分連線。雖然也可以在用戶端停用簽章要求作為權宜之計,但這樣只能解決簽章錯誤那一側的問題。訪客連線遭封鎖是由簽章以外的用戶端設定(禁止不安全的訪客登入)所造成,除非連這項設定也一併放寬,否則仍會持續失敗。Microsoft 並不建議停用簽章,也不建議以訪客身分運作。

LDAP 簽章與 LDAPS(LDAP over SSL/TLS)有什麼不同？

兩者是不同的東西。LDAP 簽章是要求在 389 埠的 LDAP 連線上進行的 SASL 繫結(Negotiate、Kerberos、NTLM、Digest)加上完整性驗證(簽章)的機制,並不會加密通訊本身。LDAPS 則是以 SSL/TLS 將整個連線加密的機制。而 LDAP 通道繫結是位於 LDAPS 之上的進一步防禦,藉由將驗證與 TLS 通道綁定,防止「僅將認證資訊中繼到另一個 TLS 連線」的攻擊。要保護網域控制站,請以下列三項為一組來思考:停止使用明文的簡單繫結、要求 SASL 繫結必須簽章,以及要求 LDAPS 上的 Windows 驗證(SASL 繫結)必須驗證通道繫結權杖。另外,不具備 CBT 的簡單繫結不屬於通道繫結驗證的對象,保護 LDAPS 上簡單繫結的是 TLS 加密本身。

應該按照什麼順序來收緊設定？

稽核→修正→強制的順序,與限制 NTLM 時相同。首先 SMB 方面,啟用 Windows 11 24H2 以後可用的、用來偵測不支援簽章對象的稽核,找出無法簽章的機器。LDAP 方面,在網域控制站的 Directory Service 記錄檔中確認事件 2887(每 24 小時彙總一次未簽章繫結的件數),若件數不為零,就將診斷設定「16 LDAP Interface Events」設為 2,再用事件 2889 鎖定用戶端。通道繫結則以事件 3039、3040,以及 2023 年以後更新新增的稽核事件 3074、3075,以同樣方式找出問題所在。將所有有問題的連線來源全部修正完畢後,再依序切換為 SMB 簽章必須、LDAP 簽章必須,以及將通道繫結設為 Always。唯一的原則就是不要一開始就直接強制執行。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。