NTLM廢除會讓業務應用程式停擺嗎 ── 稽核記錄的擷取方式，以及消除相依性的順序

「聽說 NTLM 要被廢除了，我們公司沒問題嗎？」──要得出答案，第一步要做的不是在全公司封鎖，而是稽核目前正在運作的驗證。2024 年 6 月宣布 NTLM 的所有版本列為已棄用，但光靠這則公告並不會讓業務停擺。¹

NTLM 的廢除，並不是「某天套上修補程式，全公司就停擺」這類變更，而是每次把 OS 換新就逐步收緊限制的變更。請趁 NTLM 還在運作的時候，把相依的電腦、應用程式與連線目標列成清單，先在小範圍試過再加以限制。先全部停掉、再去找壞掉的地方，順序正好相反。

本文是寫給管理 Windows 環境的資訊系統部門，以及維護業務應用程式的開發者的實務步驟。進行順序是稽核 → 原因分類 → 名稱・設定・程式碼的修正 → 以連線為單位的測試 → 分階段限制。

至於協定機制本身(為什麼 NTLM 危險、為什麼驗證會回退到 NTLM 而不是 Kerberos),則分到對應的另一篇文章「圖解NTLM與Kerberos ── 為什麼驗證會「回退」到NTLM」。

廢除路線圖與功能提供狀況的基準時點，與原文相同，都是 2026 年 7 月。請與版面的更新日期區分開來。IAKerb、本機 KDC 等功能的提供狀況，請在實際判斷是否遷移時，查閱對象版本的版本資訊。²

從自己遇到的問題開始讀

若要從頭讀到尾，請從第 1 章開始;要動手實作時，請回到第 4 章的稽核。

1. 先講結論

區分變更目前走到哪一步

NTLM 已於 2024 年 6 月列為已棄用。對象是包含 LANMAN、NTLMv1、NTLMv2 在內的所有版本，這是「不再進行積極功能開發」的宣告。同時也寫明「NTLM 在下一版 Windows Server 與下一個年度發行版的 Windows 上仍會持續運作」。¹

已經有部分遭到移除。NTLMv1 已在 Windows 11 版本 24H2 與 Windows Server 2025 中移除。¹

廢除分三個階段進行。第一階段是使用狀況的可視化與稽核，第二階段(2026 年下半年)是提供讓場景不再非依賴 NTLM 不可的功能(IAKerb、本機 KDC),第三階段則是在下一個主要版本中將網路 NTLM 驗證預設為停用。²

在封鎖之前，先鎖定相依之處

現在該做的事只有一件。執行稽核模式，做出「哪一台電腦的哪個應用程式，對哪一台伺服器」使用 NTLM 的清單(第 4 章)。

網域帳戶的調查，從網域控制站開始。依「事件 8004 → 成員伺服器的 8003 → 用戶端的 8001」的順序追下去，最後就能追到應用程式名稱(4.2 節)。不過本機帳戶的驗證不會經過網域控制站，所以不會出現 8004。這條路徑要從伺服器端的 8003 與用戶端的 8001 擷取。³

大多數原因都是「名稱」。直接寫死 IP 位址與 SPN 未註冊是兩大要因，兩者都不必重做應用程式就能修正(第 5 章)。³²

小規模試過，應用程式端也要修

有辦法只用一台電腦安全地測試。若是 Windows 11 24H2 / Windows Server 2025,可用 NET USE \\server\share /BLOCKNTLM,在完全不變更原則的情況下確認「不用 NTLM 能不能連上」(第 7 章)。⁴

自製應用程式要把直接指名 NTLM 的地方改成 Negotiate。Microsoft 自己就寫著「不要直接存取 NTLM 安全性套件」(第 8 章)。⁵

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

2. 「已棄用」代表什麼意思

首先整理一下用語。如果把這裡含糊帶過就對公司內部說明，「聽說已經不能用了」和「聽說還能撐好幾年」就會同時流傳，把話題弄亂。

區分已棄用的公告與已經發生的移除

Microsoft 的已棄用功能清單中關於 NTLM 的敘述，摘要起來有以下三點。¹

1. 包含 LANMAN、NTLMv1、NTLMv2 在內的所有版本 NTLM,都不再是積極功能開發的對象，並列為已棄用。
2. NTLM 的使用，在下一版 Windows Server 與下一個年度發行版的 Windows 上仍會持續運作。
3. 呼叫 NTLM 的地方應改為呼叫 Negotiate。Negotiate 會先嘗試以 Kerberos 驗證，只有在必要時才回退到 NTLM。

接著，作為更新資訊，還補充了NTLMv1 已從 Windows 11 版本 24H2 與 Windows Server 2025 中移除這一點。¹

也就是說，目前所處的階段是「已棄用(deprecated)」,而不是「已移除(removed)」。不過唯獨 NTLMv1 已經跨過已棄用，進入了移除階段。若老舊的複合機或 NAS 只能以 NTLMv1 驗證，更新到 Windows 11 24H2 就會直接變成故障。這不是未來的事，而是現在正在發生的事。

需要替代手段的用途，要連對方的條件一起確認

還有一點要掌握:NTLM 仍留有「不存在替代方案的用途」。Microsoft 明確表示，在採用工作群組組態的系統上進行 Windows 驗證，以及在網域控制站以外的地方進行本機登入驗證，目前仍然使用、也必須使用 NTLM。⁶ 第二階段預定提供的本機 KDC,正是為了填補「本機帳戶需要 NTLM」這個缺口的功能。²

2.1. 三個階段的現況

廢除的路線圖分為三個階段。由於這是與時間點相關的資訊，以下附上基準日期整理(下表是 2026 年 7 月時點的狀況)。

