合同会社小村ソフト
相談する
メニュー

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

· 更新日: · · Windows, SMB, Kerberos, NTLM, 共有フォルダ, 不具合調査

共有フォルダへの接続が不安定に見えるときは、成功時と失敗時の条件をそろえて調べます。通信、実行主体、認証と保護、アクセス許可を区別し、記録の採取から対処後の確認までを説明します。

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全19件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

問題・質問

「昨日は開けた」「IPアドレスなら開ける」「エクスプローラーでは開けるのにアプリでは失敗する」「再起動すると直った」。同じ共有フォルダを使っているつもりなのに結果が変わるとき、何を記録し、どの順序で原因を切り分ければよいでしょうか。

この記事は、共有への接続失敗、別ユーザーで入り直す際の1219、認証後のファイル操作の失敗を診断するガイドです。症状だけから原因を決めず、確認するコマンド、結果から言えること、次の調査先を対応付けます。「ネットワーク」にPC名が表示されることではなく、実際に失敗するUNCパスと操作を調査対象にします。

対象環境

対象はWindows 11とWindows ServerのSMB 2/3共有、通常のTCP 445接続です。PowerShell例はWindows PowerShell 5.1を想定します。管理者・開発者向けですが、共有先を管理できない場合も、許可された接続元の記録から始められます。

ADドメインのアカウント、共有先Windowsのローカルアカウント、NASの独自アカウントを区別します。ADはアカウントなどを組織で管理する仕組みで、ローカルアカウントは各PCが持つアカウントです。NASにもADに参加する構成があります。「社内LANだからKerberos」「NASだからNTLM」と決めず、共有先が受け入れるアカウントと認証構成を管理者に確認します。[S11][S15][S16]

一般的なAD Kerberosと従来のローカルアカウント構成を扱います。SMB over QUIC、Azure Files固有の認証、IAKerb・LocalKDCの個別構成は対象外です。DFSを使う場合は名前空間の入口だけでなく、最終的に接続した共有サーバーも記録します。

手順と仕様はMicrosoftの公式資料に基づきます。特定のWindows環境やNASで実機検証した結果ではありません。OS名だけでなく、エディション、ビルド、組織ポリシー、実効設定を記録してください。設定照会・Securityログ閲覧・AD照会に必要な権限は各手順に示します。権限がない場合は無断で昇格せず、取得できた記録を管理者へ引き継ぎます。

回答・解決方法

変更前の状態を保存し、届くか、誰として接続したか、どの認証・保護条件か、その操作が許可されるかを順に調べます。成功時と失敗時の時刻、接続名、接続先IP、実行主体、操作をそろえて比較してください。再起動での改善やチケットの存在だけでは、原因も実際に使った認証方式も確定しません。[S1][S2][S3]

すぐに調査する場合は「具体例」の症状表と「手順」へ進みます。接続削除やチケット削除は最初に実行せず、署名・ゲスト・NTLMの保護設定もまとめて変更しません。証拠を残して一つずつ対処し、元のアプリで元の操作を再確認します。

症状から証拠へ進む診断症状から候補を選び、成功時と失敗時の証拠を比較して対処を決めます。症状を選ぶ成功時と失敗時を比較ログで候補を絞る一つずつ対処して再確認

図1: 症状は調査の入口にし、対処は証拠を確認してから決めます。

定義

用語の範囲はSMBの接続段階、リダイレクトされたドライブ、SPN、接続照会、署名とゲストの仕様に基づきます。[S1][S5][S9][S20]

SMB

SMB（Server Message Block）は、ネットワーク越しにファイルを共有するためのプロトコルです。アプリはSMBを通じて、共有先のファイルの読み取り、作成、更新などを要求します。[S32]

UNCパス

\\server\share\fileの形式で接続先を指定するパスです。ドライブ文字の割り当てとは別で、UNCを使っても資格情報や権限が追加されるわけではありません。[S5]

認証

接続主体を確認する処理です。認証に成功しても、その主体に目的のファイル操作が許可されているとは限りません。[S1]

アクセス許可

ある主体に、対象のファイルやフォルダーでどの操作を認めるかという権限です。本人を確認する認証とは別に判定されるため、認証成功と保存成功は同じではありません。[S22]

Kerberos

チケットを使う認証方式です。本稿では主にADドメインのアカウントによる共有アクセスを扱い、チケットの取得と共有先での受け入れを分けて確認します。[S11]

NTLM

Kerberosとは別のWindows認証方式です。許可・拒否の設定があり、Kerberosで失敗すれば必ずNTLMで成功するという関係ではありません。[S11][S21]

SPN

サービスを識別する名前です。Kerberosでサービスのチケットを要求する際に使います。DNSで名前を解決できることと、SPNで正しいサービスを識別できることは別の条件です。[S9]

保存済み資格情報

接続先に対して使用するために保存されたユーザー名やパスワードなどの情報です。登録があっても、問題の接続にその情報を使ったとは断定できません。成立済みのSMBセッションとは別に調べます。[S4][S2]

SMBセッション

