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

「NTLM 的稽核已經開始，直接寫死 IP 位址的連線也在修正。那麼，在把相依性全部消除之前，中繼攻擊該怎麼防？」

這段期間的防禦，就是 SMB 簽章，以及 LDAP 簽章與 LDAP 通道繫結。它們不是停用 NTLM 本身的設定，而是在各個連線目標上阻擋「把驗證中繼到另一條連線」的攻擊。它們與削減 NTLM 並行推進，而且是廢除 NTLM 之後仍要保留的強化措施。¹²

推進方式是共通的：先稽核 → 再修正連線來源的應用程式與機器 → 最後強制。不過，SMB 與 LDAP 要確認的設定不同，要讀的事件也不同。本文先把三者的職責分開，之後再分別說明各自的確認、修正與部署步驟。

這是 NTLM 系列的第 3 篇。NTLM 的稽核步驟請參閱「NTLM 廢除會讓業務應用程式停擺嗎」，驗證協定的運作機制請參閱「圖解 NTLM 與 Kerberos」。

1. 先講結論：三種防禦，依連線目標分工

LDAP 簽章是完整性驗證，LDAPS 是整條連線的 TLS 加密，通道繫結則是把驗證與 TLS 通道繫在一起。「已經改用 LDAPS」和「正在驗證 CBT」不是同一件事。另外，簡單繫結不帶 CBT，不在通道繫結驗證的範圍內。詳細內容分別放在第 5 章與第 6 章說明。³⁴

在 SMB 方面，Windows 11 24H2 的 Enterprise、Pro、Education 在收發兩個方向上都預設要求簽章，Windows Server 2025 則在傳送端預設要求簽章。Home 不在這次變更的範圍內，所以不能只看作業系統的版本號(Version)，還要確認版本(Edition)。⁵

另一方面，本文引用的 KB4520412 所涵蓋的一系列更新，並不會變更簽章與通道繫結的預設原則。必須把「裝了更新」和「設定了強制」分開看。不要把這份更新的說明泛化成所有作業系統與導入條件下的預設值，請確認目標環境自身的組態。⁴

圖中實線表示始終成立的關係，虛線表示附帶條件的關係（成立條件寫在詳細頁面中各關係的說明中）。關係的完整清單（共 28 條，附依據與可信度）以及主要概念的定義，彙整在知識地圖詳細頁面（日文）。資料：JSON-LD / Turtle

2. 為什麼需要簽章：與削減 NTLM 並行防守

2.1. 就算能中繼驗證，也做不出正確的簽章

NTLM 根本的弱點在於沒有相互驗證。用戶端無法驗證伺服器的身分，於是攻擊者可以假冒真正的伺服器讓用戶端完成驗證，再把驗證回應中繼給真正的伺服器。這就是中繼攻擊。Microsoft 也說明了 NTLM 與 NTLMv2 驗證在 SMB 中繼與中間人攻擊面前的脆弱性。²

只要完全停用 NTLM，這種 NTLM 中繼就不再成立。不過，第 1 篇文章所談的相依性盤點與修正，通常要花上以月為單位的時間。在這段期間保護連線目標的，正是簽章。

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

    CL -->|"① 驗證回應"| AT
    AT -->|"② 原樣中繼"| SV
    SV -.->|"③ 若要求必須簽章:<br/>沒有工作階段金鑰的攻擊者<br/>做不出正確的簽章而失敗"| AT

圖1：只是中繼了驗證回應的攻擊者，做不出以工作階段金鑰算出的正確簽章

作為驗證的結果，持有簽章所用工作階段金鑰的是用戶端與真正的伺服器。只是中繼了驗證回應的攻擊者沒有這把金鑰，在要求簽章的連線上無法偽造後續訊息。分工是這樣的：針對 SMB 的中繼由 SMB 簽章擋下，針對網域控制站 LDAP/LDAPS 的中繼則由 LDAP 簽章與通道繫結擋下。