希望從這張表確認的是，現在能由自己動手推動的只有第一階段。第二階段的功能在第 6 章的判斷表中有幾處寫著「可能成為解法」,但都以確認提供狀況為前提。提供時程可能變動，因此這張表的內容，請務必在自家公司做判斷的時點重新取得。

3. 為什麼會消失 ── 只花 3 分鐘

作為遷移的判斷材料，這裡只掌握最低限度。詳細的圖解交給對應的另一篇文章。

Microsoft 在原則設定的文件中明白寫著，NTLM 與 NTLMv2 驗證對包含 SMB 中繼、中間人攻擊、暴力破解攻擊在內的各種惡意攻擊都很脆弱。⁷ 根源在於下列這些與 Kerberos 對比時會談到的性質。⁸

沒有相互驗證

在 NTLM 中，用戶端無法驗證伺服器的身分，伺服器也無法驗證另一台伺服器的身分。NTLM 是為了可以假設「伺服器是真的」的網路環境所設計。Kerberos 則不做這個假設。這個差異，正是讓認證資訊被送往假伺服器的中繼攻擊得以成立的條件。

網域驗證時，伺服器要向 DC 查詢

在 NTLM 中，應用程式伺服器每次驗證網域帳戶的用戶端時，都必須連線到網域控制站(若是伺服器本機的帳戶，則由伺服器查自己的帳戶資料庫來判定)。⁶ 在 Kerberos 中，可更新的工作階段票證取代了這種傳遞驗證，除非需要驗證 PAC(特殊權限屬性憑證),否則伺服器不需要連往網域控制站。

就算不知道密碼，偷到的雜湊值也會被濫用

NTLM 的認證資訊由網域名稱與使用者名稱，加上密碼的單向雜湊值所組成(被雜湊的只有密碼),用戶端會用這個雜湊值加密挑戰值並回傳回應。⁵ 只要偷到雜湊值，即使不知道明文密碼也能冒充他人，這個性質就是從這裡來的。

「沒有相互驗證」在實務上的意思是，光是想連上 SMB 共用資料夾，就可能把認證資訊交給假的伺服器。Microsoft 之所以準備 SMB 用戶端側的 NTLM 封鎖功能，理由也被說明為「防止讓惡意伺服器誘導送出 NTLM 要求的手法」。⁴

4. 稽核 ── 列出 NTLM 在哪裡被使用

這裡才是正題。Microsoft 的指南也明確寫著，在實作限制原則之前，必須先發現並稽核目前 NTLM 驗證流量的狀態。⁹

4.1. 啟用稽核模式

注意: 稽核模式只會記錄，不會封鎖任何東西。另一方面，在機器數量多的環境中，記錄量會一口氣暴增。若沒有使用事件收集(WEF),請先重新檢視記錄檔大小上限與保留期間，再行啟用。Microsoft 的指南也表示，依環境的複雜程度，分析有可能長達數個月。³

稽核期間要從設定送達對象電腦之後開始計算。為了不漏掉月次處理或故障時才會走的路徑，請先一併確認 9.2 節的「業務跑完一輪」。

設定位置與三個原則

要設定的是三個原則。位置都在 電腦設定\Windows 設定\安全性設定\本機原則\安全性選項,而且不需要重新啟動。無論是儲存在本機，還是透過群組原則發布，設定套用的當下就會生效。⁷

不要把儲存 GPO 的時刻當成稽核的起算時刻

不過「不需要重新啟動」和「立刻對所有機器生效」是兩回事。用網域的 GPO 發布時，儲存 GPO 當下更新的只有 AD/SYSVOL 上的原則，各台電腦實際開始稽核，要等到下一次背景更新，或是執行 gpupdate /force 之後。稽核期間的起點不是「儲存 GPO 的日期時間」,而是「套用已送達對象電腦的日期時間」,請這樣計算。若在這裡弄錯，結果就會以「只有第一次彙整的對象台數偏少」的形式被扭曲。

第三個「傳送到遠端伺服器的 NTLM 流量」有全部允許 / 全部稽核 / 全部拒絕 / 未定義四種值，未定義的處理方式與「全部允許」相同。Microsoft 的建議也很明確:不要一開始就選「全部拒絕」,先設為「全部稽核」並確認運作記錄檔，掌握哪些伺服器正在接收驗證要求之後，再建立例外清單。⁷

要看的是 NTLM/Operational,而不是安全性記錄檔

記錄位置是事件檢視器 > 應用程式與服務記錄檔 > Microsoft > Windows > NTLM(Microsoft-Windows-NTLM/Operational)。這項稽核沒有對應的安全性稽核事件原則，因此要看的是這個通道，而不是安全性記錄檔。⁷

讓機器的角色與要記錄的事件相互對應

現場最容易搞錯的，就是「要在哪台機器放哪個原則、又要看哪個事件」的對應關係。把上表的三個原則當成①②③,整理成檢查清單。

不論哪台機器，記錄檔都是同一個 Microsoft-Windows-NTLM/Operational。①只對網域控制站有效，而漏掉②③的電腦不會是「沒有使用 NTLM 的電腦」,而是「沒有記錄的電腦」。這個差異是讓彙整結果失真的最大原因。

4.2. 追蹤要「從網域控制站往下游走」

首先，把驗證所使用的帳戶分開。若是網域帳戶就從 DC 往下游走，若是本機帳戶就從伺服器與用戶端追蹤。³

另外，也有網域控制站不會出現 8004 的情況。因為以本機使用者帳戶連線檔案伺服器時，該驗證不會經過網域控制站。³ 不可以因為「看了 DC 的記錄檔覺得很少」就判斷沒問題。

網域帳戶要依 8004 → 8003 → 8001 追蹤

Microsoft 的指南所示的網域帳戶追蹤路徑如下。³

