重新啟動後就能存取共用資料夾，是否代表快取是原因？

光憑這點無法確定。重新啟動會一起改變應用程式、登入工作階段、SMB 連線與網路狀態等條件。重新啟動前應記錄目標、執行身分、既有連線、票證及錯誤，再與成功時比較。已儲存的認證資訊和已建立的 SMB 連線是不同的東西。

為何使用 IP 位址能開啟共用資料夾，使用伺服器名稱卻不行？

先確認兩種寫法是否連到相同的目標 IP。即使 IP 相同，驗證條件也不一樣：Windows 預設不會對 IP 位址目標嘗試 Kerberos。應分別檢查名稱解析、SPN 與驗證問題，不能只因 IP 連線成功就把它當成長期解法。

為何檔案總管能開啟共用資料夾，應用程式卻不能？

執行帳戶、登入工作階段、權限提升狀態、使用的認證資訊或操作可能不同。服務與互動式登入處於不同工作階段。使用者名稱相同不代表條件一致，應檢查失敗處理程序本身的資訊及伺服器端的驗證記錄。

連線時沒有輸入密碼，就是來賓連線嗎？

只看沒有出現密碼提示，無法判斷。可能使用目前的登入認證資訊、已儲存的認證資訊或既有 SMB 連線。空白密碼的本機帳戶與來賓連線也不同，需要確認伺服器實際接受哪個帳戶。

klist 有 cifs 票證，就表示 SMB 使用 Kerberos 連線嗎？

持有票證與在這次 SMB 連線中使用票證，是兩件事。應依連線時間、來源及帳戶比對伺服器記錄。klist get 會提出新的票證要求，不是單純觀察原始狀態的命令。

Windows 共用資料夾為何時而能連線、時而失敗——釐清 Kerberos、NTLM 與認證資訊問題

2026年09月08日 09:00 · 更新日期: 2026年09月09日 · Go Komura · Windows, SMB, Kerberos, NTLM, 共用資料夾, 疑難排解

「昨天還能開啟。」「檔案總管能開啟，應用程式卻失敗。」「重新啟動後又好了。」當每次操作看起來都一樣時，共用資料夾的問題反而更難調查。

即使以為每次開啟的都是同一個共用資料夾，只要目標名稱、執行帳戶或既有連線不同，Windows 進行的處理就不一定相同。找出這些差異，是調查的起點。

本文整理了檢查命令、結果的判讀方式，以及下一步調查方向，而不是只憑症狀斷定原因。Kerberos 與 NTLM 協定本身的原理，請參閱 NTLM 與 Kerberos 詳解；應用程式設計方面，請參閱網路磁碟機與 UNC 路徑的常見問題。

1. 先看結論與症狀索引

調查順序是：能否連到目標 → 以誰的身分連線 → 有哪些驗證與保護條件 → 該身分是否有權執行目標操作。對成功與失敗的嘗試，以相同格式記錄這些條件。症狀是調查入口，不是已確認的原因。

症狀	優先確認	對應章節
名稱與 IP 的結果不同	實際目標 IP，以及使用名稱的驗證條件	通訊、Kerberos
只有檔案總管成功	應用程式的執行身分、工作階段與操作	執行條件
看起來不需要密碼	共用伺服器實際接受的帳戶	認證資訊
換使用者後無法連線，或出現 1219	到同一伺服器的既有連線	連線衝突
重新啟動或登出後恢復	變更前後的狀態差異	重新啟動
更新後、部分 PC 或 NAS 才失敗	簽章、來賓與 NTLM 的實際生效設定	保護條件
可以開啟但無法儲存	目標操作的權限與原始錯誤	權限與應用程式

flowchart TB
    accTitle: 從症狀進入證據的診斷流程
    accDescr: 根據症狀選擇可能原因，比較成功與失敗時的證據，再決定處理方式。
    symptom["選擇症狀"] --> compare["比較成功與失敗"]
    compare --> evidence["透過記錄縮小範圍"]
    evidence --> fix["逐項處理並重新確認"]

圖1：以症狀作為調查入口，確認證據後才決定處理方式。

本文適用於 Windows 11 與 Windows Server 的 SMB 2/3 共用，以及一般 TCP 445 連線。PowerShell 範例以 Windows PowerShell 5.1 為前提。這是面向管理員與開發者的中級文章，但無權管理共用伺服器的讀者，也可以先收集用戶端資訊。

請區分 AD 網域、工作群組內的 Windows 共用，以及 NAS 自有帳戶。本文處理常見的 AD Kerberos 與傳統本機帳戶設定，不涵蓋 SMB over QUIC、Azure Files 特有的驗證，也不討論 IAKerb、LocalKDC 的個別設定。使用 DFS 時，也要記錄最後連到的伺服器。設定與預設值依據截至 2026 年 9 月 8 日已確認的官方資料；應優先確認實際設定，而不是只根據作業系統名稱推測。

首先確認共用伺服器設定為接受哪些帳戶。 AD 用來集中管理組織帳戶，本機帳戶則由各台 PC 分別持有。NAS 可以使用自有帳戶，也可以加入 AD。不要只憑產品名稱或所在位置，就認定「公司區域網路一定用 Kerberos」或「NAS 一定用 NTLM」；應向管理員確認驗證設定。¹²³