2.2. 即使把簽章設為必須，也要繼續往 Kerberos 遷移

要提高簽章的效果，還要確認驗證方式。工作階段金鑰源自密碼，因此建議使用 Kerberos 而非 NTLMv2，從更強的金鑰開始。Microsoft 也提到，連線共用時不要使用 IP 位址或 CNAME。¹

這是因為，以 IP 位址或以未註冊對應 SPN 的別名連線時，使用的會是 NTLM 而不是 Kerberos。要繼續使用別名時該如何註冊 SPN，第 1 篇文章中有說明。

削減 NTLM 相依性與把簽章設為必須，是同時推進的兩項措施。簽章帶來的竄改偵測與通道繫結，對 Kerberos 驗證的工作階段同樣有效，所以它們不是廢除 NTLM 之後就該拿掉的設定。¹

3. SMB 簽章：確認機制與預設值

3.1. 把「支援」與「設為必須」分開看

SMB 簽章會用工作階段金鑰與加密套件，為每一則訊息附加簽章。SMB 標頭中的簽章包含整則訊息的雜湊值以及傳送端與接收端的身分，中途遭到竄改就會對不上。這就構成竄改偵測，也就成了針對冒充與中繼的防禦。¹

看設定時的主軸不是單純的啟用或停用，而是有沒有把簽章設為必須(Require)。SMB 2.x 以後 EnableSecuritySignature 會被忽略，真正有意義的是 RequireSecuritySignature。只要用戶端或伺服器其中一方設為必須，這條連線就需要簽章。只有雙方都未設為必須時才不簽章。¹

簽章的運算是有成本的，但演算法從 SMB1 的 MD5 演進到 SMB 2.02 的 HMAC-SHA-256、SMB 3.0 的 AES-CMAC，Windows Server 2022 與 Windows 11 又加入了以 AES-128-GMAC 加速的機制。不要只憑「簽章很慢」這種過去的印象就擱置，應該在試點電腦上實際量測之後再判斷。¹

3.2. 確認作業系統、版本，以及傳送與接收的方向

首先在「設定 > 系統 > 系統資訊」中確認作業系統的版本(Edition)與版本號(Version)。下表中的傳送，指這台電腦作為 SMB 用戶端發起連線的一側；接收則指它作為 SMB 伺服器接受連線的一側。請找到貴公司電腦與伺服器對應的那一列。

上面三列是 Microsoft 明確寫出的預設值。⁵ 最下面一列的網域控制站屬於一直存在的另一套條件，它要求連線到 SYSVOL 與 NETLOGON 的對象進行 SMB 簽章。群組原則與登入指令碼的散發，向來就是以簽章為前提運作的。¹

即使是 Windows 11 24H2，Home 在收發兩個方向上都不是必須，不在這次預設值變更的範圍內。「Home 只要套用更新就會變成必須簽章」這種說法並不成立。這張表也不保證未來的變更與個別設定，因此遇到連線故障時，請先確認版本(Edition)，再確認 4.1 節所說的實際設定值。⁵

在 Enterprise、Pro、Education 上，更新到 24H2 之後，這台電腦發出的 SMB 連線預設就會變成必須簽章。Windows 本身支援簽章，所以要優先盤點的對象，是不支援簽章或已停用簽章的第三方機器。請確認舊款 NAS、複合機掃描存放目標的相關設定、內嵌 Linux 上的 Samba 等等。

4. SMB 簽章：稽核並修正機器，再設為必須

4.1. 確認目前的簽章要求，以及管理用的原則

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

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

True 代表必須，False 代表非必須。確認時要把傳送端與接收端分開進行。⁵

以群組原則管理的位置是 電腦設定\Windows 設定\安全性設定\本機原則\安全性選項。下面兩項要分開使用。¹