flowchart TD
    DC["網域控制站<br/>事件 8004"]
    MS["成員伺服器<br/>事件 8003"]
    CL["用戶端<br/>事件 8001"]
    APP["造成原因的應用程式"]

    DC -->|"安全通道名稱 =<br/>應調查的伺服器"| MS
    MS -->|"工作站名稱 =<br/>應調查的用戶端"| CL
    CL -->|"用戶端處理程序名稱"| APP
    MS -.->|"若 PID 為 4 (SYSTEM)<br/>則是經由 SMB"| CL

圖 1: NTLM 稽核事件的追蹤順序

各個事件要看的項目如下。³

最後要看的是連線目標與處理程序名稱

這條路徑上特別有價值的，是8001 的「目標伺服器」與「用戶端處理程序名稱」。前者直接告訴你「為什麼沒有變成 Kerberos」,後者直接告訴你「是誰的問題」。Microsoft 的指南也說明，從這些資訊可以判定使用者是連到 Web 伺服器的 IP 位址，而沒有使用原本可以走 Kerberos 的 NetBIOS 名稱或 FQDN。³

4.3. 用 PowerShell 彙整

步驟 1: 數一數那台機器上記錄了哪些事件識別碼

用事件檢視器的 GUI 一筆一筆看數千件並不實際，所以用 Get-WinEvent 彙整。首先確認那台機器上各個事件各出現幾筆。

# 將 NTLM/Operational 的事件依 ID 彙整(以系統管理員權限執行)
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-NTLM/Operational'
    StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue |
    Group-Object Id |
    Sort-Object Count -Descending |
    Select-Object Count, @{ N = 'EventId'; E = { $_.Name } }

步驟 2: 打開一筆 8001,確認實際的項目名稱

確認有事件出現之後，把用戶端側的 8001 以「連線目標伺服器 × 呼叫端處理程序」歸類。事件的欄位組成會因事件識別碼而異，所以先用 Format-List 打開一筆確認結構,再決定彙整要用的項目名稱，這樣比較保險。

# 先只看一筆的內容
$sample = Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-NTLM/Operational'
    Id      = 8001
} -MaxEvents 1

$sample | Format-List TimeCreated, Id, Message
# 若要看結構化欄位
([xml]$sample.ToXml()).Event.EventData.Data |
    Select-Object Name, '#text'

步驟 3: 以連線目標 × 呼叫端處理程序彙整

搞清楚結構之後，就用 XML 的 Name 屬性取出來彙整。屬性名稱會因 OS 版本而有差異，所以用名稱去取，比用位置指定更不容易壞。

# 將最近 7 天的 8001 以「連線目標 × 呼叫端處理程序」彙整
$events = Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-NTLM/Operational'
    Id        = 8001
    StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue

$rows = foreach ($e in $events) {
    $data = @{}
    foreach ($d in ([xml]$e.ToXml()).Event.EventData.Data) {
        $data[$d.Name] = $d.'#text'
    }
    [pscustomobject]@{
        Time    = $e.TimeCreated
        # 只挑實際存在的欄位名稱,並依優先順序取用
        Target  = @('TargetName', 'TargetServer', 'ServerName') |
                  Where-Object { $data.ContainsKey($_) } |
                  ForEach-Object { $data[$_] } | Select-Object -First 1
        Process = @('ClientProcessName', 'ProcessName', 'ApplicationName') |
                  Where-Object { $data.ContainsKey($_) } |
                  ForEach-Object { $data[$_] } | Select-Object -First 1
    }
}

$rows | Group-Object Target, Process |
    Sort-Object Count -Descending |
    Select-Object Count, Name

步驟 4: 比起件數，更該看連線目標與負責的應用程式

最後的彙整會傳回 Count(件數)與 Name(把 連線目標, 呼叫端處理程序 以逗號串接而成)兩個欄位。也就是說，輸出會是這個樣子(值只是為了說明的範例)。

Count Name
----- ----
  412 192.168.1.10, System
  118 fileserver.corp.example.com, System
   57 192.168.1.24, MyBizApp.exe
    9 legacy-nas, System

該看的是 Name 的前半段，也就是連線目標。各資料列的讀法如下。

件數的絕對值本身沒什麼意義。請看「IP 位址為目標的資料列有沒有排在前面」與「已經查到執行檔名稱的資料列有幾列」這兩點。前者是只要修就一定會減少的相依，後者是可以指派負責人的相依。

若彙整結果是空白或 PID,就重新檢視項目名稱

欄位名稱會因 OS 版本而有差異，所以寫成把候選排成有優先順序的陣列，只取實際存在的項目。這裡如果用 -match 'Process' 這種部分比對，連 ClientProcessId 這種 PID 欄位都會被撈到，結果就可能不是用執行檔名稱、而是用每次都會變的 PID 來彙整(雜湊表的鍵順序不固定，所以會取到哪一個也不穩定)。如果 Process 欄位全部變成空白，就是候選名稱與實際結構描述不合的徵兆,請把前一個步驟確認到的名稱加進陣列。

擴大到多台之前，先在 1 台上統一讀法

若要從多台機器收集，用 PowerShell Remoting 平行執行會比較快(「PowerShell Remoting(WinRM)入門」)。Get-WinEvent 的篩選是否使用 -FilterHashtable,所需時間會差上好幾個數量級，這方面的要領整理在「使用 Get-WinEvent 有效率地調查事件記錄」。

4.4. 從安全性記錄檔這一側看 ── 確認是否還在使用 NTLMv1

除了 NTLM/Operational 之外，也有從安全性記錄檔的登入事件確認 NTLM 版本的方法。步驟是在安全性記錄檔中搜尋「驗證套件」,再查看各事件的「詳細驗證資訊」。³

詳細驗證資訊:
    登入處理程序:               NtLmSsp
    驗證套件:                   NTLM
    已轉換的服務:               -
    套件名稱 (僅限 NTLM):       NTLM V1
    金鑰長度:                   128

