再起動で共有フォルダに接続できるようになったら、原因はキャッシュですか？

それだけでは特定できません。再起動ではアプリ、ログオンセッション、SMB接続、ネットワーク状態などが一緒に変わります。再起動前に接続先、実行主体、既存接続、チケット、エラーを保存し、成功時との違いを確認します。保存済み資格情報と成立済みSMB接続は別物です。

IPアドレスなら開けるのに、サーバー名では開けないのはなぜですか？

まず同じ接続先IPに到達しているか確認します。同じIPでも認証条件は同じではなく、Windowsは既定ではIPアドレス宛てにKerberos認証を試みません。名前解決とSPN・認証の問題を別々に調べます。IP指定での成功だけを恒久対策にしません。

エクスプローラーから開ける共有を、アプリから開けないのはなぜですか？

実行アカウント、ログオンセッション、昇格、使用資格情報、アクセスする操作が違う可能性があります。サービスは対話ログオンと別のセッションで動きます。同じユーザー名でも条件は一致しないため、失敗しているプロセス自身の情報とサーバー側の認証記録を確認します。

パスワードを入力していない共有接続はゲスト接続ですか？

入力画面が出ないことだけでは分かりません。現在のログオン資格情報、保存済み資格情報、既存のSMB接続を利用している場合があります。空パスワードのローカルアカウントとゲスト接続も別です。共有先が実際に受け入れたアカウントを確認します。

klistにcifsのチケットがあれば、SMBはKerberosで接続していますか？

チケットを保持していることと、問題のSMB接続でそれを使ったことは別です。接続時刻・接続元・アカウントと一致するサーバー側のログを照合します。klist getは新たなチケット要求であり、実行前の状態を観察するだけのコマンドではありません。

共有フォルダにつながったり、つながらなかったりする理由 ── Kerberos・NTLM・資格情報を切り分ける

2026年09月08日 09:00 · 更新日: 2026年09月09日 · 小村豪 · 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日確認時点の公式資料に基づき、OS名だけでなく実際の設定を優先します。

最初に、共有先がどのアカウントを受け入れる構成なのかを確認してください。 ADは会社などのアカウントをまとめて管理する仕組みで、ローカルアカウントは各PCが持つアカウントです。NASにも独自アカウントで使う構成と、ADに参加して使う構成があります。「社内LANだからKerberos」「NASだからNTLM」と製品名や置き場所だけで判断せず、管理者に認証設定を確認します。¹²³

共有へのログオンに使うアカウント	優先する調査
ADドメインのアカウント	通信確認後、名前・SPN・チケットと認証ログを確認する
共有先Windowsのローカルアカウント	使用資格情報と空パスワード、既存接続、保護条件を先に見る
NASの独自アカウント	NAS側のアカウント・認証ログと、ゲスト・署名・NTLM制限を確認する
どれか分からない	接続元の記録を保存し、サーバーが受け入れたアカウントを確認する

「PCがドメインに参加しているか」と「今回どの資格情報を使ったか」も別です。以降の CORP\alice はドメインアカウントの例、FILESRV01\alice は共有先PCのローカルアカウントの例として読み分けてください。自分の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パス、ユーザー、OS、既存接続を記録してください。次は状態確認用です。サービスの失敗を調べるときに、この対話端末の結果をサービス自身の結果として扱ってはいけません。⁴⁸⁹

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: PC上で強い権限があっても、共有先で対話ユーザーとして扱われるわけではありません。

タスクスケジューラでは、アカウント名に加えてログオン方式を調べます。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. 再起動で直るときは「何が変わったか」を探す

再起動によって複数の状態が変わる以上、改善したという結果だけから、一つの原因へ逆算することはできません。次の表は調査の比較軸であり、操作すれば必ずその範囲だけが初期化されるという保証ではありません。⁴⁸⁹

操作・情報	比較するときの注意
アプリの再起動	アプリの状態は変わるが、OS側の共有接続が残る場合がある
対象共有の切断・再接続	接続と認証をやり直せるか確認する。別接続が残っていないか見る
サインアウト・OS再起動	セッションやアプリ、ネットワークなど複数条件が変わる
保存済み資格情報	成立済み接続とは別。通常、OS再起動だけでは登録は消えない

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は送信側を要求すると説明しています。OS名だけでなく、エディションと実効設定まで確認することが重要です。⁷

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: OSの既定値だけでなく、組織ポリシー、接続オプション、サーバー側条件を調べます。
    defaults["OS・エディションの既定値"] --> 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ログを読める権限で実行する例です。調査対象の試行直前に時刻を記録し、必要な成功・失敗監査が有効であることを管理者に確認します。例では直近10分を抽出し、メッセージの翻訳やフィールドの位置ではなく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: エクスプローラーで一度開けたことではなく、元の失敗条件での成功を確認します。

調査メモ	残す内容
環境	接続元・共有先のOS、エディション、ビルド、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. OS・エディションごとの既定値と署名要求。 ↩ ↩² ↩³ ↩⁴ ↩⁵
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は新たなチケット要求であり、実行前の状態を観察するだけのコマンドではありません。

著者プロフィール

記事の著者プロフィールページです。

小村豪

合同会社小村ソフト代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。

プロフィールを見るお問い合わせ

公開リンク

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

ブログ一覧に戻る

共有フォルダにつながったり、つながらなかったりする理由 ── 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廃止で業務アプリは止まるか ── 監査ログの取り方と、依存を潰す順番

Time Travel Debugging ── 長期稼働で再現しない不具合を「録画」して巻き戻す

スリープ復帰で壊れるアプリ ── 電源イベントの仕組みと復帰に強い業務アプリの作り方

関連トピック

Windows技術トピック

不具合調査 / 長期稼働テーマ

このテーマがつながるサービス

Windowsアプリ開発

不具合調査・原因解析

よくある質問

著者プロフィール

小村豪

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. 対処後に「安定して動く」を確かめる

参考リンク

関連する記事

関連トピック

このテーマがつながるサービス

よくある質問

著者プロフィール

小村 豪

小村豪