SMBで認証を経て成立する、クライアントと共有サーバーの間の接続状態です。保存済み資格情報の登録やチケットの保持とは異なり、接続先と実際のアカウントを確認する材料になります。[S1][S30]

Kerberosチケットキャッシュ

ログオンセッション内でKerberosチケットを保持する領域です。チケットが残っていても、問題のSMB接続で使ったとは限りません。調査対象と同じログオンセッションの状態を確認します。[S3]

SMB署名

SMB通信の改ざんを検出するための保護です。認証方式やゲスト接続の許可とは別の条件として、署名を要求する設定と相手側の対応を確認します。[S20]

ゲスト接続

共有先がゲストとして受け入れる接続です。空パスワードのローカルアカウントによる接続とは別で、ゲストは通常のSMB署名・暗号化をサポートしません。[S16]

役割

診断情報の使い分け

通信テストは接続先へ届くかを確認し、接続情報はどの主体・資格情報で接続しているかを確認する材料になります。認証ログは試行と結果を、アクセス許可とアプリのエラーは目的の操作が拒否された理由を調べる材料になります。一つのコマンドですべてを説明するのではなく、確認できる範囲を分担させます。[S7][S2][S25]

業務復旧と原因調査

復旧と原因調査も分けます。業務上の承認を得て再起動で復旧する場合でも、その前の記録があれば成功時との差を追えます。証拠不足なら未確認事項を残し、復旧したことを根本原因の確定と言い換えないようにします。

構成

SMB接続の処理段階

共有ファイルを開くまでには、名前解決・TCP接続、SMB条件の交渉、SESSION_SETUPによる認証、TREE_CONNECTによる共有への接続、CREATEなどのファイル操作があります。前段の成功は後段の成功を保証しません。「ネットワークパスが見つからない」という表示でもゲスト拒否が背景にある場合があるため、文言だけでDNS障害と断定しません。[S1][S20]

共有ファイルを開くまでの段階通信、SMBの条件交渉、認証、共有への接続、ファイル操作は別々に失敗し得ます。名前解決・TCP接続SMB条件の交渉SESSION_SETUP：認証TREE_CONNECT：共有CREATE等：ファイル操作

図2: 前の段階に成功しても、後の段階の成功までは証明できません。

資格情報・セッション・チケット

接続元には、保存済み資格情報、成立済みSMB接続、Kerberosチケットキャッシュという別々の状態があります。保存済み情報を読むcmdkey /list、接続を読むGet-SmbConnection、チケットを読むklistを混同しないでください。[S4][S2][S3]

保存済み情報と利用中の状態資格情報の保存、SMB接続、Kerberosチケットは別々に観察します。同じ時刻に記録保存済み資格情報成立済みSMB接続チケットキャッシュ実際の使用はログで照合

図3: 保存されているものと、問題の接続で使われたものを分けます。

仕組み

接続名、実行主体、接続の再利用、保護設定、アクセス許可は別々に結果を変えます。成功時と失敗時を比較するときは、以下の区別を保ちます。

接続名と認証方式

Windowsは既定では接続先名がIPアドレスのときにKerberos認証を試みません。TryIPSPNとIPベースのSPNを構成する例外はありますが、本稿では正しいDNS名とサービスの識別を整えることを標準対処とします。IP指定で通った事実は比較材料であって、恒久対策の証明ではありません。[S8]

接続名による認証条件の違い名前指定ではサービス名を使うKerberosの条件を確認し、IP指定では既定でKerberosを試みない点を考慮します。UNCの接続先表記ホスト名・FQDNIPアドレス名前に対応するSPNを確認既定ではKerberosを試みない

図4: 同じ装置を指しても、接続名が変われば認証条件も変わります。

KerberosではSPNでサービスを識別します。DNSで別名が引けることと、その別名のサービスを正しく認証できることは別です。また、Kerberosの失敗がすべてNTLMへの切り替えになるわけではありません。フォールバックの可否、認証エラー、NTLM制限をログで区別します。[S9][S11]

SPNとサービスチケット

cifsのSPNが明示登録されていないだけで、SPN不足と断定しません。コンピューターアカウントではHOSTのSPNがcifsなどのサービスを代替できます。一方、登録されていても所有アカウントの相違や重複はあり得ます。照会範囲と所有関係をAD管理者が確認し、見つからないという理由だけで追加しません。[S10]

SPNとチケットの確認範囲SPNの解決、チケットの取得、共有サーバーでの受け入れは別々の確認です。SPNの登録先・HOST代替チケットを取得できるか実際のSMB認証で受理されるかサーバー側ログで照合

図5: チケットを取得できても、共有サーバーでの受理までは保証されません。

チケットを保持していても、問題のSMB接続で使ったかは別に確認します。サービスの失敗に対話ユーザーのチケットを当てはめず、ログオンセッションと試行を照合します。ADを使わないNASやローカルアカウント認証では、AD用SPNの修正より先に、共有の認証方式とアカウント設定を調べます。[S3][S5]

実行アカウントとログオンセッション