NTLM V1 的記錄要另外歸類、優先處理

這個「套件名稱 (僅限 NTLM)」會指出使用的是 NTLM 協定群中的哪一個子協定。³ 出現 NTLM V1 的主機，就是直接升級到 Windows 11 24H2 / Windows Server 2025 之後驗證會過不了的候選。因為 NTLMv1 已在這些版本中移除。¹ 執行稽核時，唯獨這個觀點請提高優先順序去撈。

4.5. 當 PID 幾乎都是 4(SYSTEM),進度卡住時

一開始稽核，幾乎一定會撞上這道牆。像 SMB(共用資料夾)這種經由重新導向器通訊的應用程式，要求驗證的主體是核心模式的重新導向器，因此事件中留下的 PID 永遠是 4(SYSTEM)。³

用記錄檔鎖定電腦，再用 ProcMon 追那一台

Microsoft 的指南所示的處理方式如下。³

1. 在正在送出 NTLM 認證資訊的用戶端(8001 的「電腦」)上，安裝處理程序監控工具。
2. 以對方伺服器的電腦名稱與 IP 位址兩者篩選路徑。若需要長時間採集，就以背景模式執行。
3. 把採集結果與伺服器端事件 8003 的時間戳記比對。使用者、路徑、驗證識別碼會互相對應，由此就能鎖定呼叫端應用程式。

工具是 Process Monitor(ProcMon)。篩選條件的設法與讀法，整理在「Process Monitor(ProcMon)實戰指南」。

再補一個實務上的訣竅:在這個階段之前，先只用事件記錄檔把「是哪一台電腦」完全鎖定，再只對那一台電腦掛上 ProcMon,速度會快得多。把 ProcMon 發給所有機器並不實際。

5. 回退到 NTLM 的典型模式

稽核查出位置之後，接下來就是原因的分類。Microsoft 的指南舉出了理論上支援 Kerberos、實際卻會使用 NTLM 的應用程式四種。³

• 可以選擇各種安全性組態或提供者的應用程式
• SPN(服務主體名稱)未正確組態的應用程式
• 因設定錯誤或廠商文件的緣故，使用 IP 位址而非 DNS 名稱的應用程式
• 擁有舊有程式碼庫，其中仍殘留 NTLM 專用部分的應用程式

Microsoft 日本的支援部落格則舉出使用 NTLM 的代表性原因，包括以 IP 位址指定存取伺服器、防火牆限制了 Kerberos 所需的通訊埠、SPN 未註冊、對信任關係對象的驗證，以及工作群組環境中的驗證。²

把原因與修正的優先順序記在同一張表

把這些整理成現場會遇到的形式，就成了下面這張表。右邊兩欄是用來排優先順序的基準。「影響範圍」代表停擺時會困擾到多廣，「修正容易度」代表能不能只靠自家公司的判斷就修好。只要掌握這兩點，就能直接變成計畫書的著手順序。

把 NTLMv1 列為最優先，長期協調則同時開始

著手順序可以從這兩欄機械式地決定。

1. 不論影響範圍，最優先的都是只會說 NTLMv1 的裝置，以及記錄到 NTLM V1 的主機(4.4 節)。只有這一項是因為「期限已經到了」,所以放在優先度計算之外。¹
2. 其次是影響範圍=大且修正容易度=高,也就是直接寫死 IP 位址。件數多，而且只靠自家公司的判斷就能修。第一個月請集中在這裡。
3. 再其次是修正容易度=中的 SPN 相關項目。與名稱的統一一起推進。
4. 修正容易度=低的項目(取決於裝置、路徑、等待第二階段),並不是著手時間晚，而只是前置時間長,所以至少要把向廠商洽詢與編列預算，與第 1～3 項並行地提早開始。

被分類為「馬上就能修」與「註冊 SPN 就能修好」的項目，應該會占稽核結果的大半。光是把這些處理掉，剩下的例外就會少很多。

6. 修正方式的判斷表

依第 5 章標上的分類選擇處理方式。先推進改成 FQDN 與確認 SPN,TryIPSPN 則當成無法改為名稱時的最後手段。IIS 的 SPN 註冊對象有例外，作業前請確認 8.3 節的「解密票證的識別」。

7. SMB 的 NTLM 封鎖 ── 實地確認的最短路徑

稽核記錄檔能告訴你「正在被使用」,卻不會告訴你「停掉會怎樣」。這時派得上用場的，就是Windows Server 2025 與 Windows 11 版本 24H2 新增的 SMB 用戶端側 NTLM 封鎖。⁴

這項功能會封鎖 SMB 用戶端在對遠端的傳出連線中使用 NTLM 驗證。Microsoft 表示，藉此可以防止讓惡意伺服器誘導送出 NTLM 要求的手法，並對抗暴力破解、破解與 Pass-the-Hash 攻擊,並且把它定位為組織要把驗證協定切換到 Kerberos 時必要的一環。同時也寫著，即使不完全停用 NTLM,也能單獨啟用這一層保護。⁴

注意: 這項功能是SMB 用戶端側的功能。⁴ SMB 以外的路徑(自家應用程式的 HTTP 通訊、對 SQL Server 的連線、WinRM 等)上的 NTLM,靠這個是擋不住的。那些要依第 5 章的分類個別處理。

前提條件有以下兩項。⁴

• SMB 用戶端是 Windows Server 2025(含)以後，或 Windows 11 版本 24H2(含)以後
• 連線目標的 SMB 伺服器能夠使用 Kerberos(SMB 伺服器端的 OS 只要能用 PKU2U 或 Kerberos 即可)

7.1. 先只用 1 台、1 個連線測試