登入共用時使用的帳戶	優先調查方向
AD 網域帳戶	確認通訊後，檢查名稱、SPN 與票證，以及驗證記錄
Windows 共用伺服器的本機帳戶	先檢查使用的認證資訊與空白密碼、既有連線和保護條件
NAS 自有帳戶	檢查 NAS 的帳戶設定、驗證記錄，以及來賓、簽章與 NTLM 限制
不確定是哪一種	保存用戶端記錄，並確認伺服器實際接受的帳戶

「PC 是否加入網域」與「這次使用哪些認證資訊」也是兩件事。下文的 CORP\alice 是網域帳戶範例，FILESRV01\alice 則是共用伺服器本機帳戶的範例。自己的 PC 有同名使用者，不代表該使用者在共用伺服器上具有相同權限。⁴⁵

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

2. 將「無法連線」分成不同階段

開啟檔案前，需要建立通訊、交涉 SMB 條件、驗證工作階段、連接共用，然後執行檔案操作。驗證成功並不代表具有共用或檔案的存取權。此外，「找不到網路路徑」也可能與來賓連線遭拒有關。不要只憑顯示的文字，就斷定是 DNS 故障。⁶⁷

flowchart TB
    accTitle: 開啟共用檔案前的各個階段
    accDescr: 通訊、SMB 條件交涉、驗證、共用連接及檔案操作都可能分別失敗。
    net["名稱解析與 TCP 連線"] --> negotiation["交涉 SMB 條件"]
    negotiation --> session["SESSION_SETUP：驗證"]
    session --> tree["TREE_CONNECT：共用"]
    tree --> file["CREATE 等檔案操作"]

圖2：前一階段成功，不能證明下一階段也會成功。

這裡的「成功」是指能對目標檔案執行目標操作。在檔案總管的「網路」中看到 PC 名稱、看到共用清單、讀取某個檔案，並不是同一回事。調查時應記錄實際失敗的 UNC 路徑與操作，而不只是清單是否顯示。

3. 重新啟動或變更設定前，先留下記錄

一開始就刪除連線或票證，會讓原本要比較的狀態消失。先在用戶端記錄時間、UNC 路徑、使用者、作業系統與既有連線。以下命令用來查看狀態。調查服務故障時，不可將這個互動式終端機的結果當成服務本身的結果。⁴⁸⁹

Get-Date -Format o
whoami /user
whoami /groups
Get-CimInstance Win32_OperatingSystem |
    Select-Object Caption, Version, BuildNumber
net use
cmdkey /list
klist

在有權查詢 SMB 連線的終端機上，也收集以下資訊。若出現拒絕存取，應記錄為「無法查詢」，而不是「沒有連線」。改用管理員身分重新收集的結果，要清楚註明執行條件。未經說明就將整個調查改為提升權限的環境，可能改變正在比較的登入工作階段。⁴¹⁰

Get-SmbConnection | Format-List *

記錄	能確認什麼	單憑它無法確認什麼
`whoami`	該命令在本機的執行身分	共用伺服器接受的帳戶
`net use`	目前執行環境中可見的共用連線與對應	其他工作階段的連線狀態
`cmdkey /list`	哪些目標已儲存認證資訊	這次是否使用了該認證資訊
`Get-SmbConnection`	已建立的連線、認證資訊等屬性	連線失敗的完整經過，或最終採用的驗證協定
`klist`	目標登入工作階段持有的票證	本次 SMB 連線實際使用的驗證協定

查看 Get-SmbConnection 時，除了 UserName，也要確認 Credential。本機登入身分與連接共用時使用的認證資訊，可能不一致。並排比較成功與失敗時的 ServerName、ShareName、UserName 和 Credential，比較容易確認是否正在比較相同連線。⁴

flowchart TB
    accTitle: 已儲存的資訊與正在使用的狀態
    accDescr: 分別觀察已儲存的認證資訊、SMB 連線與 Kerberos 票證。
    snapshot["在同一時間記錄"] --> stored["已儲存的認證資訊"]
    snapshot --> connection["已建立的 SMB 連線"]
    snapshot --> ticket["票證快取"]
    stored -.-> verify["比對記錄確認實際使用情況"]
    connection --> verify
    ticket -.-> verify

圖3：區分已儲存的內容，以及問題連線實際使用的內容。

這些輸出包含使用者名稱、內部伺服器名稱、IP 位址等資訊。應限制記錄的存取範圍；對外提供時，進行匿名化並保留比較所需的對應關係。不需要公開密碼、雜湊或票證本身。

4. 先檢查名稱解析與 TCP 445

以下是在用戶端執行的主動通訊測試。請將伺服器名稱換成實際使用的連線名稱，並分別記錄名稱解析與 TCP 連線結果。¹¹

$Server = 'filesrv01.corp.example.com'
Resolve-DnsName -Name $Server
Test-NetConnection -ComputerName $Server -Port 445 -InformationLevel Detailed

若 TcpTestSucceeded 是 False，此時應先調查驗證之前的可達性。檢查目標 IP、VPN 與路由、用戶端及伺服器的防火牆，以及伺服器是否正在接聽。ping 的成敗不等於 TCP 445 的成敗。反過來，即使 TCP 成功，共用名稱、驗證、簽章與權限也仍未確認。¹¹

flowchart TB
    accTitle: 如何解讀 TCP 連線測試
    accDescr: TCP 445 失敗時檢查可達性，成功後繼續檢查 SMB 與後續階段。
    tcp["測試 TCP 445"] --> result{"是否成功"}
    result -->|"否"| route["檢查目標、路由與阻擋"]
    result -->|"是"| smb["檢查 SMB、驗證與權限"]