エクスプローラーとアプリでは、実行アカウント、ログオンセッション、昇格、UNCパス、操作が違う場合があります。サービスは同じアカウントでも対話ログオンとは別のセッションです。ドライブ文字の割り当てもセッション単位なので、Z:\dataと\\server\share\dataを区別します。UNCはドライブ文字の問題への対策であり、認証や権限まで与える操作ではありません。[S5][S6]

エクスプローラーとサービスの違い同じPCでも対話ログオンとサービスではセッションと資格情報を分けて比較します。同じPC対話ログオンサービスのログオンそのセッションの接続・権限別セッションの接続・権限

図6: 同じPC・同じユーザー名でも、同じ接続状態を共有しているとは限りません。

既定のネットワーク資格情報を使う場合、LocalSystemはコンピューターの資格情報を、LocalServiceは匿名資格情報を提示します。ドメイン構成でLocalSystemの共有アクセスを認めるなら、対話ユーザーではなくコンピューターアカウントなど実際の主体の権限を調べます。明示的な資格情報や偽装を使う実装は別条件です。[S12][S13]

ローカル権限とリモートの主体既定のネットワーク資格情報を使う場合、LocalSystemとLocalServiceは異なる主体を提示します。サービスの既定資格情報LocalSystemLocalServiceコンピューターの資格情報匿名資格情報

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

タスクスケジューラはアカウント名に加えてログオン方式を確認します。TASK_LOGON_S4Uはパスワードを保存せず、ネットワークや暗号化ファイルへのアクセスを持たない方式です。「パスワードを保存しない」タスクを対話ログオンと同じ条件と考えず、業務用のアカウント・ログオン方式と最小権限を設計します。毎回エクスプローラーで先に開く運用に依存させません。[S14]

パスワード入力と実際の認証

入力画面が出なくても、現在のログオン資格情報、保存済み資格情報、成立済みSMBセッションを利用している場合があります。登録があるだけで今回それを使ったとも断定できません。空パスワードのアカウントとゲスト接続も別です。[S2][S4]

見かけ 確認する実体
入力していない ログオン資格情報や保存済み資格情報で認証していないか。
以前は認証したが今回は聞かれない 既存SMBセッションを再利用していないか。
共有先のローカルアカウントにパスワードがない 空パスワード制限の対象か。
共有側がゲストとして受け入れる ゲスト接続と署名・暗号化の条件が合うか。
パスワード入力なしの意味入力画面の有無から無認証と判断せず、資格情報・既存セッション・空パスワード・ゲストを分けます。パスワード入力画面が出ない実際の受け入れ主体を確認資格情報・既存セッション空パスワードのアカウントゲスト

図8: 画面が同じでも、認証の実体は別々です。

共有先Windowsで「ローカルアカウントの空のパスワードの使用をコンソールログオンのみに制限する」が有効なら、空パスワードのローカルアカウントによる通常のネットワークログオンは制限されます。ゲスト許可とは別です。以前通ったなら、本当にそのアカウントが受け入れられていたかを確認します。制限を無効化するのでなく、パスワードを持つ適切な共有用アカウントを検討します。[S15][S16]

資格情報の競合（エラー1219）

エラー1219（ERROR_SESSION_CREDENTIAL_CONFLICT）は、同じサーバーへの複数接続で異なるユーザー名を使う競合を示します。共有名が違っても同じサーバーへの既存接続が関係します。資格情報を変える前に、既存接続、開いているファイル、利用中のアプリを調べます。[S17][S18]

別の共有でも競合する資格情報同じ接続文脈から同じサーバーへ別ユーザーの接続を追加すると、共有名が異なっても競合し得ます。サーバーへユーザーAで接続済み別共有へユーザーBで接続資格情報が競合：1219サーバー単位で既存接続を確認

図9: 共有名だけでなく、接続先サーバーと使用資格情報の組み合わせを見ます。

再起動と接続状態

アプリ再起動、接続の切断、サインアウト、OS再起動では、変わる条件が違います。アプリを閉じてもOS側の接続が残る場合があり、一つの共有を切断しても別接続が残る場合があります。保存済み資格情報の登録は成立済み接続とは別で、通常はOS再起動だけでは消えません。これらは比較軸であり、操作の影響がその範囲だけに限られる保証ではありません。[S2][S4][S3]

再起動で直った結果の解釈再起動では複数の条件が変化するため、改善した事実だけでは一つの原因を特定できません。再起動で改善アプリの状態接続・ログオン状態ネットワークなどの状態変更前後の証拠が必要

図10: 再起動は復旧手段になっても、そのまま原因の証明にはなりません。

署名・ゲスト・NTLMの制限

SMB署名は通信の改ざんを検出する保護で、認証方式とは別の条件です。署名専用ガイドは、Windows 11 24H2のPro・Enterprise・Educationが送受信、Windows Server 2025が送信側の署名を既定で要求すると説明しています。エディションと実効設定を確認します。[S20]

2026年9月17日の資料確認でも、Homeの扱いには記載差があります。署名専用ガイドは署名要求なしとする一方、24H2の変更一覧はHomeを既定の署名要求に含めています。「Homeだから署名は無関係」とは判断せず、調査端末の設定と接続の記録を優先します。[S20][S31]