不要一開始就發布原則，而是善用可以逐一連線指定封鎖這一點。不過，要下判斷需要解除既有工作階段,以及確認不加旗標時可以連上。下面兩個命令只是指定方式的範例，實際測試請依這下面的四個步驟進行。

# 只在這個連線禁用 NTLM 並嘗試連線(若連得上,表示該共用資料夾不需要 NTLM 也夠用)
NET USE \\fileserver.corp.example.com\share /BLOCKNTLM

# 用 PowerShell 的對應也能做同樣的事
New-SmbMapping -RemotePath \\fileserver.corp.example.com\share -BlockNTLM $true

滿足必要前提後若能連上，就可以判斷這條路徑不用 NTLM 也能成立。失敗時，則與不加旗標的測試比較，把原因分開。由於不必變更原則就能逐一連線確認，很適合用來佐證稽核記錄檔。

結果要分成以下三個層次確認。請不要只憑錯誤訊息的文字就斷定是相依 NTLM。

避免誤判的四個步驟

不過，這項確認需要照步驟來。什麼都不想就執行，兩個方向都會誤判。

$server = 'fileserver.corp.example.com'

# 1. 把對該伺服器的對應「一個不留」地解除
#    只要還留著任何一個別的共用資料夾,以伺服器為單位的工作階段就會繼續存活
net use | Select-String $server              # 先看看目前連著什麼
net use \\$server\share  /delete
net use \\$server\other  /delete             # 同一台伺服器的其他共用資料夾也全部解除

# 2. 確認工作階段真的消失了(沒有變空就不要進到下一步)
Get-SmbConnection -ServerName $server

# 3. 先確認不加旗標可以連上(若在這裡就失敗,表示是 NTLM 以外的問題)
net use \\$server\share
net use \\$server\share /delete
Get-SmbConnection -ServerName $server        # 這裡也要恢復成空的

# 4. 在此基礎上,加上 /BLOCKNTLM 測試
net use \\$server\share /BLOCKNTLM

步驟 1～2: 不只是共用資料夾，連對伺服器的工作階段都要解除

SMB 的工作階段是以伺服器為單位，而不是以共用資料夾為單位。若對該伺服器的已驗證工作階段還留著，重新導向器就不會重做驗證，而是直接重複使用它。/BLOCKNTLM 生效的只有為了那個對應所進行的驗證,並不會回頭去驗證已經建立的工作階段(可能是用 NTLM 建立的)。

也就是說，只把測試對象的共用資料夾 /delete 並不夠。如果同一台伺服器的其他共用資料夾還連著，即使存在 NTLM 相依也會測試成功。請一直解除到 Get-SmbConnection 什麼都不傳回為止。除了自己的對應之外，常駐應用程式或備份作業也可能握著工作階段。若要確保萬無一失，從一台從未連過該伺服器的電腦上測試，是最快的做法。

步驟 3: 把不加旗標的成功當成比較的基準

名稱解析失敗、認證資訊錯誤、對共用資料夾本身的存取權不足，都會讓加上 /BLOCKNTLM 的執行失敗。若不加旗標也失敗，那就不是相依 NTLM,而是別的問題。

即使成功，也不代表驗證方式就自動確定了

請注意，這裡能說的只到「不需要 NTLM」,還說不到「以 Kerberos 完成驗證」。這項功能的前提條件是「能使用 Kerberos 的 SMB 伺服器」,但連線目標也可以是能使用 PKU2U 的 OS。⁴ 也就是說，成功的理由是 PKU2U 而不是 Kerberos 的可能性仍然存在。若對象是已加入網域的檔案伺服器，基本上不會有問題，但若想確定實際上是用什麼驗證的，請在連線後於用戶端執行 klist,查看是否取得了該伺服器的 cifs/ 票證，或是在伺服器端的安全性記錄檔中確認登入事件的驗證套件(4.4 節)。

7.2. 以電腦為單位啟用

佐證完成之後，就在試行電腦上進入整台電腦的封鎖。⁴

# 在整個 SMB 用戶端上封鎖 NTLM(系統管理員權限)
Set-SmbClientConfiguration -BlockNTLM $true

若用群組原則，則啟用 電腦設定 > 系統管理範本 > 網路 > Lanman 工作站 中的 「封鎖 NTLM (LM、NTLM、NTLMv2)」。⁴

7.3. 無論如何都會殘留的對象，列入例外清單

未加入網域的 SMB 伺服器等等，無論如何都需要 NTLM 的對象可以列為例外。啟用群組原則的 Lanman 工作站 > 封鎖 NTLM 伺服器例外清單,並列舉要允許的對象的 IP 位址、NetBIOS 名稱、FQDN。⁴

把永久性的例外與緊急時的登錄檔操作分開

由於沒有準備用來建立例外清單本身的 PowerShell Cmdlet,第一次必須用群組原則編輯器設定，但建立之後要個別新增，則可以用登錄檔操作完成。⁴

# 在既有的例外清單中新增項目
$params = @{
  Path = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\LanmanWorkstation"
  Name = "BlockNTLMServerExceptionList"
}
$Entries = "192.168.10.10", "corp.contoso.com", "CORP"

$CurrentValue = (Get-ItemProperty @params -ErrorAction SilentlyContinue).BlockNTLMServerExceptionList
$params["Value"] = if ($null -eq $CurrentValue) { $Entries }
                   else { $CurrentValue + $Entries }
Set-ItemProperty @params

注意: Microsoft 文件上刊登的範例，在值尚不存在時的分支只會設定 @(""),想新增的項目就這樣被丟掉了。⁴ 第一次執行時一個例外都不會進去，要到第二次執行才終於會進去，因此上面的程式碼在尚未建立的情況下也會直接寫入要新增的對象。話雖如此，這個登錄值本來就是群組原則管理的區域。永久性的例外請在群組原則端管理，這項操作請僅限於緊急時的暫時處置。下一次套用原則時就會被覆寫。