圖4：TCP 成功不代表驗證成功，只表示可以繼續檢查下一階段。

名稱與 IP 的結果不同時，比較 RemoteAddress 與名稱解析結果。短名稱、FQDN、別名不一定連到相同 IP。即使 IP 相同，下一節的驗證條件仍需另外確認。若更換名稱後看似「修好了」，也要留下究竟改變了什麼的記錄。

5. 名稱與 IP 表現不同時，檢查 Kerberos 的前提

5.1. 相同 IP 不代表相同驗證

Windows 預設不會在目標名稱為 IP 位址時嘗試 Kerberos。雖然可以透過 TryIPSPN 與 IP 型 SPN 設定例外，本文的標準處理方向仍是建立正確的 DNS 名稱與服務識別。以 IP 連線成功，是比較名稱解析、驗證及既有連線的線索，不是長期解法的證明。¹²

flowchart TB
    accTitle: 連線名稱造成的驗證條件差異
    accDescr: 使用主機名稱時確認 Kerberos 服務名稱條件，使用 IP 時注意預設不嘗試 Kerberos 的行為。
    unc["UNC 的目標寫法"] --> name["主機名稱或 FQDN"]
    unc --> ip["IP 位址"]
    name --> spn["檢查名稱對應的 SPN"]
    ip --> fallback["預設不嘗試 Kerberos"]

圖5：即使指向同一台裝置，連線名稱改變後，驗證條件也會改變。

Kerberos 以稱為 SPN 的服務識別名稱要求票證。DNS 能解析別名，與能否正確驗證該別名的服務，是兩件事。此外，不是每一種 Kerberos 失敗都會退回 NTLM。需要從實際記錄區分是否能退回其他協定、發生了何種驗證錯誤，以及 NTLM 是否受到限制。¹³¹

5.2. 分開確認取得票證與伺服器接受票證

AD 環境的管理員應調查連線名稱的 SPN 註冊對象。以下是在可查詢 AD 的管理終端機上執行的唯讀範例。執行前，確認具有查詢權限與必要的管理工具。¹⁴

setspn -Q cifs/filesrv01.corp.example.com
setspn -Q HOST/filesrv01.corp.example.com

不能只因沒有明確註冊 cifs/...，就斷定缺少 SPN。對電腦帳戶而言，HOST SPN 可以代替 cifs 等服務類別。反過來，即使已有註冊，也可能註冊到不是實際服務身分的帳戶，或存在重複註冊。應由 AD 管理員確認歸屬後變更，不要因為查不到就機械式地新增。¹⁴

flowchart TB
    accTitle: SPN 與票證檢查的範圍
    accDescr: SPN 解析、取得票證，以及共用伺服器接受票證，必須分別確認。
    lookup["SPN 歸屬與 HOST 代替"] --> issue["能否取得票證"]
    issue --> accept["實際 SMB 驗證是否接受"]
    accept --> logs["比對伺服器端記錄"]

圖6：能取得票證，並不保證共用伺服器會接受它。

必要時，保存原始狀態後再測試 klist get cifs/filesrv01.corp.example.com。這會提出新的票證要求並改變快取，屬於主動測試。失敗時，檢查 DC 可達性、時間同步、名稱與 SPN；成功也不代表 SMB 存取一定成功。同樣要注意，不可將互動式使用者的票證結果套用到服務的問題。⁸¹

沒有網域的 NAS 或使用本機帳戶驗證時，應先確認共用支援的驗證方式與帳戶設定，而不是先嘗試修復 AD SPN。即使環境包含較新的驗證功能，也應優先查看連線記錄，不根據產品名稱猜測使用方式。

6. 檔案總管能開啟，應用程式卻不能

6.1. 使用者名稱相同，不代表條件相同

需要比較執行帳戶、登入工作階段、是否提升權限、UNC 路徑與操作。服務即使設定成同一使用者帳戶，也會在不同於互動式登入的工作階段執行。磁碟機代號的對應同樣以登入工作階段為單位，因此先區分 Z:\data 與 \\server\share\data。改用 UNC 是解決磁碟機代號問題的方法，不會同時授予驗證能力或存取權。¹⁰

flowchart TB
    accTitle: 檔案總管與服務的差異
    accDescr: 即使在同一台 PC，互動式登入與服務也必須分別比較工作階段及認證資訊。
    pc["同一台 PC"] --> explorer["互動式登入"]
    pc --> service["服務登入"]
    explorer --> a["該工作階段的連線與權限"]
    service --> b["另一工作階段的連線與權限"]

圖7：同一台 PC、相同使用者名稱，不代表共用同樣的連線狀態。

讓失敗的應用程式記錄處理程序 ID、執行身分、權限提升狀態、實際路徑、操作名稱、原始例外與錯誤碼。使用模擬身分時，也應記錄執行該操作之執行緒的有效身分。不能只因為管理員 PowerShell 能開啟，就結束對服務的調查。

6.2. 服務帳戶與工作的登入類型

服務使用預設認證資訊時，LocalSystem 會在網路上提供電腦的認證資訊，LocalService 則提供匿名認證資訊。在網域環境中允許 LocalSystem 存取共用時，應檢查電腦帳戶等實際使用身分的權限，而不是互動式使用者。若實作使用明確指定的認證資訊或模擬身分，則要另外確認這些條件。¹⁵¹⁶