別々に調べるSMBの保護条件認証方式、SMB署名、ゲスト許可は同じ設定ではなく、各条件を確認します。実効ポリシーを確認Kerberos・NTLMの許可SMB署名の要求ゲスト接続の許可

図11: 一つの設定を見ただけで、残りの条件まで満たしたとは判断できません。

ゲスト接続は通常のSMB署名・暗号化をサポートしないため、ゲスト許可だけを変更しても署名要求が残れば解決しない場合があります。NAS側で認証済みアカウントと署名を利用できる構成を優先し、署名無効化やSMB1導入を安易な回避策にしません。[S16]

SMBクライアントのNTLMブロックはWindows 11 24H2／Windows Server 2025以降の機能で、個別接続にも指定できます。グローバル設定だけでなく、組織ポリシー、接続オプション、共有先の条件を調べます。「NTLMの非推奨」「NTLMv1の削除」「NTLM拒否ポリシー」は同じ話ではありません。移行全体はNTLM廃止への監査・移行手順で扱います。[S21]

グローバル設定だけでは決まらない接続OSの既定値だけでなく、組織ポリシー、接続オプション、サーバー側条件を調べます。OS・エディションの既定値実際の接続条件組織ポリシー・接続オプション共有サーバーの対応条件拒否された理由をログで確認

図12: 更新日との一致は手掛かりであり、実効設定と拒否ログを確認して判断します。

認証とアクセス許可

Windows共有では、同じ主体の同じ操作が共有のアクセス許可と実体のフォルダー・ファイルのアクセス許可の両方で認められる必要があります。グループ所属、拒否、継承も確認し、「Everyoneを追加したから全部通る」とは考えません。実効アクセスは共有先の実体パスと、実際に受け入れられた主体で確認します。[S1][S22]

認証とアクセス許可の違い本人確認が成功しても、共有とファイルの両方で対象操作が許可される必要があります。認証された主体共有のアクセス許可実体ファイルのアクセス許可目的の操作を実行

図13: 本人確認と、何をしてよいかの判定は別です。

一覧表示、読み取り、新規作成、上書き、リネーム、削除は別の操作です。一時ファイルを作って置換する保存処理では、読み取り成功だけでは不足します。共有違反、容量、パス、ファイルの消失も元のエラーから調べます。[S23]

.NETのFile.Existsはアクセス権不足などでもfalseを返します。その戻り値だけから「存在しない」と表示していないかを確認し、調査では本来行う操作の例外とエラーコードを記録します。[S24]

具体例

次の表は症状から調査先を選ぶための対応表です。症状だけで右側の候補を原因と確定するものではありません。リンク先の手順に進む前に、変更前の記録を採取します。

症状 最初に比較すること 進む手順
名前とIPで結果が違う 実際の接続先IPと、名前を使う認証条件。 通信、SPN・チケット
エクスプローラーだけ成功する アプリの主体・セッション・昇格・操作。 実行条件
パスワードなしに見える 共有先が実際に受け入れたアカウント。 受け入れ主体
別ユーザーで入り直せない・1219 同じサーバーへの既存接続と利用中のファイル。 接続の競合
再起動・サインアウトで直る 変更前後の状態と先に行った操作。 再起動の解釈と「確認」
更新後・一部のPC・NASだけ失敗 署名・ゲスト・NTLMの実効設定。 保護条件
開けるが保存できない 目的の操作の権限と元のエラー。 ファイル操作

CORP\aliceはドメインアカウント、FILESRV01\aliceは共有先PCのローカルアカウントの例です。PCのドメイン参加と今回使用した資格情報は別で、同じユーザー名でも共有先で同じ権限とは限りません。ADアカウントならSPN・チケットと認証ログ、ローカルアカウントなら資格情報・既存接続・保護条件、NAS独自アカウントならNASのアカウント設定と認証ログを優先します。不明なら受け入れ主体の確認へ進みます。[S2][S19]

IPアドレスなら接続できる

サーバー名では失敗し、IPアドレスでは成功する場合は、まず同じ共有サーバーへ到達しているかを比較します。接続先IPが一致していても、名前による認証条件は別に調べます。IP指定での成功だけを恒久対策とせず、名前解決とTCP 445の確認、AD認証ならSPNとチケットの調査へ進みます。[S8]

エクスプローラーだけ接続できる

対話操作では開けるのにサービスやタスクで失敗する場合は、ユーザー名だけでなく、ログオンセッション、昇格、パス、実際の操作を比べます。管理者の端末で成功しても、元のアプリで成功するとは限りません。アプリの実行条件を採取し、共有先が受け入れた主体と照合します。[S5][S6]

パスワードを求められない

入力画面が出ない場合は、現在の資格情報、保存済み資格情報、既存SMBセッションの利用を確認します。画面の有無だけでゲスト接続や空パスワードと判断せず、接続先の認証アカウントを調べます。[S2][S4]

別ユーザーで接続できない