8. 從開發者角度看 NTLM ── 使用 Negotiate

若自家公司有在開發 Windows 應用程式，要修的地方非常明確。Microsoft 明白寫著以下內容。⁵

應用程式不應直接存取 NTLM 安全性套件，而應改用 Negotiate 安全性套件。只要參與驗證的系統有支援，Negotiate 就能讓應用程式使用更先進的安全性協定。目前，Negotiate 安全性套件會在 Kerberos 與 NTLM 之間擇一。除非參與驗證的系統中有一方無法使用 Kerberos,否則 Negotiate 會選擇 Kerberos。

也就是說，原則就是把寫著「NTLM」的地方改成「Negotiate」。已棄用功能清單上的敘述也一樣，表示呼叫 NTLM 的地方應改為呼叫 Negotiate。¹

8.1. .NET 中常見的「直接指名 NTLM」

不要變更進行驗證的帳戶，只替換驗證類型

// 不好的範例: 在驗證類型中直接指名 NTLM
var credential = new NetworkCredential(user, password, domain);
var cache = new CredentialCache();
cache.Add(new Uri("http://intra.example.local/"), "NTLM", credential);

var handler = new HttpClientHandler { Credentials = cache };

// 良好範例: 只改驗證類型。認證資訊照原樣傳入
var credential = new NetworkCredential(user, password, domain);
var cache = new CredentialCache();
cache.Add(new Uri("http://intra.example.local/"), "Negotiate", credential);

var handler = new HttpClientHandler { Credentials = cache };

這裡要改的只有驗證類型的字串。如果把 credential 換成 CredentialCache.DefaultNetworkCredentials,改變的就不只是驗證協定，連進行驗證的主體都會改變。屆時會改用執行該處理程序的帳戶(服務帳戶或登入中的使用者)去驗證，而不是原本指定的帳戶，依連線目標的權限設定不同，可能會無法運作。協定的替換與認證資訊的檢討，請當成不同的變更分開進行。

改成以目前的使用者驗證，要當成另一項判斷來做

另一方面，如果本來就想用登入中使用者的認證資訊進行驗證(整合式 Windows 驗證),寫法可以更單純。這是刻意要改變「以誰的身分驗證」時的寫法。

// 整合式 Windows 驗證(以目前登入的使用者驗證)
var handler = new HttpClientHandler
{
    UseDefaultCredentials = true,
};

HttpClient 本身的處理方式(不要用 using 包起來、產生模式、逾時設計),整理在「不要用 using 包住 HttpClient」。

直接操作 SSPI 時，也要指定 Negotiate

若必須直接操作 SSPI,使用 .NET 7 之後新增的 System.Net.Security.NegotiateAuthentication,就能從受控碼處理透過 Negotiate 的驗證。這裡的重點同樣是不要在套件名稱中指定 NTLM。

8.2. 比程式碼更該先檢查的「連線目標寫法」

就算修了程式碼，只要連線目標還是 IP 位址，結果還是會回退到 NTLM。因為在預設情況下，當主機名稱是 IP 位址時，Windows 不會對該主機嘗試 Kerberos 驗證，而是回退到 NTLM 等其他有效的協定。¹⁰ 具體來說請清查以下項目。

• 設定檔(appsettings.json、App.config、ini 檔)中寫的伺服器名稱
• SQL Server 連線字串中的伺服器指定(Data Source)
• 組出 UNC 路徑的地方。有沒有寫死的 IP 位址
• 安裝程式或裝機手冊中的預設值
• 過去處理故障時因為「名稱解析不穩定」而改成 IP、之後沒有改回來的地方

最後一項真的很常找到。直接寫死 IP 位址在當時是正確的應急處置，但現在已經是技術債。

8.3. 若是在開發服務端

若想讓自製的 Windows 服務或 IIS 應用程式以 Kerberos 接受驗證，就必須對解密票證的帳戶，以用戶端存取時所用的名稱註冊 SPN。正如 Microsoft 自己所舉的代表例:未註冊 SPN 的應用程式，即使號稱支援 Kerberos 也會回退到 NTLM。³

在 IIS 上，應用程式集區的識別與解密的識別未必相同

如果把註冊對象單純想成「執行服務的帳戶」,在 IIS 上就會跌倒。IIS 的 Windows 驗證預設啟用核心模式驗證，此時負責解密 Kerberos 票證的不是應用程式集區的識別，而是HTTP.sys 所使用的電腦帳戶。即使是以專用的網域帳戶執行應用程式集區，若把網站的 HTTP SPN 註冊到該帳戶，SPN 的持有者與實際解密的帳戶就會不一致,結果不只是回退到 NTLM,而是會以 KRB_AP_ERR_MODIFIED 讓驗證本身失敗。

重點是「讓 SPN 的註冊對象與解密票證的識別一致」。可採取的形式有以下兩種。

要選哪一種，取決於是否有多台伺服器共用同一個服務帳戶(若有共用，靠向應用程式集區識別的做法比較好處理)。另外SPN 只能註冊在一個帳戶上,所以切換時別忘了刪除舊的註冊。重複註冊會破壞 Kerberos 驗證本身。

對其他伺服器的委派，要與協定變更一起確認

若採用偽裝成用戶端去存取其他伺服器的設計(委派),NTLM 與 Kerberos 的處理方式就不一樣。Kerberos 支援讓服務代表用戶端連線到其他服務的委派機制，而 NTLM 提供的僅止於在本機偽裝所需的授權資訊。⁸ 偽裝相關的實作，在「Windows 的偽裝(Impersonation)與權杖」中有說明。

9. 分階段收緊的路線圖

把以上內容整理起來，推進的順序如下。每個階段都以「可以退回」為條件。

9.1. 就算擋住 SMB,那也只是 NTLM 對策的一半

