如果你現在還在用 IP 直接連線、或者習慣靠 NAT 轉址 來做事，請注意：2026 年你的維運世界即將崩潰。微軟已經正式發出最後通牒：全面停用 NTLM 驗證協定。
這不是普通的更新，而是一場針對「連線習慣」的大肅清。如果你發現你的 網路磁碟機 (SMB) 突然連不上、遠端桌面 (RDP) 噴出錯誤、甚至連 事務機掃描 都不通了，不要懷疑，這就是微軟斬斷 NTLM 的後果。
核心因素：這是一場「認證實名制」的革命
這場災難的底層邏輯只有一個：驗證機制從 NTLM 強制轉向 Kerberos。
真相： Kerberos 認證需要票據，而票據中心不認得 IP 地址。
變革： 以前 Kerberos 連不上會自動降級用 NTLM 讓你通；2026 年後，微軟把這條後路封了。
當這條「湊合用」的老路被封死，如果你不重建架構、不理順 DNS，你的設備就會集體罷工。這不是帳號密碼錯了，而是連通訊隧道都蓋不起來。
2026 即將無法正常使用的五大服務
這場變革影響的不是單一軟體，而是所有依賴 Windows 認證的底層通道。只要你的連線路徑中包含「打 IP」或「跨網段 NAT」，以下服務將會集體罷工：
1. 網路磁碟機與 NAS (SMB 共享)
這是最核心的災區。
崩潰點： 習慣在檔案總管輸入 \\192.168.x.x 掛載磁碟機。
原因： SMB 協定在建立隧道時，會優先嘗試領取 Kerberos 票據。票據中心不認識 IP，而當 NTLM 回退機制（Fallback）被關閉後，Windows 會直接報錯「身分無法驗證」，連輸入帳密的機會都不給你。
2. 遠端桌面 (RDP)
MIS 的保命工具，現在成了最大的風險。
崩潰點： 使用 RDP 客戶端連線到內部伺服器 IP，或透過 NAT 轉址連入。
原因： 現代 RDP 預設開啟 NLA（網路層驗證）。NLA 要求在看到桌面之前就必須完成身分核實。沒有 DNS A 紀錄支撐的 Kerberos 驗證，RDP 會判定該連線「不具備身分可靠性」而強制中斷。
3. 多功能事務機 (MFP) 掃描
辦公室裡最難修的「隱形地雷」。
崩潰點： 事務機「掃描到資料夾」（Scan to Folder）功能。
原因： 大多數事務機的韌體老舊，底層只會講 NTLM（挑戰/響應）。當你的伺服器端（Windows 11/2025）拒絕 NTLM 時，這些機器因為不具備領取票據的邏輯，會直接噴出連線失敗。
4. 內網 SSO 網頁與 SQL 服務
崩潰點： 打開 ERP 網頁、Portal，或應用程式透過「Windows 整合驗證」連線資料庫。
原因： 瀏覽器與資料庫驅動程式在發現目標是 IP 地址時，會自動嘗試走 NTLM。當 NTLM 禁用且你沒有註冊 SPN（服務主體名稱），身分憑證就無法傳遞，導致 SSO 崩潰或資料庫拒絕登入。
5. Windows 排程工作 (Task Scheduler)
崩潰點： 定時執行的跨機備份腳本、自動化資料同步。
原因： 許多維運人員會用「網域帳號」來跑排程，並在路徑中指定目標 IP。這類行為在 2026 年後會因為無法進行「委託驗證（Delegation）」而失敗，導致任務在背景默默執行失敗。
微軟的「認證實名制」大變革
這場變革的核心因素，就是微軟要徹底終結那個「只要帳密對了，不管路徑安不安全都能通」的舊時代。
1. 認證邏輯的典範轉移
微軟的目標是將 Windows 驗證從 NTLM（挑戰/響應制） 全面轉向 Kerberos（票據制）。
舊時代（NTLM）： 像是在「對暗號」。它不看名字，只看你給的 Hash 對不對。這給了駭客（如 Relay 攻擊）巨大的空間。
新時代（Kerberos）： 像是在「領票據」。你必須先向票據中心（KDC）指名要找誰（SPN）。問題在於：KDC 不認識 IP 地址。如果你連線的對象是 IP，連線就會直接撞牆。
2. 重大技術變更：封鎖自動回退 (Fallback)
這是最致命的一刀。以前當 Kerberos 因為你打 IP 而失效時，Windows 會「貼心」地自動降級回 NTLM 讓你連通。但在 2026 年，微軟將預設關閉這個回退開關。
關鍵時間線：這不只是 2026 的事
微軟的肅清計畫是一場「溫水煮青蛙」：
2024 下半年 (Windows 11 24H2)： 引入「NTLM 審核模式」。
2025 年： 推出「預設禁用」測試版。引入 IAKerberos 與 Local KDC，強迫本機帳號也要開始學會「領票據」。
2026 年： 進入全面收網期。Windows Server 2025 的新安裝版本將預設禁用 NTLM。
在 NTLM 消失後的生存法則
面對 Kerberos 時代，解決問題的核心只有一個：讓你的連線對象擁有「真名」（Hostname），並讓票據中心認得它。
1. 完善 DNS A 紀錄：最簡單也最正統的方案
如果你沒有架設 AD 網域，做法是在你防火牆或內網 DNS 伺服器上建立 DNS A 紀錄：將 192.168.1.100 對應到 nas.office.local。這能讓 Windows 領取針對該網域名稱的 Kerberos 票據。
2. 建立 AD 網域：大型架構的唯一解
部署 Active Directory (AD) 是最徹底的解法。原理是 AD 本身就是最強大的 KDC（票據中心），無論是 SQL 還是網頁服務，都能獲得合法的身分證明。
3. Local KDC 與 IAKerberos：微軟給的「緩衝墊」
做法是讓本機帳號也能領票。但這這非常依賴 主機名稱（Hostname） 的解析。如果你還在用 IP 連線，這個緩衝機制完全幫不了你。
4. WebDAV：救回那些「不講理」的老設備
如果設備實在太舊不支援 Kerberos，做法是改用 HTTPS (Port 443) 封裝的 WebDAV。走的是 Web 驗證邏輯，對 NTLM 的依賴度較低。限制是傳輸效能略遜於原生 SMB。
必須廢棄的服務：為什麼 NAT 轉址即將終結？
在 NTLM 時代，我們習慣靠「穿牆術」（將 33890 轉發到內網的 3389）來辦事。這種做法在 2026 年會徹底失效。
致命傷是 SPN 名分不符。當你從外網打 office.ddns.net 連入時，內網電腦不認得你這張給外網名的票。以前 NTLM 密碼對就讓過；現在名字對不上，就是身分冒用。即便設了 DDNS，NAT 直連在 2026 年依然會掛掉。
VPN 的強制性：回歸內網才是唯一活路
我們唯一的選擇就是「拆牆」，讓你的電腦真正進入內網。VPN 不再是「進階功能」，而是 2026 年維運的「標配」。沒有 VPN，你的 RDP、SMB、ERP 通通都回不了家。
FortiGate 用戶的雙重夾擊
如果你是 Fortinet 的擁護者，這場變革來得比別人更猛烈。
1. SSL-VPN 的正式終結
從 FortiOS 7.6.3 開始，Fortinet 已經明確表態：全面移除 SSL-VPN 門戶功能。這意味著過去熟悉的「網頁撥接、Port 443 轉址」徹底走入歷史。
2. 當「沒門可入」撞上「身分不詳」
這就是雙重災難：通道端沒了 SSL-VPN（被迫走 IPsec VPN），認證端沒了 NTLM（被迫走 Kerberos）。
面對微軟與 Fortinet 的雙重清算，你的唯一活路只有一套「組合拳」：
放棄 Fortinet SSL-VPN
放棄 NAT 轉址
回歸 DNS 基礎
觀看完整影音解說：https://youtu.be/HfRzHNyKUs4
沒有留言:
張貼留言