ユーザーを切り替えてエラー1219になる場合は、別の共有名を指定したときも、同じサーバーへの既存接続を確認します。開いているファイルと利用中のアプリを確認し、承認された範囲で資格情報の競合を解消します。1219以外の失敗を、同じ原因と決めつけないでください。[S18]

再起動すると接続できる

再起動で改善した場合は、再起動前の接続状態と、起動後に先に実行した操作を記録します。接続やログオン以外にも複数の条件が変わるため、再起動と接続状態の説明に沿って比較し、原因を一つに決めません。

例えば「成功時は別アカウントのSMB接続が既にあり、失敗時は新規認証になっていた」という仮想例なら、調べるべきは再起動自体ではなく、意図しない資格情報と新規認証の失敗理由です。実測例ではありません。

更新後に接続できない

更新後や特定のPC・NASとの組み合わせだけで失敗する場合は、両端のOS・エディション・ビルドと、署名・ゲスト・NTLMの条件を比べます。更新日が一致するだけで原因を確定せず、SMB設定と拒否ログを調べます。保護設定をまとめて無効にして試す手順にはしません。[S20][S21]

読み取れるが保存できない

一覧表示や読み取りだけ成功する場合は、保存が行う新規作成、上書き、リネーム、削除を分けます。共有と実体ファイルの権限に加え、共有違反や容量不足など元のエラーも確認し、承認されたテスト用ファイルでファイル操作を検証します。[S23]

手順

最初の記録を全ケースの入口にし、その後は症状と権限に合う作業だけを選びます。以下はすべてを一括実行するスクリプトではありません。読み取り、能動的テスト、接続状態の変更を区別してください。例のサーバー名・共有名・アカウント名は、管理を許可された実際の対象に置き換えます。

接続状態を記録する

接続元で、失敗を観測したログオン文脈を記録します。サービスの調査では、この対話端末の結果をサービス自身の情報と扱わないでください。

CAUTION:

再起動、接続削除、チケット削除を先に行いません。出力にはユーザー名、社内サーバー名、IPが含まれるため保管先を制限し、外部へ渡す場合は対応関係を保って匿名化します。パスワード、ハッシュ、チケットそのものは公開しません。

  1. 時刻・タイムゾーン、実際のUNCパス、アプリ、操作、元のエラーを記録します。

    成功時も同じ形式で記録し、画面表示だけでなく例外とエラーコードを残します。

  2. 同じ端末の実行主体、OS、既存接続、保存済み資格情報、チケットを採取します。

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

    ここでは状態を表示します。klist getやklist purgeとは異なる操作です。[S3][S4]

  3. 照会できる権限がある場合、成立済みSMB接続を採取します。

    Get-SmbConnection | Format-List *

    ServerName、ShareName、UserName、Credentialを比較します。ローカル主体と接続に使う資格情報は一致しない場合があります。アクセス拒否は「接続ゼロ」ではなく「照会できなかった」と記録します。昇格して採取し直す場合は、元のログオン文脈とは区別します。[S2][S6]

変更前の比較材料が残ります。whoamiはローカル主体、net useはその文脈で見える接続、cmdkeyは登録、klistはチケットの記録です。これだけでサーバーが受け入れた主体や今回使った認証方式を確定しません。

名前解決とTCP 445を確認する

接続元で、実際の接続名を確認します。

Note: これは名前解決とTCP接続を行う能動的テストです。承認された接続先だけを指定し、ファイアウォールを無効にして試す手順にはしません。

  1. 名前解決結果とTCP 445の到達性を別々に採取します。

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

    [S7]

  2. 名前とIPで結果が違う場合、RemoteAddressと名前解決結果を比較します。

    短い名前、FQDN、別名が同じIPに到達するとは限りません。同じIPでも認証条件は別です。名前を変更して改善した場合も、何が変わったかを残します。

  3. TcpTestSucceededに応じて次の調査を選びます。

    Falseなら、その時点の接続先IP、VPN・経路、両端のファイアウォール、サーバーの待受を管理者と調べます。pingの成否はTCP 445の成否ではありません。TrueならSMB、認証、署名、共有名、権限の調査へ進みます。[S7]

到達性の成否と実際の宛先が分かります。TCPの成功を認証やファイル操作の成功とは扱いません。

TCP接続テストの読み方TCP 445の失敗は到達性の調査へ、成功はSMB以降の調査へ進みます。いいえはいTCP 445を試験成功したか接続先・経路・遮断を調査SMB・認証・権限を調査

図14: TCPの成功は認証成功ではなく、次の段階へ進めるという証拠です。

SPNとチケットを調べる

AD認証を使うこと、接続名、調査するログオンセッションを確認します。SPN照会は必要な管理ツールとAD照会権限のある管理端末で行います。

CAUTION:

