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

「聽說 NTLM 要被廢除了,我們公司沒問題吧？」──自從 Microsoft 在 2024 年 6 月宣布將 NTLM 的所有版本列為已棄用(deprecated)以來,收到這類問題的機會愈來愈多。答案是,只要調查就能知道有沒有問題,而且現在調查還來得及。

NTLM 的廢除,並不是「某天套上修補程式,全公司就停擺」這種變更。它是每次 OS 更新就逐步收緊的變更,而且唯有在 NTLM 還在運作的現在,才能安全地盤點出「自家哪些地方相依於 NTLM」。先把一切都停掉,再去找損壞的地方,是最不該採用的順序。

本文將重點放在建立這份清單並逐一消除的實務步驟。至於協定機制本身(為什麼 NTLM 危險、為什麼會落回 NTLM),則交給對應的另一篇文章「圖解讀懂 NTLM 與 Kerberos ── 為什麼驗證會「落回」NTLM」。

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 章)。⁵

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 則不做這樣的假設。這個差異,正是讓攻擊者能誘導受害者把認證資訊送往偽造伺服器的中繼攻擊得以成立的條件。
• 伺服器每次都要向網域控制站查詢(網域帳戶的情況)。在 NTLM 中,應用程式伺服器每次驗證網域帳戶的用戶端時,都必須連線到網域控制站(若是伺服器本機的帳戶,則由伺服器查閱自己的帳戶資料庫來判斷)。⁶ 在 Kerberos 中,可更新的工作階段票證取代了這種傳遞驗證,除非需要驗證 PAC(特殊權限屬性憑證),否則伺服器不需要連往網域控制站。
• 驗證材料本身就是密碼的雜湊值。NTLM 的認證資訊,是由網域名稱、使用者名稱、密碼的單向雜湊值所組成,用戶端會用這個雜湊值加密挑戰碼並回傳回應。⁵ 由此衍生出的特性是:只要竊取雜湊值,即使不知道明文密碼也能冒充身分。

「沒有相互驗證」在實務上的意義是:光是嘗試連線到 SMB 共用,就可能把認證資訊交給偽造的伺服器。Microsoft 之所以準備了 SMB 用戶端側的 NTLM 封鎖功能,說明中也提到是為了「防止讓惡意伺服器誘導使用者送出 NTLM 要求的手法」。⁴

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

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

4.1. 啟用稽核模式

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

不過,「不需要重新啟動」和「立刻對所有機器生效」是兩回事。若透過網域的 GPO 發布,GPO 儲存的當下只會更新 AD/SYSVOL 上的原則,各終端實際開始稽核,要等到下一次背景更新,或是執行 gpupdate /force 之後。稽核期間的起點,請以「套用擴及目標終端的日期時間」計算,而不是「GPO 儲存的日期時間」。若把這一點搞錯,結果就會以「第一次彙整時對象台數偏少」的形式出現偏差。

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

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

實務上最容易搞錯的,是「在哪一台機器上設定哪一個原則、要看哪一個事件」的對應關係。以下把上表的三個原則標為①②③,整理成檢查清單。

無論哪一台機器,記錄檔都是同一個 Microsoft-Windows-NTLM/Operational。①只對網域控制站有效,而忘記設定②③的終端,並不是「沒有使用 NTLM 的終端」,而是「沒有記錄下來的終端」。這個差異,是造成統計失真的最大原因。

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

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

如何解讀蒐集到的事件,有一套固定的順序。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。³

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

4.3. 用 PowerShell 彙整

用事件檢視器的 GUI 逐一檢視數千筆事件並不切實際,因此改用 Get-WinEvent 彙整。首先確認這台機器上,各事件各出現了多少筆。

# 依 ID 彙整 NTLM/Operational 的事件(以系統管理員權限執行)
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 } }

確認有事件出現後,把用戶端的 8001 依「連線目標伺服器 × 呼叫端處理程序」彙整。由於事件的欄位結構因事件 ID 而異,先用 Format-List 開啟 1 筆確認結構之後,再決定要用哪個索引,才是安全的做法。

# 先只確認 1 筆的內容
$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'

確認結構之後,用 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