原則名稱中的「一律(always)」就是「必須」的意思。如果還沒有掌握不支援簽章的機器，這個階段就不要一次全面強制，先進入下一步的稽核。

4.2. 用稽核找出無法簽章的對象

在 Windows 11 24H2 以後，可以使用偵測不支援簽章或加密的第三方用戶端與伺服器的稽核功能。以下是針對簽章啟用該功能的命令。¹

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

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

伺服器端查的是連進來的用戶端，用戶端查的是連出去的伺服器。在群組原則中，電腦設定\系統管理範本\網路 底下 Lanman Server / Lanman Workstation 裡的「Audit client does not support signing」等項目與之對應。¹

同一套稽核功能裡還有查加密不支援情況的 -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

這個範例會把簽章與加密的稽核識別碼一起取回來。不要把顯示出來的全部件數都當成「不支援簽章的件數」，請用 Message 把簽章與加密分開。

剛啟用稽核之後等情況下，若沒有對應的事件，Get-WinEvent 會回傳找不到符合項目的錯誤。範例中的 -ErrorAction SilentlyContinue 就是用來抑制它的。篩選條件的寫法也請參閱「使用 Get-WinEvent 有效率地調查事件記錄」。

稽核期間和 NTLM 稽核一樣，要取到業務循環一輪為止。不能只憑剛啟用後那一段記錄，就當作已經確認了所有連線目標。

4.3. 把簽章錯誤與來賓封鎖分開修

從要求簽章的環境連線到無法簽章的對象時，會出現下面的錯誤。⁵

0xc000a000
STATUS_INVALID_SIGNATURE
加密簽章無效。

另一種是來賓存取遭拒。要求簽章的連線上無法使用來賓存取，因此在免驗證即可使用的 NAS 等機器上，會出現下面這樣的錯誤。⁵

因為貴組織的安全性原則封鎖了未經驗證的來賓存取，
所以無法存取這個共用資料夾。

第一個處理方式是在機器端啟用 SMB 簽章，並改用認證資訊而不是來賓身分連線。必要時可以考慮更新韌體，或是改變連線路徑。

在用戶端執行 Set-SmbClientConfiguration -RequireSecuritySignature $false 這種規避做法，緩解的是簽章錯誤那一半。來賓封鎖還受到「禁止不安全的來賓登入」這項另外的用戶端設定控制，因此光是拿掉簽章要求，來賓連線遭拒的問題並不會消失。

Microsoft 既不建議為了遷就第三方機器而停用簽章，也不建議拿來賓帳戶去使用簽章。⁵ 即使確實需要緩解，也不要把它變成常態，而應作為機器汰換之前的限期例外來管理。

4.4. 從試點推進到全面部署

24H2 以後涵蓋的版本愈多，用戶端預設必須簽章的比例就愈高。實質上的截止期限是由作業系統更新計畫決定的，所以請把這項稽核與機器修正納入遷移到 Windows 11 的前置作業。從 Windows 10 遷移的方針，在「Windows 10 支援結束後的現實解方」中有討論。

5. LDAP 簽章：先確認繫結方式再強制

SMB 之後是往網域控制站與 AD LDS 的 LDAP 連線。未簽章的 LDAP 流量在重播攻擊與中間人攻擊面前很脆弱，伺服器有可能依據遭攔截、竄改的要求做出判斷。³

首先，要區分驗證所用的「繫結」種類。

把 LDAP 簽章設為必須之後，會拒絕不要求簽章的 SASL 繫結，以及明文(非 SSL/TLS)連線上的簡單繫結。簽章是與加密不同的完整性驗證。簡單繫結沒有簽章的框架，所以若要繼續使用簡單繫結，就只能改到 LDAPS 上。³

5.1. 讀事件時，把「件數」與「連線來源」分開

LDAP 簽章與下一章的通道繫結，都使用網域控制站的 Directory Service 記錄檔。在事件檢視器中，開啟應用程式及服務記錄檔 > Directory Service。