以下のsetspnは読み取りの-Qです。登録を機械的に追加・削除しません。klist getは新しいチケット要求でキャッシュを変えるため、先にklistの出力を保存し、対象セッションと実施の許可を確認します。

  1. 接続に使った名前に対するSPNを照会します。

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

    HOSTによる代替、登録先アカウント、重複、照会対象のドメイン・フォレストをAD管理者と確認します。照会結果だけで未登録や正しい所有関係を断定しません。[S10]

  2. 必要な場合だけ、状態保存後に対象セッションからチケット取得を試します。

    klist get cifs/filesrv01.corp.example.com

    失敗したらDCへの到達性、時刻同期、名前・SPN、返されたエラーを調べます。対話ユーザーでの成功をサービスの成功と読み替えません。[S3][S11]

  3. 取得結果を実際のSMB試行とサーバー側ログに照合します。

    取得成功だけでは受理を証明できません。認証方式が曖昧なままなら、ログ照合で未確認事項を絞ります。

SPN照会、チケット取得、SMBでの使用・受理について、確認できた段階と未確認の段階を区別できます。ADを使わない構成はこの手順を適用せず、共有先の認証設定へ戻ります。

アプリの実行条件を調べる

対象アプリのログやサービス・タスク設定を閲覧できる権限を確認します。

CAUTION:

調査のために実行アカウントや昇格条件を無断で変更しません。管理者PowerShellで開けた結果だけで、元のアプリの問題を解決済みにしません。

  1. 失敗したプロセスのID、実行主体、ログオンセッション、昇格状態を記録します。

    偽装を使う場合は、そのファイル操作を実行するスレッドの有効な主体も記録します。

  2. 実際のパス、操作名、元の例外とエラーコードを成功時と比較します。

    ドライブ文字の割り当てが必要なのか、UNCを直接使っているのかも確認します。[S5]

  3. サービスならネットワークへ提示する資格情報、タスクならログオン方式を確認します。

    LocalSystem・LocalServiceの既定資格情報、明示的資格情報、偽装、S4Uを区別します。変更が必要なら担当者が最小権限と復旧方法を決めます。[S12][S13][S14]

エクスプローラーとアプリで一致する条件と異なる条件を説明できます。共有先が受け入れた主体は次の手順とログで確認します。

接続先の認証アカウントを確認する

Windows共有サーバーを管理でき、接続が成功している間に実行できることを確認します。NASは製品固有のアカウント・認証ログを管理者に確認します。

Note: このコマンドは共有サーバー上の管理者PowerShellで実行する読み取りです。接続元のGet-SmbConnectionと取り違えず、他利用者の情報を含む出力の保管先を制限します。

  1. 共有サーバー上で成立済みセッションを照会します。

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

    [S30]

  2. 接続元と試行時刻を手掛かりに対象を探し、ClientUserNameを確認します。

    同じ接続元に複数セッションがあれば、アプリの操作時刻やSMB固有の記録も照合します。終了済みの接続は、過去のログを調べます。

現在成立しているSMBセッションとクライアントのアカウントが分かります。過去の失敗理由やKerberos／NTLMの判定は、この出力だけではできません。[S30]

資格情報の競合を解消する

変更前の記録と既存接続を確認し、対象サーバーを利用するファイルとアプリを洗い出します。変更理由、影響範囲、元の接続先・アカウントで復旧する方法を担当者と決めてください。

CAUTION:

これは接続状態の変更です。必要な保存を終え、対象の利用を止め、影響範囲の承認を得てから実行します。対象外の接続は切断しません。削除に失敗した場合や別接続が残る場合は再接続へ進まず、状態を確認します。パスワードはコマンドラインに書きません。

  1. net useとGet-SmbConnectionで、同じサーバーへの既存接続と資格情報を確認します。

    共有名が異なっていても同じサーバーへの接続を対象にします。[S18]

  2. 実際に確認した接続だけを指定して切断します。

    net use "\\filesrv01.corp.example.com\data" /delete

    一覧を再確認します。一共有を切断しても別共有・別用途の接続が残る場合があるため、承認された必要な範囲だけ整理します。[S19]

  3. 競合する接続が整理できたことを確認し、意図したアカウントで再接続します。

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

    *はパスワードの対話入力です。失敗したらエラーと残る接続を記録して担当者へ戻し、資格情報を推測して繰り返し試しません。[S19]

  4. 本来のアプリ・実行文脈から、本来の資格情報で目的の操作を確認します。

    対話端末でのnet use成功を別セッションのサービスの成功と扱いません。net use * /deleteの一括実行や、別名・IPで競合を避け続ける運用は標準対処にしません。

意図した主体の対象接続で競合が解消し、元の操作が成功すれば対処を確認できます。未解消なら接続一覧と元のエラーを残し、無関係の接続を削除せず引き継ぎます。

SMB設定を確認する

接続元の管理者PowerShellで実施します。これは端末の構成の読み取りであり、対話ユーザーの接続状態の採取とは区別します。

CAUTION:

設定値を記録する手順です。署名やNTLM制限を無効にしたり、ゲスト許可を有効にしたりして結果を合わせません。

  1. 署名要求・ゲスト許可と、公開されていればBlockNTLMを採取します。

    $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.'
}

    [S20][S21]

  2. 組織ポリシー、アプリの接続オプション、共有サーバーの対応条件と比較します。

    RequireSecuritySignature: Falseは要求しないという意味で、すべての接続が署名なしという証明ではありません。BlockNTLMが見えない場合も、他のNTLM制限がないとは言えません。

  3. 更新前後や成功するPCとの差を、拒否ログに照合します。

    署名非対応ならサーバー側で署名を使える構成、ゲスト依存なら認証済みアカウントへの移行を優先して担当者と検討します。[S20][S16]