flowchart TB
    accTitle: 本機權限與遠端身分
    accDescr: 使用預設網路認證資訊時，LocalSystem 與 LocalService 提供的身分不同。
    service["服務的預設認證資訊"] --> system["LocalSystem"]
    service --> local["LocalService"]
    system --> machine["電腦的認證資訊"]
    local --> anonymous["匿名認證資訊"]

圖8：本機上具有高權限，不代表共用伺服器會把服務當成互動式使用者。

在工作排程器中，除了帳戶名稱，也要檢查登入方式。TASK_LOGON_S4U 不儲存密碼，也不提供網路或加密檔案的存取能力。不要把設定成「不要儲存密碼」的工作，視為與一般互動式登入條件相同。業務處理應使用適當的服務帳戶、登入方式及最小權限，不應依賴每次先在檔案總管開啟共用資料夾。¹⁷

7. 將「不輸入密碼也能存取」分成四種情況

沒有出現輸入提示，不代表未經驗證。可能正在使用目前的登入認證資訊、已儲存的認證資訊，或已建立的 SMB 工作階段。僅在 cmdkey /list 看到項目，也不能斷定這次使用了它。⁴⁹

表面現象	應確認的實際情況
沒有輸入密碼	是否使用登入或已儲存的認證資訊完成驗證
之前驗證過，這次沒有再詢問	是否重複使用既有 SMB 工作階段
共用伺服器的本機帳戶沒有密碼	是否適用空白密碼限制
共用伺服器以來賓身分接受	來賓連線是否符合簽章與加密條件

flowchart TB
    accTitle: 沒有密碼提示的意義
    accDescr: 不從提示畫面判斷是否未經驗證，而是區分認證資訊、既有工作階段、空白密碼帳戶與來賓。
    prompt["沒有顯示密碼輸入畫面"] --> identity["確認實際接受的身分"]
    identity --> authenticated["認證資訊或既有工作階段"]
    identity --> blank["空白密碼的帳戶"]
    identity --> guest["來賓"]

圖9：畫面相同，背後的驗證機制卻可能不同。

共用伺服器執行 Windows，且該伺服器啟用「限制使用空白密碼的本機帳戶僅能登入主控台」原則時，會限制空白密碼本機帳戶的一般網路登入。這與允許來賓的設定不同。若有人說「帳戶沒有密碼，但以前能連」，應先在伺服器上確認：之前真的以該帳戶完成驗證嗎？不要先停用限制，應考慮使用有密碼且權限適當的共用存取帳戶。²³

若有權管理 Windows 共用伺服器，請在存取仍成功時，於該伺服器的管理員 PowerShell 執行以下查詢。不要混淆在用戶端執行的 Get-SmbConnection，以及在接受連線的伺服器端執行的 Get-SmbSession。¹⁸

Get-SmbSession |
    Select-Object SessionId, ClientComputerName, ClientUserName, NumOpens

依 ClientComputerName 與嘗試時間找出目標工作階段，再確認 ClientUserName。這是目前已建立之 SMB 工作階段的資訊，無法說明過去連線失敗的原因，也不能判定使用 Kerberos 還是 NTLM。相同用戶端有多個工作階段時，也要比對應用程式的操作時間與 SMB 專屬記錄。若連線已中斷，請繼續查看第12節的記錄。¹⁸

8. 1219 與換使用者後無法重新連線

錯誤 1219 表示到相同伺服器的多個連線使用不同使用者名稱，因而發生衝突。即使共用名稱不同，既有的伺服器連線仍可能相關。先以 net use 和 Get-SmbConnection 查看目標伺服器的連線，更換認證資訊前，確認開啟中的檔案及使用中的應用程式。¹⁹²⁰

flowchart TB
    accTitle: 不同共用也可能產生認證資訊衝突
    accDescr: 從相同連線環境以另一使用者新增到同一伺服器的連線，即使共用名稱不同也可能衝突。
    existing["已以使用者 A 連到伺服器"] --> new["以使用者 B 連到另一共用"]
    new --> conflict["認證資訊衝突：1219"]
    conflict --> inspect["以伺服器為單位檢查既有連線"]

圖10：除了共用名稱，也要看目標伺服器與認證資訊的組合。

以下是會變更連線狀態的操作。只有在停止使用目標，並取得影響範圍的核准後，才針對實際確認的連線中斷並重連。請替換範例中的伺服器、共用與帳戶名稱。* 會提示互動式輸入密碼，不要直接把密碼寫在命令列。⁵

net use "\\filesrv01.corp.example.com\data" /delete
net use "\\filesrv01.corp.example.com\data" /user:CORP\alice * /persistent:no

中斷一個共用後，同一伺服器仍可能有其他共用或其他用途的連線。再次確認清單，只清理目標伺服器上必要範圍的連線。不要把 net use * /delete 的全面刪除，或持續用別名、IP 避開衝突，當成標準處理方式。完成後，應確認原本的應用程式能用預期的認證資訊連線。

9. 重新啟動後恢復時，找出改變了什麼

重新啟動會改變多個狀態，因此無法僅從恢復正常的結果反推單一原因。下表是調查時的比較面向，不保證各項操作必然只重設所列範圍。⁴⁸⁹

操作或資訊	比較時的注意事項
重新啟動應用程式	應用程式狀態改變，但作業系統的共用連線可能仍在
中斷並重連目標共用	檢查是否重新連線與驗證，以及是否還有其他連線
登出或重新啟動作業系統	工作階段、應用程式、網路等多項條件一起改變
已儲存的認證資訊	與已建立的連線不同，通常不會只因作業系統重新啟動就刪除