用法上的區別是：查看剩餘件數的彙總事件(2887、3040)，以及查出連線來源的個別事件(2889、3039、3074、3075)。只要還有問題連線存在，就不要推進到強制，先去修正。

表中的「無需手動啟用即可使用」，說的是那次更新之後可以使用該稽核功能。不要把它理解成任何組態下都一定會出現對應事件，請對照 KB4520412 確認作業系統、已套用的更新與診斷設定。簡單繫結不在 CBT 驗證範圍內這一點，也在第 6 章分開判讀。⁴

5.2. 用 2887 看剩餘件數，用 2889 鎖定連線來源

LDAP 簽章使用的是 2886、2887、2888、2889。2886 是促使設定的提醒，2887 是每 24 小時的問題繫結彙總，2888 是設定為拒絕之後的彙總。只有用來知道連線來源的 2889 預設不會出現。³

先用 2887 確認是否還有未簽章繫結。若有件數，就把診斷設定「16 LDAP Interface Events」改為 2(Basic) 來記錄 2889，查出連線來源 IP 位址與驗證所用的 ID。³

2889 不是彙總，而是逐筆繫結的記錄。在高頻連線仍然存在的環境裡，它會迅速塞滿 Directory Service 記錄檔，因此鎖定連線來源之後，要把診斷設定調回原本的層級(預設為 0)。若要持續記錄，請先備妥記錄檔的轉發與保留容量。

要查的對象包括業務系統的 AD 驗證與人事系統整合、複合機的 LDAP 通訊錄搜尋、網路設備的 LDAP 驗證等。機器類尤其經常設定成明文的簡單繫結，所以要確認它們的 LDAP 設定。修正方式是切換到 LDAPS(636 埠)或附帶簽章的 SASL 繫結。具體例子整理在第 7 章。

5.3. 修正之後要求簽章，並驗證拒絕行為

修正連線來源之後，用群組原則做下面的設定。³

確認設定可以使用 ldp.exe。不使用 TLS 連線到 389 埠並嘗試簡單繫結，若出現下面的錯誤，就代表拒絕的設定已經生效。這是對拒絕行為的驗證，不是在業務中使用明文繫結的步驟。請用驗證專用的認證資訊來做。³

Ldap_simple_bind_s() failed: Strong Authentication Required

6. LDAP 通道繫結：LDAPS 上的驗證也要確認

6.1. TLS 加密與把驗證繫到通道是兩回事

LDAPS 會以 TLS 加密通訊。但是，對於「讓用戶端完成驗證，再把這次驗證中繼到攻擊者自己另一條 TLS 連線」這種形式的中繼，光有加密並不夠。通道繫結權杖(CBT)就是把驗證繫到那條 TLS 通道本身、從而讓中繼到其他通道的行為可以被偵測出來的數值。⁴

適用範圍是在 LDAPS 上進行 NTLM 或 Kerberos 等 Windows 驗證(SASL 繫結)的連線。簡單繫結不帶 CBT，不在這項驗證的範圍內。保護 LDAPS 上簡單繫結的是 TLS 加密與認證資訊管理，即使把設定改成 Always，使用簡單繫結的用戶端也不會出現在 CBT 的稽核事件裡。

6.2. 讓設定值 0、1、2 與原則對應起來

透過網域控制站的登錄檔，或對應的群組原則來控制。⁴

When supported 與 Always 不是同一回事。要把「驗證支援該功能的用戶端」這個階段，和「對適用連線一律要求驗證」這個階段分開，確認支援狀況之後再推進到 Always。

6.3. 用 3039、3040、3074、3075 查出連線來源

把 5.1 節速查表中通道繫結一側事件的意義展開來看，就是下面這樣。2020 年 3 月 10 日的更新加入了相關事件，2023 年以後的更新又擴充了稽核。⁴