取得できた実効設定と不足する情報が分かります。OS名や更新日との一致だけで原因を断定せず、実際に拒否された条件をログで確認します。

ファイル操作を検証する

実際に受け入れられた主体、共有先の実体パス、失敗した操作を確認します。権限の照会や変更は共有先の担当者と行います。

CAUTION:

Get-Itemの例はメタデータ取得です。読み書きや削除を試す場合は、権限と影響を確認したテスト用ファイルを使い、業務データを上書きしません。調査目的でEveryoneなどへ広い権限を追加しません。

  1. 目的の操作について、共有と実体ファイルの両方のアクセス許可を確認します。

    グループ所属、拒否、継承と、アプリが一時ファイル作成・置換などを行うかも確認します。[S22][S23]

  2. メタデータ取得を確認する場合、例外を握りつぶさずに記録します。

    $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
}

    File.Existsのfalseだけを「ファイルなし」の根拠にしません。[S24]

  3. 承認されたテスト用ファイルで、元のアプリの目的の操作を再現します。

    一覧表示やメタデータ取得の成功を、読み取り・保存・リネームの成功と読み替えません。認証・権限以外の共有違反や容量不足なども元のエラーで切り分けます。

どの主体のどの操作が成功・失敗したかを記録できます。読み取りは成功するが保存は失敗するなど、残った差を担当者へ渡します。

関連ログを照合する

試行時刻とタイムゾーン、接続元、接続先、対象アカウントをそろえます。Securityログは閲覧権限と必要な成功・失敗監査が有効なことを管理者に確認します。

CAUTION:

監査未設定や閲覧権限不足を「該当イベントなし」と同一視しません。監査設定の変更やトレースは管理者の承認と保管方針に従い、接続情報を公開しません。

三つの場所のログを照合する接続元、共有サーバー、必要に応じてDCのログを時刻と接続情報で照合します。接続元：SMBClientログ時刻・接続元・アカウントを照合共有サーバー：認証ログDC：チケット・資格情報検証同じ試行の証拠として読む

図15: 場所と時刻をそろえないと、別の接続のログを原因と取り違えます。

  1. 接続元のSMBClientログと共有先の認証・共有ログを確認します。

    接続元はMicrosoft-Windows-SMBClient/ConnectivityとMicrosoft-Windows-SMBClient/Securityを確認します。Windows共有先ではSecurityログの4624・4625、NASでは製品固有のログを確認します。[S25][S26][S27]

  2. Windows共有サーバー上で、対象時間帯のネットワークログオンを抽出します。

    次の例は直近10分を対象にします。試行時刻に合わせて期間を調整してください。メッセージの翻訳やフィールドの位置に依存せず、XMLのフィールド名で読みます。[S26][S27]

    $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

  3. 対象アカウントと失敗理由を読み、同じSMB試行の記録と照合します。

    4624は新しいログオンの対象アカウントを読み、イベントを報告したSubjectと取り違えません。4625の対象ユーザー名は試みられた名前であり、受け入れられた主体ではありません。StatusとSubStatusを組み合わせて読みます。AuthenticationPackageNameがNegotiateだけならKerberosかNTLMかを確定しません。[S26][S27]

    ログオンタイプ3はSMB専用ではありません。時刻・接続元・アカウントが一致しても、そのイベントだけで共有名やSMBセッションを特定できないため、接続情報、SMB固有のログ、必要に応じたトレースと照合します。[S2][S25]

  4. イベントが見つからなければ、収集条件と既存接続の再利用を確認します。

    監査、権限、時間帯、確認するサーバー、既存セッションを調べます。認証より前に失敗した可能性も残ります。Get-WinEventのエラーや取得不能は、そのまま未確認と記録します。

  5. AD環境で必要なら、DCのチケット要求・資格情報検証の記録も照合します。

    4769はKerberosサービスチケット要求、4776はNTLM系の資格情報検証の確認に使います。チケット発行だけでは共有先での使用・受理を証明できず、4776だけでは対象サービスがSMBと断定できません。曖昧さが残る場合は管理者による対象を絞ったトレースへ進みます。[S28][S29]

同じ試行について、接続・認証・権限のどこまで確認できたかを記録できます。ログの欠落や主体の不一致が残る場合は、原因確定ではなく次の調査条件として引き継ぎます。

ログがないときの判断イベントがない場合は収集条件や既存セッションを調べ、認証していないと即断しません。該当イベントがない監査・権限・時刻・対象既存セッションの再利用認証より前の失敗

図16: 記録がないことと、その処理が存在しなかったことは同義ではありません。

確認