flowchart TB
    accTitle: 如何解讀重新啟動後的恢復
    accDescr: 重新啟動會改變多個條件，不能只從恢復正常就判定單一原因。
    reboot["重新啟動後恢復"] --> app["應用程式狀態"]
    reboot --> session["連線與登入狀態"]
    reboot --> network["網路等狀態"]
    app --> evidence["需要變更前後的證據"]
    session --> evidence
    network --> evidence

圖11：重新啟動可以是恢復手段，但本身不是原因的證明。

舉一個假設案例：成功時已存在以另一帳戶建立的 SMB 連線，失敗時卻需要重新驗證。此時該調查的是非預期認證資訊，以及新驗證為何失敗，而不是重新啟動本身。將成功與失敗的時間、連線名稱、執行條件、接受的帳戶對齊，就能更明確地決定下一步。

即使急著重新啟動以恢復服務，也應盡可能先保存第3節的輸出與原始錯誤。重新啟動後，先在原本的應用程式執行相同操作，不要先用檔案總管開啟共用資料夾。若中間插入其他操作，就比較難判斷究竟是重新啟動讓存取恢復，還是該操作改變了連線條件。這不是禁止重新啟動，而是讓復原與原因調查可以兼顧的記錄步驟。

klist purge 會刪除票證，是變更狀態的操作。對沒有使用 Kerberos 的連線並不對症，也可能影響同一登入工作階段的其他服務。避免在保留證據之前「先清掉再說」。⁸

10. 更新後或只有部分 PC 失敗

10.1. 不要混淆簽章、來賓與 NTLM 封鎖

SMB 簽章用來偵測通訊內容遭到竄改，與使用 Kerberos 或 NTLM 的驗證方式屬於不同設定。Microsoft 的 SMB 簽章專屬指南說明，Windows 11 24H2 的 Pro、Enterprise、Education 預設要求輸入與輸出簽章，Windows Server 2025 則要求輸出簽章。除了作業系統名稱，也要確認版本與實際生效的設定。⁷

對於 Home，該指南說明不要求簽章，但 Windows 11 24H2 的變更清單又將 Home 列入預設要求簽章的版本，兩份資料存在差異。本文不會因為是 Home 就排除簽章問題，而是使用下列命令確認調查對象的實際設定。⁷²¹

flowchart TB
    accTitle: 分別確認 SMB 的保護條件
    accDescr: 驗證方式、SMB 簽章與來賓許可不是同一設定，必須分別確認。
    policy["確認實際生效的原則"] --> auth["是否允許 Kerberos 與 NTLM"]
    policy --> signing["是否要求 SMB 簽章"]
    policy --> guest["是否允許來賓連線"]

圖12：看過一項設定，不代表其餘條件也都滿足。

來賓連線不支援一般 SMB 簽章與加密。因此，只變更來賓許可而仍要求簽章時，問題可能不會解決。應優先讓 NAS 使用經過驗證的帳戶並支援簽章，不要輕率地以停用簽章或安裝 SMB1 作為替代方案。³

10.2. 讀取實際設定，不只看預設值

在用戶端的管理員 PowerShell 收集以下資訊。這是讀取設定，應與互動式使用者的連線狀態記錄分開。⁷²²

$config = Get-SmbClientConfiguration
$config | Format-List RequireSecuritySignature, EnableInsecureGuestLogons
if ($config.PSObject.Properties['BlockNTLM']) {
    $config | Format-List BlockNTLM
} else {
    'BlockNTLM property is not exposed on this system.'
}

RequireSecuritySignature: False 表示「不強制要求」，不能證明所有連線都未使用簽章。較舊環境沒有顯示 BlockNTLM，也不能證明不存在其他 NTLM 限制原則。SMB 用戶端的 NTLM 封鎖功能自 Windows 11 24H2／Windows Server 2025 起提供，也能針對個別共用連線指定。因此，除了全域設定，也要確認應用程式的連線選項與組織原則。⁷²²

flowchart TB
    accTitle: 連線條件不只取決於全域設定
    accDescr: 除作業系統預設值外，也要檢查組織原則、連線選項和伺服器端條件。
    defaults["作業系統與版本的預設值"] --> effective["實際連線條件"]
    organization["組織原則與連線選項"] --> effective
    server["共用伺服器的支援條件"] --> effective
    effective --> log["從記錄確認拒絕原因"]

圖13：與更新時間相符只是線索，應依實際設定與拒絕記錄判斷。

「NTLM 淘汰」「移除 NTLMv1」「以原則拒絕 NTLM」是不同的事情。驗證方式遷移與組織層級的稽核，請參閱 NTLM 淘汰的稽核與遷移步驟；本文集中確認本次連線遭哪個條件拒絕。

11. 驗證成功，卻不能開啟或儲存

Windows 共用需要同時檢查共用存取權，以及實際資料夾和檔案的存取權。同一身分執行同一操作時，兩者都必須允許。也要確認群組成員資格、拒絕項目與繼承關係，不能認為「加了 Everyone 就全部能通」。檢查有效存取權時，應以伺服器上的實際路徑，以及真正被接受的身分為準。²³

flowchart TB
    accTitle: 驗證與存取授權的差異
    accDescr: 即使身分驗證成功，共用及檔案權限仍必須同時允許目標操作。
    identity["已驗證的身分"] --> share["共用存取權"]
    share --> file["實際檔案的存取權"]
    file --> operation["執行目標操作"]