Microsoft 的部署步驟也是這個順序：在所有網域控制站的 Directory Service 記錄檔中監控 2889、3039、3074、3075，鎖定有問題的機器並向廠商確認，處理完之後再開啟強制。⁴

不要只因為已經在用 LDAPS 就當作完成，還要看驗證方式與 CBT 的支援狀況。從 6.1 節的區分也看得出來，不該只靠 CBT 事件去找不在範圍內的簡單繫結。

6.4. 不要只因為套用了更新，就判定已經強制

KB4520412 說明，2020 年 3 月 10 日的更新以及該文件涵蓋的一系列更新，都不會變更 LDAP 簽章與通道繫結的預設原則。⁴

因此，在只套用了更新而尚未強制的環境裡，管理員仍然有設定工作要做。不要把它與 SMB 在 24H2 上的預設值變更混為一談，請把「能使用稽核功能」和「已經強制防禦」分開確認。趁還能自行選擇強制時機的期間，把連線來源的修正計畫好並推進下去。

7. 依原因分別修正業務應用程式與機器

7.1. 把事件中出現的對象與修正方法對應起來

不支援簽章、來賓使用方式、明文的簡單繫結、不支援 CBT，這幾類要修的地方各不相同。即使表面上同樣是「連不上」，也不要一律放寬設定，而要依事件與連線方式選擇處理辦法。

7.2. .NET 應用程式要確認驗證方式與 TLS 設定

在自行開發的 .NET 應用程式中，首先要查的是有沒有把 AuthType.Basic 的簡單繫結送往明文的 389 埠。下面是強制 LDAP 簽章之後會被拒絕的不良範例。它不是拿真實認證資訊去執行的範例。

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

修正時，若在網域環境中可以選擇，就以使用 Negotiate 並要求簽章與加密為基本做法。確實需要簡單繫結時，就使用 LDAPS。下面兩個範例是用來對比這兩種選項的節錄，不是要接在前面的不良範例後面連續執行的。

// 良好範例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 查看是否已取得對應服務的票證。若第 1 篇文章所述的傳出 NTLM 稽核設為了「全部稽核」，那麼沒有出現事件 8001 也可以作為旁證。不過，在稽核原則仍處於停用狀態時判斷「沒有 8001」是沒有意義的。

良好範例 2 的簡單繫結雖然會被 TLS 加密，卻不在 CBT 驗證的範圍內。重要的是不要把它當成與良好範例 1 同等的防禦。使用 DirectoryEntry(ADSI) 時，要明確指定 AuthenticationTypes.Secure | AuthenticationTypes.Signing | AuthenticationTypes.Sealing。

連線目標要寫 FQDN 而不是 IP 位址，這條原則對 Kerberos 上的 SASL 繫結同樣適用。請連同名稱解析與 SPN 一起修好，不要只改了程式碼裡的驗證方式就算完。

8. 總結：依路徑分別走完稽核、修正、強制

SMB 簽章、LDAP 簽章與 LDAP 通道繫結，並不是停用 NTLM 的替代品。它們是在削減 NTLM 相依性期間也能擋下中繼的防禦，也是遷移到 Kerberos 之後仍要保留的長期強化措施。¹²

在 SMB 方面，要確認作業系統、版本以及收發兩個方向的預設值，先修好不支援簽章的機器與來賓使用方式。更新到 Windows 11 24H2 相關版本的計畫，就是準備工作的截止期限。在 LDAP 方面，用 2887、2889 查未簽章繫結，用 3039、3040、3074、3075 查通道繫結相關的問題，修正連線來源之後再開啟強制。⁵³⁴

套用更新、啟用稽核功能、強制防禦，是三個不同的階段。尤其不要因為裝了 KB4520412 的 LDAP 更新，就判斷強制已經完成。也請把簡單繫結不在 CBT 驗證範圍內這一點一併納入確認。⁴

在自家應用程式中，先消除明文的簡單繫結與直接寫死的 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 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。