対処は一つずつ行い、変更理由、影響範囲、戻し方、変更前後の記録を残します。名前が誤っていたなら名前と接続先、資格情報が違ったなら使用アカウント、署名非対応なら共有側の対応を、確認できた原因に合わせて直します。保護機能をまとめて無効化して成功させる方法では、何が原因だったか分かりません。

元のアプリでの再検証

確認は元のアプリ、元の実行主体、同じUNCパス、同じ操作で行います。別のアプリで一度開けただけでは、元の問題を解決済みにしません。

再接続・再起動後の再検証

サインアウト・OS再起動・VPN再接続が再現条件なら、作業の保存と停止の承認を得たうえでその条件でも確認します。再起動後はエクスプローラーで先に共有を開く前に元のアプリで試し、間に行った操作も記録してください。

一度の成功から再発確認へ一つの対処を行った後、元の失敗条件と再接続条件で動作を確認します。原因を示す記録一つの対処元のアプリ・操作で確認再接続・再起動後も確認前後の差と結果を残す

図17: エクスプローラーで一度開けたことではなく、元の失敗条件での成功を確認します。

解決条件と調査記録

調査メモ 残す内容 確認できない場合
環境 両端のOS・エディション・ビルド、ADかローカル／NAS独自認証か。 共有先の構成を管理者へ確認します。
再現条件 時刻とタイムゾーン、UNC、接続先IP、アプリ、主体、昇格、操作。 実行条件の採取へ戻り、別の接続を比較しません。
証拠 元のエラー、既存接続、使用資格情報、関連するイベント。 取得不能と不存在を区別し、ログ照合へ進みます。
対処 一つの変更、理由、影響範囲、戻し方。 原因候補と承認を確認し、無関係の設定を変えません。
結果 元の操作と、必要な再接続・再起動・VPN再接続後の成功／失敗。 未解決の条件を明記し、担当者へ引き継ぎます。

これは利用者が結果を確かめるための確認方法であり、本稿で実機試験が成功したという記録ではありません。調査を終える目安は「一度開けた」ではなく、どの段階で失敗し、どの条件を直し、意図した主体で元の操作が成功するようになったかを説明できることです。

制約

診断結果の適用範囲

本稿は診断の進め方を示すもので、症状に一対一の原因を割り当てる表ではありません。TCP接続、チケット取得、認証、共有接続、メタデータ取得、内容の読み取り、保存は別の成功条件です。どこまで確認したかを記録し、その先まで推測で埋めません。

接続・チケット削除の影響

klist purgeはチケットを削除する変更操作です。Kerberosを使っていない接続には狙いが合わず、同じログオンセッションの別サービスにも影響し得ます。証拠保存前の「とりあえず削除」は避けます。保存済み資格情報を削除することも、成立済みSMB接続を切断することと同じではありません。[S3][S4]

権限・監査ログの制約

共有先を管理できない、監査がない、別セッションのアプリから情報を取れない場合は、確認範囲に限界があります。取得できた記録、試した操作、未確認事項を担当者へ渡してください。OSの既定値や資料間の記載差を、目の前の機器の実測値の代わりにしません。

関連記事

参考資料

元記事のMicrosoft一次資料を維持し、本文の主張から該当資料へリンクしています。旧製品名を含む資料は記載仕様の参照用であり、旧OSの利用を推奨する意味ではありません。

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

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

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

再起動で共有フォルダに接続できるようになったら、原因はキャッシュですか？
それだけでは特定できません。再起動ではアプリ、ログオンセッション、SMB接続、ネットワーク状態などが一緒に変わります。再起動前に接続先、実行主体、既存接続、チケット、エラーを保存し、成功時との違いを確認します。保存済み資格情報と成立済みSMB接続は別物です。
IPアドレスなら開けるのに、サーバー名では開けないのはなぜですか？
まず同じ接続先IPに到達しているか確認します。同じIPでも認証条件は同じではなく、Windowsは既定ではIPアドレス宛てにKerberos認証を試みません。名前解決とSPN・認証の問題を別々に調べます。IP指定での成功だけを恒久対策にしません。
エクスプローラーから開ける共有を、アプリから開けないのはなぜですか？
実行アカウント、ログオンセッション、昇格、使用資格情報、アクセスする操作が違う可能性があります。サービスは対話ログオンと別のセッションで動きます。同じユーザー名でも条件は一致しないため、失敗しているプロセス自身の情報とサーバー側の認証記録を確認します。
パスワードを入力していない共有接続はゲスト接続ですか？
入力画面が出ないことだけでは分かりません。現在のログオン資格情報、保存済み資格情報、既存のSMB接続を利用している場合があります。空パスワードのローカルアカウントとゲスト接続も別です。共有先が実際に受け入れたアカウントを確認します。
klistにcifsのチケットがあれば、SMBはKerberosで接続していますか？
チケットを保持していることと、問題のSMB接続でそれを使ったことは別です。接続時刻・接続元・アカウントと一致するサーバー側のログを照合します。klist getは新たなチケット要求であり、実行前の状態を観察するだけのコマンドではありません。

著者プロフィール

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

小村 豪

合同会社小村ソフト 代表

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

お問い合わせ
ブログ一覧に戻る