圖14：確認是誰，與判斷可以做什麼，是兩個不同步驟。

列出資料夾、讀取檔案、新增、覆寫、重新命名和刪除是不同操作。有些應用程式儲存時會先建立暫存檔，再取代原檔，因此只確認「讀得到」並不足夠。驗證與權限之外，也要依原始錯誤調查共用違規、容量、路徑或檔案消失等問題。²⁴

.NET 的 File.Exists 在存取權不足等情況下，也會回傳 false。請確認應用程式的「檔案不存在」訊息，是否只根據這個回傳值產生。診斷程式碼也應記錄真正要執行之操作的例外。²⁵

$Path = '\\filesrv01.corp.example.com\data\sample.txt'
try {
    Get-Item -LiteralPath $Path -ErrorAction Stop |
        Select-Object FullName, Length, LastWriteTime
} catch {
    $_.Exception.GetType().FullName
    'HRESULT=0x{0:X8}' -f $_.Exception.HResult
    $_.Exception.Message
}

這只能確認能否取得中繼資料，不代表能讀取或寫入檔案內容。測試實際讀寫時，應先確認授權與影響，再使用測試檔重現目標操作。不要將所有錯誤一律轉成「檔案不存在」，也能讓下次調查更容易。

12. 比對記錄，縮小可能原因

12.1. 區分用戶端、共用伺服器與 DC

在用戶端，查看事件檢視器的 Microsoft-Windows-SMBClient/Connectivity 與 Microsoft-Windows-SMBClient/Security。在 Windows 共用伺服器上，若已啟用稽核，Security 記錄中的 4624（登入成功）與 4625（登入失敗）可提供線索。SMB 網路登入應確認登入類型 3。NAS 則使用該產品的驗證與共用記錄。²⁶²⁷²⁸

事件 4624 的登入類型 3 並非 SMB 專用。即使時間、來源與帳戶一致，單靠該事件仍無法識別共用名稱或 SMB 工作階段。應搭配 Get-SmbConnection、SMB 專屬記錄，以及必要時的追蹤資料進行比對。²⁷⁴²⁶

flowchart TB
    accTitle: 比對三個位置的記錄
    accDescr: 依時間與連線資訊比對用戶端、共用伺服器，以及必要時的 DC 記錄。
    client["用戶端：SMBClient 記錄"] --> match["比對時間、來源與帳戶"]
    server["共用伺服器：驗證記錄"] --> match
    dc["DC：票證與認證資訊驗證"] --> match
    match --> result["視為同一次嘗試的證據"]

圖15：沒有對齊位置與時間，就可能把另一條連線的記錄誤認為原因。

以下範例應在 Windows 共用伺服器上，以可讀取 Security 記錄的權限執行。在目標嘗試前先記錄時間，並請管理員確認必要的成功與失敗稽核已啟用。範例取出最近十分鐘的記錄，使用 XML 欄位名稱，而不是依賴訊息翻譯或欄位位置。²⁷²⁸

$Start = (Get-Date).AddMinutes(-10)
Get-WinEvent -FilterHashtable @{
    LogName = 'Security'; Id = 4624, 4625; StartTime = $Start
} -ErrorAction Stop | ForEach-Object {
    $event = $_
    $xml = [xml]$event.ToXml()
    $fields = @{}
    foreach ($item in $xml.Event.EventData.Data) {
        $fields[$item.Name] = [string]$item.'#text'
    }
    if ($fields['LogonType'] -eq '3') {
        [pscustomobject]@{
            Time = $event.TimeCreated
            EventId = $event.Id
            User = $fields['TargetUserName']
            Domain = $fields['TargetDomainName']
            SourceIp = $fields['IpAddress']
            Authentication = $fields['AuthenticationPackageName']
            Status = $fields['Status']
            SubStatus = $fields['SubStatus']
            LogonId = $fields['TargetLogonId']
        }
    }
} | Format-List

在 4624 中，要讀取新登入的目標帳戶，不要與回報事件的 Subject 混淆。4625 的目標使用者名稱是嘗試使用的名稱，而不是已接受的身分。失敗原因應結合 Status 與 SubStatus 判讀。如果 AuthenticationPackageName 只顯示 Negotiate，不能單憑它就確定使用 Kerberos 或 NTLM。²⁷²⁸

12.2. 沒有記錄，或只有票證時

找不到事件，不代表沒有發生驗證。請確認是否已設定稽核、是否有讀取權限、時間是否一致、是否查看正確伺服器、是否重複使用既有工作階段，以及是否在驗證前就失敗。重複使用既有 SMB 連線時，不會每開啟一次檔案就產生新的 4624。²⁷⁴

flowchart TB
    accTitle: 沒有記錄時的判斷方式
    accDescr: 找不到事件時，先檢查收集條件與既有工作階段，不要立即判定沒有驗證。
    absent["沒有符合的事件"] --> collection["稽核、權限、時間與目標"]
    absent --> reuse["重複使用既有工作階段"]
    absent --> before["在驗證之前失敗"]

圖16：沒有留下記錄，與操作從未發生，並不是同一件事。

AD 環境中，DC 的 4769 可用來確認 Kerberos 服務票證要求，4776 可用來確認 NTLM 認證資訊驗證。不過，票證發出不代表共用伺服器使用或接受了它，而單靠 4776 也無法確定目標服務就是 SMB。應合併時間、來源、目標帳戶與伺服器端記錄；若仍有模糊之處，再由管理員收集範圍受限的追蹤資料。²⁹³⁰