階段 4～6 處理的只有 SMB。如第 7 章所述，SMB 用戶端的 NTLM 封鎖是 SMB 用戶端側的功能，⁴ 對其他路徑沒有效果。在階段 2 分類為「以 HTTP 驗證」「SQL Server 變成 NTLM」「WinRM 使用 NTLM」的項目，就算推進到階段 6 也會原封不動地留著。而且它們不會出現在 SMB 的例外清單上，所以清點件數也看不到。

SMB 以外要用 Restrict NTLM,依稽核 → 例外 → 拒絕推進

負責收緊那些項目的是階段 6b。使用的就是第 4 章切換到稽核模式的那三個原則。步驟遵循相同的形式。¹¹

1. 維持「傳送到遠端伺服器的 NTLM 流量」為全部稽核,清查還殘留的連線目標
2. 把無論如何都必要的對象註冊到「新增遠端伺服器的例外」
3. 在試行電腦上切換為全部拒絕,等待業務跑完一輪
4. 沒有問題就推行出去

整個網域也要先用對應的稽核確認影響，再切到拒絕

對整個網域則是把「這個網域中的 NTLM 驗證」同樣依稽核 → 例外(「新增這個網域中的伺服器例外」)→ 拒絕的順序推進。¹² Microsoft 也表示，在選擇拒絕選項之前，應先把對應的稽核原則設為相同選項來評估影響。¹²

「擋住 SMB 就等於 NTLM 對策完成」是不對的。若要當成完成的指標，請把 SMB 的例外清單與 Restrict NTLM 的伺服器例外清單兩者都清點。

9.2. 稽核期間不是用「天數」,而是用「業務跑完一輪」來決定

階段 1 最容易失敗的，就是期間的決定方式。若認定「收集了兩週就完成」,那兩週內沒有跑到的處理就不會列入清單。而沒有列入清單的東西，會在階段 6 發布封鎖之後才第一次壞掉。

不只是月次處理，連復原、離線電腦都要清查

具體來說，容易漏掉的是以下這些。

• 月次・季度的結算處理。月底批次以直接寫死的 IP 位址連線共用資料夾或資料庫，就是典型的例子。
• 年度處理。盤點、年度切換、決算相關作業。
• 只有故障時才會走的路徑。從備份復原的程序、切換到備援伺服器、DR 演練。
• 長期離線的電腦。外帶 PC、長假中的負責人的電腦、平常沒有開機的備用機。
• 一年只用幾次的業務應用程式。

等不了的話，就刻意執行低頻率的處理

Microsoft 的指南本身也表示，依部署的複雜程度不同，分析有可能長達數個月。³ 實際可行的界線是以下兩者之一。

1. 持續執行稽核，直到業務跑完一輪。至少跨過一次月結，可以的話跨過一季。
2. 清查低頻率的處理，並刻意執行它們。若等不了那麼久，就在驗證環境中跑一次結算處理或 DR 程序，把結果加進清單。重點在於先透過向負責人訪談，把「只是因為沒有執行才沒出現」的處理列舉出來。

無論哪一種情況，都請在能區分「沒有出現事件」與「還沒有執行」的狀態下，再進入下一個階段。

9.3. 不要一口氣切到拒絕

這裡的重點是不要一口氣把「傳送 NTLM 流量=全部拒絕」切下去。Microsoft 也表示，把這項原則設為拒絕會導致大量 NTLM 驗證要求失敗、可能降低生產力，因此應在實作前以「全部稽核」確認記錄檔、分析伺服器，並建立要排除的例外清單。⁷ 對於以整個網域為對象的「這個網域中的 NTLM 驗證」原則，也寫著相同的警告。¹²

10. 總結

• NTLM 已於 2024 年 6 月全版本列為已棄用。這不是會立即停止的變更，據稱在下一版 Windows Server、下一個年度發行版的 Windows 上仍會持續運作。¹
• 另一方面，NTLMv1 已經遭到移除(Windows 11 24H2 / Windows Server 2025)。只會說 NTLMv1 的裝置，以及記錄到 NTLM V1 的主機，是最近的期限。¹
• 廢除分三個階段，第一階段是稽核，第二階段(2026 年下半年)是 IAKerb 與本機 KDC,第三階段是預設停用。²
• 稽核是把三個原則切換為稽核模式，蒐集 Microsoft-Windows-NTLM/Operational。若是網域帳戶，依「DC 的 8004 → 成員伺服器的 8003 → 用戶端的 8001」順序，最終就能追到應用程式名稱。本機帳戶的驗證不會出現 8004,因此要從伺服器與用戶端的事件擷取。³⁷
• 經由 SMB 時，PID 永遠是 4(SYSTEM)。請先用事件記錄檔把範圍縮小到電腦，再用 ProcMon 追蹤那一台。³
• 大多數原因都是「名稱」。只要處理掉直接寫死 IP 位址與 SPN 未註冊，剩下的例外就會大幅減少。³²
• NET USE \\server\share /BLOCKNTLM 是不需要變更任何原則，僅憑一個連線就能佐證的最安全確認手段。⁴
• 自製應用程式要把直接指名 NTLM 的地方換成 Negotiate,並把連線目標的寫法統一改為 FQDN。⁵
• 例外清單不是解決方案，而是緩衝期。請以件數是否逐年減少作為指標。

相關文章

• 圖解NTLM與Kerberos ── 為什麼驗證會「回退」到NTLM
• 網路磁碟機與 UNC 路徑的陷阱 ── 業務應用程式處理檔案伺服器(共用資料夾)的實務
• 使用 Get-WinEvent 有效率地調查事件記錄 ── 篩選的速度決定調查所需的時間
• Process Monitor(ProcMon)實戰指南 ── 在10分鐘內找出「設定未被讀取」「ACCESS DENIED」的原因
• PowerShell Remoting(WinRM)入門 ── 一次管理多台 Windows
• PowerShell 中安全處理認證資訊 ── 把明文密碼逐出腳本
• 在 WinForms/WPF 應用程式中導入 Entra ID 驗證 ── MSAL.NET 與 WAM 代理的實務架構
• Windows 的 TPM 是什麼 ── 圖解「不讓金鑰外流的保險箱」與測量啟動