最後的彙整結果會回傳兩欄: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 位址的行是否排在前面」「已經查到執行檔名稱的行有多少」。前者是只要修正就必定會減少的相依,後者則是可以指派負責人的相依。

由於欄位名稱會因 OS 版本而有差異,這裡採用把候選項目排成有優先順序的陣列,只挑實際存在的項目這種做法。此時若使用 -match 'Process' 這類部分比對,連 ClientProcessId 這種 PID 欄位都會被抓進來,有時會導致不是用執行檔名稱、而是用每次都會改變的 PID 來彙整(由於雜湊表的鍵順序不固定,取到哪一個也不穩定)。若 Process 欄全部變成空白,就是候選名稱與實際結構描述不符的訊號,請把前面步驟中確認到的名稱加進陣列。

如果要從多台機器蒐集,用 PowerShell Remoting 平行執行會比較快(「PowerShell Remoting(WinRM)入門」)。Get-WinEvent 的篩選,是否使用 -FilterHashtable 會讓所需時間有數量級的差異,這方面的訣竅整理在「用 Get-WinEvent 實務調查事件記錄檔」中。

4.4. 從安全性記錄檔角度查看 ── 確認是否仍在使用 NTLMv1

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

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

這個「套件名稱 (僅限 NTLM)」欄位,顯示的是 NTLM 協定家族中實際使用了哪一個子協定。³ 出現 NTLM V1 的主機,若直接升級到 Windows 11 24H2 / Windows Server 2025,就是驗證會失敗的候選對象。因為 NTLMv1 已在這些版本中移除。¹ 執行稽核時,請將這個觀點的優先順序調高來挑選。

4.5. PID 幾乎都是 4(SYSTEM),無法繼續追查時

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

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 未註冊、對信任關係對象的驗證,以及工作群組環境中的驗證。²

把這些整理成實務現場常見的樣態,就是下面這張表。右側兩欄是用來排定優先順序的基準。「影響範圍」表示一旦停擺會造成困擾的廣度,「修正容易度」表示是否僅憑自家的判斷就能修正。只要掌握這兩欄,就能直接轉換成計畫書的著手順序。

著手順序,可以機械式地從這兩欄推導出來。

1. 不論影響範圍大小,最優先的都是只能使用 NTLMv1 的機器,以及記錄到 NTLM V1 的主機(4.4 節)。唯獨這一項,因為「期限已經到了」,所以要排除在優先度計算之外。¹
2. 接下來是影響範圍=大 且 修正容易度=高,也就是直接輸入 IP 位址的情況。件數多,且僅憑自家判斷就能修正。請把最初的一個月集中在這裡。
3. 再來是修正容易度=中的 SPN 相關項目。與統一名稱一併推進。
4. 修正容易度=低的項目(機器相依、路徑、等待第二階段)並不是要延後著手,只是前置時間比較長,因此洽詢廠商與編列預算這兩件事,要與 1〜3 並行、先開始進行。

分類為「可以立刻修正」與「註冊 SPN 即可修正」的項目,應該會占稽核結果的大半。只要處理掉這些,剩下的例外就會大幅減少。

6. 修正方式判斷表

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

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

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

前提條件有以下兩項。⁴

• 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 的地方。在完全不變更任何原則的情況下,就能逐一連線確認「在正式環境是否會停擺」,很適合用來佐證稽核記錄檔。

確認結果的地方有三處。(1)連線是否成功就看指令本身的結果,成功的話會建立對應,並出現在 net use 的清單與 Get-SmbConnection -ServerName <伺服器名稱> 中,失敗的話則以錯誤結束,不會留下對應。(2)是否真的是 NTLM 造成的,要與下面步驟 3(不加旗標連線)搭配判斷。若不加旗標也失敗,那就是別的問題。(3)若想確定究竟是用什麼進行驗證,請使用本節最後說明的方法(klist 與伺服器端的安全性記錄檔)。請不要只憑錯誤訊息的文字內容,就斷定是相依 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 伺服器」,但連線目標的 OS 只要能使用 PKU2U 也可以。⁴ 也就是說,成功的原因仍有可能不是 Kerberos,而是 PKU2U。若對象是已加入網域的檔案伺服器,基本上不會構成問題,但若想確定實際上究竟是用什麼驗證的,請在連線後於用戶端執行 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 文件中所附的範例,在值尚不存在的分支中,只設定了 @(""),結果原本想新增的項目就這樣被丟棄了。⁴ 因此會出現第一次執行沒有加入任何例外、要到第二次執行才終於加入的行為。上面的程式碼中,即使是尚未建立的情況,也會把要新增的對象直接寫入。話雖如此,這個登錄值原本就是由群組原則管理的範圍。永久性的例外請在群組原則端管理,這裡的操作請僅限於緊急狀況下的臨時應對。下一次原則套用時就會被覆寫。