13. 處理後，確認能夠穩定運作

一次處理一個問題，留下變更理由與前後記錄。名稱錯誤就修正名稱和目標；認證資訊不同就統一成預期帳戶；不支援簽章就改善共用伺服器的支援。在原因不明的情況下，一次停用多項保護功能，無法建立可靠的運作方式。

flowchart TB
    accTitle: 從一次成功到確認是否再發
    accDescr: 完成一項處理後，依原本的失敗條件與重新連線條件確認結果。
    evidence["能說明原因的記錄"] --> change["一項針對性處理"]
    change --> original["確認原應用程式與操作"]
    original --> reconnect["重連與重新啟動後再確認"]
    reconnect --> record["保留前後差異與結果"]

圖17：應確認原本失敗的條件已能成功，而不只是檔案總管曾開啟一次。

調查筆記	應保留的內容
環境	用戶端與共用伺服器的作業系統、版本、組建，以及 AD 或 NAS 自有驗證
重現條件	時間與時區、UNC、目標 IP、應用程式、身分、權限提升狀態、操作
證據	原始錯誤、既有連線、使用的認證資訊、相關事件
處理	一項變更、理由、影響範圍、還原方式
確認	相同操作的結果，以及必要時登出、重新啟動、VPN 重連後的結果

本文無法唯一確定每一種實作或網路設定的故障原因。不過，只要知道哪個階段失敗、哪些條件與成功時不同，以及什麼仍未確認，下一步調查就能具體化。不要停在「重新啟動就好了」，而要確認預期身分確實能透過預期路徑連線。

參考連結

Microsoft Learn, Kerberos authentication troubleshooting guidance. 確認名稱、時間、DC 與錯誤。 ↩ ↩² ↩³
Microsoft Learn, Accounts: Limit local account use of blank passwords to console logon only. 限制空白密碼本機帳戶的設定。 ↩ ↩²
Microsoft Learn, Insecure guest logons in SMB2 and SMB3. 來賓連線與簽章、加密的限制。 ↩ ↩² ↩³
Microsoft Learn, Get-SmbConnection. 查詢已建立的 SMB 連線與認證資訊。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸
Microsoft Learn, Net use. 刪除指定連線及互動式密碼輸入。 ↩ ↩²
Microsoft Learn, SMB troubleshooting guidance. SMB 通訊與問題調查的入口。 ↩
Microsoft Learn, Control SMB signing behavior. 各作業系統、版本的預設值與簽章要求。 ↩ ↩² ↩³ ↩⁴ ↩⁵
Microsoft Learn, klist. 顯示、取得與刪除票證是不同操作。 ↩ ↩² ↩³ ↩⁴
Microsoft Learn, cmdkey. 管理已儲存的認證資訊。 ↩ ↩² ↩³
Microsoft Learn, Services and Redirected Drives / Mapped drives are not available from an elevated prompt. 服務及權限提升時的登入工作階段與磁碟機對應。 ↩ ↩²
Microsoft Learn, Test-NetConnection. 診斷 TCP 連接埠與目標。 ↩ ↩²
Microsoft Learn, Configuring Kerberos over IP. 使用 IP 時的預設行為與例外設定。 ↩
Microsoft Learn, Service principal names. 識別服務的 SPN。 ↩
Microsoft Learn, setspn. SPN 查詢及 HOST 對服務類別的代替。 ↩ ↩²
Microsoft Learn, LocalSystem Account. 對遠端提供的電腦認證資訊。 ↩
Microsoft Learn, LocalService Account. 網路上的匿名認證資訊。 ↩
Microsoft Learn, TASK_LOGON_TYPE enumeration. S4U 登入的網路存取限制。 ↩
Microsoft Learn, Get-SmbSession. 在共用伺服器查詢已建立的 SMB 工作階段與用戶端帳戶。 ↩ ↩²
Microsoft Learn, System Error Codes (1000–1299). ERROR_SESSION_CREDENTIAL_CONFLICT 的定義。 ↩
Microsoft Learn, Cannot use different credentials for a network share. 使用不同認證資訊連到同一伺服器的問題。 ↩
Microsoft Learn, What’s new in Windows 11, version 24H2 for IT pros. SMB 簽章預設要求的變更清單。注意其中對 Home 的說明與 SMB 簽章專屬指南存在差異。 ↩
Microsoft Learn, Block NTLM connections on SMB. 全域與個別連線的 NTLM 封鎖。 ↩ ↩²
Microsoft Learn, Access control overview. 身分、存取權、繼承與有效存取權。 Microsoft Learn, SMB share and NTFS permissions. ↩
Microsoft Learn, File Security and Access Rights. 個別檔案操作需要的存取權。 ↩
Microsoft Learn, File.Exists. 存取失敗時也會回傳 false 的行為。 ↩
Microsoft Learn, SMB troubleshooting guidance. SMB 事件記錄與進一步調查。 ↩ ↩²
Microsoft Learn, 4624: An account was successfully logged on. 新登入與驗證套件的記錄。 ↩ ↩² ↩³ ↩⁴ ↩⁵
Microsoft Learn, 4625: An account failed to log on. 嘗試使用的帳戶、Status 與 SubStatus。 ↩ ↩² ↩³
Microsoft Learn, 4769: A Kerberos service ticket was requested. DC 上的服務票證要求記錄。 ↩
Microsoft Learn, 4776: The computer attempted to validate the credentials for an account. NTLM 認證資訊驗證記錄。 ↩

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