相關諮詢領域

合同會社小村軟體提供 NTLM 相依性盤點、遷移至以 Kerberos 為前提所需的業務應用程式改修，以及驗證相關的缺陷調查等服務。

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

參考連結

相關文章

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

相關主題

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

與本主題相關的服務

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

常見問題

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

NTLM 廢除之後，業務會從什麼時候開始停擺？

光是「已棄用(deprecated)」的公告本身，並不會讓任何東西停止運作。Microsoft 在 2024 年 6 月將 NTLM 的所有版本列為已棄用，但當時的說明是「NTLM 在下一版 Windows Server 與下一個年度發行版的 Windows 上仍會持續運作」。目前實際上已經停止運作的具體變更，是 Windows 11 版本 24H2 與 Windows Server 2025 中 NTLMv1 的移除。雖然已公布未來版本會將網路 NTLM 預設為停用的計畫，但即使到了那個時間點，仍可透過原則重新啟用。也就是說，這並非「某天突然全公司停擺」的變更，而是每次 OS 更新就會逐步收緊的變更。正因如此，與其等停擺後才調查，唯一實際可行的準備方式，就是趁 NTLM 還在運作時，透過稽核記錄盤點出相依之處。

要如何列出使用 NTLM 的位置？

把群組原則中「網路安全性: 限制 NTLM」系列的設定切換為稽核模式，並蒐集 NTLM/Operational 記錄檔。只要在網域控制站設定「稽核這個網域中的 NTLM 驗證」,並在伺服器與用戶端設定「稽核傳入的 NTLM 流量」與「傳送到遠端伺服器的 NTLM 流量=全部稽核」,事件檢視器的「應用程式與服務記錄檔 > Microsoft > Windows > NTLM」中就會記錄相關事件。若是網域帳戶的驗證，追蹤順序是:先用網域控制站的事件 8004 鎖定使用者與連線目標伺服器(安全通道名稱),再看該伺服器事件 8003 的處理程序識別碼(PID),最後用用戶端的事件 8001 確定「哪個應用程式，以哪個伺服器名稱」提出要求。事件 8001 中會包含目標伺服器名稱與用戶端處理程序名稱，追到這一步就能鎖定原因應用程式。不過，本機帳戶的驗證不會經過網域控制站，因此不會出現 8004。工作群組主機或檔案伺服器上以本機帳戶連線共用資料夾的路徑，必須從伺服器端的 8003 與用戶端的 8001 擷取。請不要只看網域控制站的記錄檔，就判斷「我們公司的量很少」。

稽核之後，事件的 PID 幾乎都是 4(SYSTEM),看不出是哪個應用程式。

這是因為通訊經由 SMB(共用資料夾)。SMB 的驗證是由核心模式的重新導向器進行，呼叫端的應用程式因而隱藏在 SMB 封包的另一側，事件中留下的 PID 永遠是 4(SYSTEM)。Microsoft 的指南也明確提到這種情況，並提出對策:在有出現事件的用戶端上執行 Process Monitor(ProcMon),以對方伺服器的電腦名稱與 IP 位址篩選路徑，再與伺服器端事件 8003 的時間戳記比對，藉此鎖定呼叫端處理程序。實務上，先用事件記錄檔把範圍縮小到「哪一台電腦」,再只針對那一台電腦執行 ProcMon,是最快的做法。

應該支援 Kerberos 的應用程式，為什麼還是會落回 NTLM？

大多是名稱的問題。Microsoft 的指南列舉了理論上支援 Kerberos、實際卻使用 NTLM 的應用程式，共有四種:可以選擇安全性組態或提供者的應用程式、SPN(服務主體名稱)未正確註冊的應用程式、因設定錯誤或廠商操作手冊而以 IP 位址(而非 DNS 名稱)連線的應用程式，以及舊有程式碼庫中仍殘留 NTLM 專用部分的應用程式。若事件 8001 的「目標伺服器」既不是 NetBIOS 名稱也不是 FQDN 格式(也就是 IP 位址),在預設組態下就不會使用 Kerberos。最先該做的兩件事，是把直接輸入的 IP 位址改成 FQDN,以及若是以別名存取，就替該名稱註冊 SPN。另外，若真的無法改成名稱，也備有在用戶端設定 TryIPSPN、手動註冊 IP 位址 SPN 的方法，不過 Microsoft 自己也表示這應僅限於無法改為 DNS 名稱的情況，終究只是最後手段。

自行開發的 Windows 應用程式，應該修正哪裡？

把在驗證套件中直接指名 NTLM 的地方，換成 Negotiate。Microsoft 明確表示「應用程式不應直接存取 NTLM 安全性套件，而應使用 Negotiate 套件」。Negotiate 會在 Kerberos 與 NTLM 之間擇一，除非參與驗證的系統中有一方無法使用 Kerberos,否則一律選擇 Kerberos。以 .NET 為例，典型的修正方式是把傳給 CredentialCache.Add 的驗證類型從 "NTLM" 改成 "Negotiate"(指定驗證類型的是 CredentialCache.Add,而不是 NetworkCredential 的建構函式)。同時，也需要把連線目標從 IP 位址或寫在 hosts 中的別名改為 FQDN 指定，若是要讓自製服務以 Kerberos 接受驗證，還需要替該服務帳戶註冊 SPN。

作者檔案

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

Go Komura

小村軟體有限公司 代表

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