注意: 這項功能是SMB 用戶端側的功能。⁴ SMB 以外路徑(自家應用程式的 HTTP 通訊、連線到 SQL Server、WinRM 等)上的 NTLM,無法靠這項功能封鎖。這些必須依照第 5 章的分類,逐一個別處理。

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,可以使用 .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 的 Windows 驗證預設會啟用核心模式驗證,此時負責解密 Kerberos 票證的並非應用程式集區的識別身分,而是HTTP.sys 所使用的電腦帳戶。就算應用程式集區是以專用網域帳戶執行,若把網站的 HTTP SPN 註冊在該帳戶上,就會導致SPN 的擁有者與實際負責解密的帳戶不一致,結果不只是落回 NTLM,連驗證本身都會因 KRB_AP_ERR_MODIFIED 而失敗。

重點在於「讓 SPN 的註冊對象,與負責解密票證的識別身分保持一致」。可以採用的做法有以下兩種。

• 以電腦帳戶解密(維持預設):若網站是以主機名稱對外公開,就把該主機名稱的 HTTP SPN 註冊在電腦帳戶上。
• 以應用程式集區的識別身分解密:在啟用 useAppPoolCredentials 之後,把 HTTP SPN 註冊在應用程式集區的帳戶上。

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

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

9. 分階段收緊的路線圖

綜合以上內容,推進的順序如下。每個階段的前提都是「可以復原」。

9.1. 就算封鎖了 SMB,也只是 NTLM 對策的一半

第四〜六階段處理的僅有 SMB。如第 7 章所述,SMB 用戶端的 NTLM 封鎖是 SMB 用戶端側的功能,⁴ 對其他路徑沒有效果。在第二階段被分類為「用 HTTP 驗證」「SQL Server 落回 NTLM」「WinRM 使用 NTLM」的項目,即使推進到第六階段,依然會原封不動地殘留。而且這些也不會列入 SMB 的例外清單,因此就算統計數量也看不見。

負責收緊這一塊的就是階段 6b。使用的正是在第 4 章切換為稽核模式的那三個原則。步驟依循相同的形式。¹¹

1. 維持「傳送到遠端伺服器的 NTLM 流量」為全部稽核,篩查出仍然存在的連線目標
2. 把無論如何都需要的對象,登記到「新增遠端伺服器例外」
3. 在試點終端切換為全部拒絕,等待業務跑完一輪
4. 若沒有問題就展開部署

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

並不是「封鎖了 SMB,NTLM 對策就完成了」。若要當作完成的指標,請同時統計 SMB 的例外清單與 Restrict NTLM 的伺服器例外清單兩者。

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

第一階段最容易失敗的地方,就是期間的決定方式。若以「已經蒐集了兩週,所以完成了」草率結案,那兩週內沒有跑到的作業就不會列入清單。而沒有列入清單的項目,要等到第六階段部署封鎖之後才會第一次壞掉。

具體來說,容易被遺漏的項目如下。

• 月結、季結作業。典型的例子是月底批次作業以直接輸入 IP 位址的方式連線共用資料夾或資料庫。
• 年度作業。盤點、年度切換、決算相關。
• 只有故障時才會走到的路徑。從備份還原的程序、切換到替代伺服器、DR 演練。
• 長期離線的終端。外借出去的電腦、長期休假中負責人的終端、平常沒有開機的備用機。
• 一年只用幾次的業務應用程式。

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