與本主題相關的服務

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

Windows 應用程式開發

支援包含常駐處理、設備連動、運作日誌與可維護結構的 Windows 桌面應用程式。

查看服務聯絡我們

常見問題

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

重新啟動後就能存取共用資料夾，是否代表快取是原因？: 光憑這點無法確定。重新啟動會一起改變應用程式、登入工作階段、SMB 連線與網路狀態等條件。重新啟動前應記錄目標、執行身分、既有連線、票證及錯誤，再與成功時比較。已儲存的認證資訊和已建立的 SMB 連線是不同的東西。
為何使用 IP 位址能開啟共用資料夾，使用伺服器名稱卻不行？: 先確認兩種寫法是否連到相同的目標 IP。即使 IP 相同，驗證條件也不一樣：Windows 預設不會對 IP 位址目標嘗試 Kerberos。應分別檢查名稱解析、SPN 與驗證問題，不能只因 IP 連線成功就把它當成長期解法。
為何檔案總管能開啟共用資料夾，應用程式卻不能？: 執行帳戶、登入工作階段、權限提升狀態、使用的認證資訊或操作可能不同。服務與互動式登入處於不同工作階段。使用者名稱相同不代表條件一致，應檢查失敗處理程序本身的資訊及伺服器端的驗證記錄。
連線時沒有輸入密碼，就是來賓連線嗎？: 只看沒有出現密碼提示，無法判斷。可能使用目前的登入認證資訊、已儲存的認證資訊或既有 SMB 連線。空白密碼的本機帳戶與來賓連線也不同，需要確認伺服器實際接受哪個帳戶。
klist 有 cifs 票證，就表示 SMB 使用 Kerberos 連線嗎？: 持有票證與在這次 SMB 連線中使用票證，是兩件事。應依連線時間、來源及帳戶比對伺服器記錄。klist get 會提出新的票證要求，不是單純觀察原始狀態的命令。

作者檔案

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

Go Komura

小村軟體有限公司代表

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

查看檔案聯絡我們

公開連結

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

回到部落格一覽

Windows 共用資料夾為何時而能連線、時而失敗——釐清 Kerberos、NTLM 與認證資訊問題

1. 先看結論與症狀索引

2. 將「無法連線」分成不同階段

3. 重新啟動或變更設定前，先留下記錄

4. 先檢查名稱解析與 TCP 445

5. 名稱與 IP 表現不同時，檢查 Kerberos 的前提

5.1. 相同 IP 不代表相同驗證

5.2. 分開確認取得票證與伺服器接受票證

6. 檔案總管能開啟，應用程式卻不能

6.1. 使用者名稱相同，不代表條件相同

6.2. 服務帳戶與工作的登入類型

7. 將「不輸入密碼也能存取」分成四種情況

8. 1219 與換使用者後無法重新連線

9. 重新啟動後恢復時，找出改變了什麼

10. 更新後或只有部分 PC 失敗

10.1. 不要混淆簽章、來賓與 NTLM 封鎖

10.2. 讀取實際設定，不只看預設值

11. 驗證成功，卻不能開啟或儲存

12. 比對記錄，縮小可能原因

12.1. 區分用戶端、共用伺服器與 DC

12.2. 沒有記錄，或只有票證時

13. 處理後，確認能夠穩定運作

參考連結

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

圖解NTLM與Kerberos ── 為什麼驗證會「回退」到NTLM

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

Windows I/O 的深層(第 5 回) ── NTFS 的內部結構：從 MFT 理解檔案系統

使用 Get-WinEvent 有效率地調查事件記錄 ── 篩選的速度決定調查所需的時間

相關主題

Windows 技術主題

與本主題相關的服務

Windows 應用程式開發

常見問題

作者檔案

Go Komura

1. 先看結論與症狀索引

2. 將「無法連線」分成不同階段

3. 重新啟動或變更設定前，先留下記錄

4. 先檢查名稱解析與 TCP 445

5. 名稱與 IP 表現不同時，檢查 Kerberos 的前提

5.1. 相同 IP 不代表相同驗證

5.2. 分開確認取得票證與伺服器接受票證

6. 檔案總管能開啟，應用程式卻不能

6.1. 使用者名稱相同，不代表條件相同

6.2. 服務帳戶與工作的登入類型

7. 將「不輸入密碼也能存取」分成四種情況

8. 1219 與換使用者後無法重新連線

9. 重新啟動後恢復時，找出改變了什麼

10. 更新後或只有部分 PC 失敗

10.1. 不要混淆簽章、來賓與 NTLM 封鎖

10.2. 讀取實際設定，不只看預設值

11. 驗證成功，卻不能開啟或儲存

12. 比對記錄，縮小可能原因

12.1. 區分用戶端、共用伺服器與 DC

12.2. 沒有記錄，或只有票證時

13. 處理後，確認能夠穩定運作

參考連結

相關文章

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

圖解NTLM與Kerberos ── 為什麼驗證會「回退」到NTLM

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

Windows I/O 的深層(第 5 回) ── NTFS 的內部結構：從 MFT 理解檔案系統

使用 Get-WinEvent 有效率地調查事件記錄 ── 篩選的速度決定調查所需的時間

相關主題

Windows 技術主題

與本主題相關的服務

Windows 應用程式開發

常見問題

作者檔案

Go Komura