VPN 経由の SMB ゲストログオン: Windows はいまも識別情報を求める

オフィスの VPN に接続するとファイル サーバーには届くようになるのに、共有はアクセスを拒否し続ける。そこでトンネルが壊れていると結論したくなるが、たいていはそうではない。SMB はセッションごとに別々に認証し、Windows は匿名ログオンとして何を受け入れるかを厳しくしてきた。 ネットワーク経路とユーザー識別情報は別の要件であり、問題になっているのは後者である。

なぜトンネルは SMB の識別情報の代わりにならないのか

サーバーとサブネットを共有しても、そのファイルを読む許可を得たことにはならず、経路の問題が取り除かれるだけだ。クライアントが安全でないゲスト ログオンを遮断すると、Windows はイベント 31017 を記録するが、これはサーバーではなく手元のマシンでの判断である。トンネルは SMB パケットを忠実に運ぶが、ゲスト セッションは拒否される。同じ家庭内ネットワークでも一方のノート PC は機能し、もう一方は機能しないのはこのためだ。

このイベントはネットワーク障害ではなくポリシーの証拠として扱う。修正は識別情報か機器の側にある。

クライアント ポリシーと拒否イベントを読む

二つの出力、すなわち有効なクライアント構成と最近の拒否イベントが、問いをすぐに片づける。

Get-SmbClientConfiguration | Select-Object EnableInsecureGuestLogons, RequireSecuritySignature
Get-WinEvent -LogName Microsoft-Windows-SmbClient/Operational -MaxEvents 20 | Where-Object Id -eq 31017

誤ったゲスト設定と署名の要求が重なればそれ以上の調査の前に失敗を説明でき、またイベント ログは、サーバーが資格情報を拒否したのではなく、クライアントがセッションを拒否したことを裏づける。別のマシンで成功した試行の共有パスとアカウントを控えておくこと。キャッシュされたセッションがあると、同じでない二つの検証が同じに見えることがある。比較の前に既存の接続を net use で消して、古いセッションが新しいセッションの代わりに答えないようにする。

名前付きアカウントを使い、署名は維持する

持続的な修正は、サーバーが知っているアカウントを明示的に渡すことであり、署名と暗号化のポリシーはそのままにする。ダイアログに適当な名前を打ち込むのではなく、接続時に資格情報を渡す。

net use \\fileserver.example\share /user:DOMAIN\alice *
Get-SmbConnection

名前付きログオンはサーバーが監査できるセッションを生み、Get-SmbConnection はダイアレクトと署名が有効かを示す。ゲスト セッションは署名や暗号化の要件を満たせないため、ゲスト フラグを有効にしても、それらを要求するポリシーは救えない。旧式の機器にアカウントの仕組みがない場合は、ゲスト アクセスを明示的に文書化した例外として扱い、置き換え計画を添える。一つの機器に合わせて、すべての接続で署名を弱めてはならない。

機器がゲストしか話さない場合

一部の民生向け NAS はアカウントの概念がない共有を公開しており、機器を隔離するか交換するかという二つの正直な選択肢が残る。機密に至る経路のないセグメントに置き、便宜上の例外をクライアント全体の既定にしてはならない。バックアップや資格情報を置いたゲスト共有は、Windows の不便ではなくデータ露出の問題である。ファームウェア更新でユーザー アカウントが追加されるなら、それがより安価な長期的答えだ。

受け入れたアカウントとポリシーの値をチケットに記録する。そうしなければ、次の担当者が再びトンネルの検証を実行し、同じ拒否にたどり着く。