Windows Server 2008 R2でSMB1接続を監査ログで洗い出す方法｜無効化前のAuditSmb1Access手順

Windows Server 2008 R2でSMB1を無効化したいとき、まず困るのが「まだSMB1で接続してくる端末が残っていないか」の確認です。2012以降の記事のコマンドが使えない環境でも、レジストリ設定でSMB1接続を監査ログに残す手順を解説します。

Windows Server 2008 R2で「SMB1を無効化する前に監査（ログ）したい」よくある悩み

SMB1（CIFS）は古いプロトコルで、セキュリティ面・運用面の理由から無効化が推奨される場面が多くあります。ただし、ファイルサーバー側でSMB1を止めた瞬間に、以下のような“レガシー利用者”が一斉に影響を受けることがあります。

• 古いWindows端末（例：古い検査端末、業務アプリが固定されたPC）
• 複合機／スキャナーの「スキャン to フォルダ」
• 組み込み機器（生産設備、医療系、計測機器など）
• 古いNAS／バックアップソフト／古いアプライアンス

このため、いきなりSMB1を無効化するのではなく、事前に「SMB1で接続してくるクライアントがいるか」を監査ログで洗い出すことが重要です。

なぜ2008 R2だとSMB1監査の情報が見つけにくいのか

Windows Server 2012以降を前提とした記事では、SMBサーバー構成を操作するPowerShellコマンド（例：Set-SmbServerConfiguration）で監査を有効化する手順が紹介されがちです。しかし2008 R2では、環境や更新状況によってはそのコマンド体系が存在しない、あるいは同じ手順がそのまま適用できないことがあります。

結論として、2008 R2で実務的に取りやすいのはレジストリでSMB1アクセス監査を有効化する方法です。

まず押さえる全体像（何をやると何が得られるか）

目的	やること	得られるもの	注意点
SMB1利用者の棚卸し	SMB1アクセス監査を有効化	SMB1接続が発生した痕跡（ログ）	ログの保存期間・量に注意
止めたときの影響を最小化	ログから端末/アプリの特定→対策	影響範囲、移行計画	部門調整が必要になりやすい
最終的にSMB1を無効化	棚卸し完了後に無効化	セキュリティ改善	切替はメンテ時間推奨

解決策A：レジストリでSMB1アクセス監査を有効化（2008 R2向けの実用解）

2008 R2で「SMB1接続を監査したい」場合、サーバー側のレジストリに設定を追加して監査を有効化するのが現実的です。ポイントは、LanmanServer（Serverサービス）側のParametersに設定を入れることです。

設定するレジストリキー

項目	値	意味
キー（パス）	HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters	ファイル共有（Serverサービス）の設定
値名	AuditSmb1Access	SMB1アクセス監査のオン/オフ
型	DWORD (32-bit)	数値で設定
値	1	有効化

実施前の注意（重要）

• 管理者権限で操作してください。
• レジストリ変更は、念のため事前バックアップ（エクスポート）を推奨します。
• 反映のためにServer（LanmanServer）サービス再起動またはサーバー再起動が必要になる場合があります。
• Serverサービスの再起動は、共有接続を切断する可能性があるため、業務影響が出ない時間帯で実施してください。

バックアップ（エクスポート）の例

最低限、対象キーをエクスポートしておくと戻しやすくなります。

reg export "HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" "C:\Temp\LanmanServer_Parameters_backup.reg" /y

PowerShellで設定する例（推奨）

PowerShellから値を作成/上書きできます。

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" `
  -Name AuditSmb1Access -Type DWord -Value 1 -Force

コマンドプロンプトで設定する例（reg add）

reg add "HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" /v AuditSmb1Access /t REG_DWORD /d 1 /f

反映（サービス再起動/再起動）

環境によっては設定直後にログが出ない場合があります。その場合は、次のどちらかを実施します。

• サーバー再起動（確実だが業務影響が大きい）
• Serverサービス（LanmanServer）の再起動（共有接続が切れる可能性がある）

Serverサービス再起動の例（影響に注意）：

net stop lanmanserver
net start lanmanserver

PowerShellでの例（依存関係により失敗することもあるため、計画的に）：

Restart-Service -Name LanmanServer -Force

クラスタ構成（フェールオーバークラスタ）での注意点

ファイルサーバーがクラスタ上で動いている場合、監査設定も「どこか1台に入れれば終わり」にならないケースが多いです。基本方針としては次の通りです。

• 監査の目的が「どのノードで稼働してもSMB1接続を捕捉したい」なら、原則として各ノードに同じ設定を入れます。
• ログはノードごとに分散して残る可能性があるため、収集手順（どのノードから、どの期間を回収するか）を最初に決めます。
• Serverサービス再起動はフェールオーバー計画と合わせて行い、共有の切断や業務影響を最小化します。

項目	単体サーバー	クラスタ
設定投入	対象サーバー1台	原則、全ノード
ログ確認	そのサーバーを見る	アクティブだったノードを中心に回収
作業タイミング	メンテ時間	フェールオーバー手順に組み込む

監査ログの見方：どこに出るか／見えないときの探し方

SMB1監査を有効化したら、まずはテスト用にSMB1クライアントから接続してログが出るかを確認します。

イベントビューアーでは、一般に「アプリケーションとサービス ログ」配下のSMB関連ログに記録されることが多いです。ただし、OSの言語や更新状況、ログチャネルの有効/無効状態によって見え方が異なります。

まず「SMBのログチャネル名」を特定する（確実な探し方）

ログ名が分からない場合は、ログ一覧からSMBっぽいものを検索するのが早いです。

wevtutil el | findstr /i smb

出てきたログ（例：SMBServer系、SMBClient系、Operational/Auditなど）をイベントビューアーで開き、右クリックして「ログの有効化」が必要なら有効化します。

イベントビューアーでの基本確認ポイント

• 該当ログチャネルが無効（停止）になっていないか
• ログサイズが極端に小さく、上書きが速すぎて消えていないか
• SMB1で接続した「つもり」でも、実はSMB2/SMB2.1で繋がっていないか

ログ確認を運用に乗せるなら「エクスポート」が便利

イベントビューアーで目視するだけだと棚卸しが進みません。一定期間のログをエクスポートし、端末ごとに整理するのが現場では強いです。

例：EVTXとしてエクスポート（ログ名は環境で確認）

wevtutil epl "（ここにSMB監査ログ名）" "C:\Temp\SmbAudit.evtx"

例：PowerShellでイベントを抽出（ログ名は環境に合わせる）

$logName = "（ここにSMB監査ログ名）"
Get-WinEvent -LogName $logName |
  Where-Object { $_.Message -match "SMB1" } |
  Select-Object TimeCreated, Id, ProviderName, Message |
  Export-Csv "C:\Temp\Smb1_Audit.csv" -NoTypeInformation -Encoding UTF8

※イベント本文の表現は環境で異なるため、まずは数件出力して「Messageに何が含まれるか」を確認し、フィルタ条件（SMB1/接続元/IP/ユーザーなど）を調整してください。

テスト方法：SMB1接続を意図的に発生させてログを確認する

監査を有効化したら、最初に「ログが出る」ことをテストで確認します。現実的には次のどれかがやりやすいです。

テスト手段	メリット	注意点
手元にある古いWindows端末で共有にアクセス	実際の利用に近い	端末がないと難しい
Linux/UnixのsmbclientでSMB1（NT1）を指定	意図的にSMB1を発生させやすい	環境準備が必要
既存の複合機のスキャン先を一時的に向ける	“本命”が複合機なら最短	業務影響が出ないよう一時共有で

Linuxのsmbclientを使う例（SMB1相当の指定としてNT1を指定するパターン）：

smbclient -m NT1 -L //ファイルサーバー名 -U ユーザー名

テストの目的は「監査設定が効いているか」なので、本番共有ではなくテスト用の共有を用意し、短時間で確認するのがおすすめです。

棚卸しの進め方：ログを“見える化”して潰していく

監査ログが取れる状態になったら、次は棚卸しを進めます。ここで大事なのは、ログを眺めるのではなく、対応リストに落とすことです。

おすすめの棚卸しサイクル

1. 監査を有効化し、ログが出ることをテスト
2. 業務ピークを含む期間（例：5～14日）ログを収集
3. 接続元（IP/ホスト名/ユーザー/共有名など）でグルーピング
4. 端末・アプリの管理者を特定し、SMB2以上へ移行（設定変更/更新/置換）
5. 再度ログを取り、SMB1接続がゼロになったことを確認
6. SMB1無効化を計画・実施

棚卸しの管理テンプレ（表にして運用すると強い）

接続元	想定機器/アプリ	影響（止めたら）	対応方針	期限	担当	状況
例：192.0.2.10	例：複合機（スキャン）	スキャン不能	ファーム更新/SMB2設定	例：今月末	例：総務	調査中
例：192.0.2.25	例：業務端末	共有参照不可	端末更改/OS更新	例：来月	例：情シス	対応中

この表を1枚作って、ログに出た接続元を一行ずつ潰していくと、SMB1廃止が「言いっぱなしで終わる」状態から脱出できます。

解決策B：PowerShellコマンドで有効化（環境によっては不可）

情報として、Set-SmbServerConfiguration -AuditSmb1Access $true のようなPowerShellコマンドでSMB1監査を有効化できる、とされるケースがあります。ただし2008 R2では、更新プログラムの前提やモジュールの有無により、コマンド自体が存在しない／動作しないことがあるため、確実性はレジストリ方式が上です。

「そもそもコマンドが使えるか」だけでも先に確認するなら、次のようにチェックします。

Get-Command Set-SmbServerConfiguration -ErrorAction SilentlyContinue

何も返らない場合は、その環境では使えない可能性が高いので、素直に解決策A（レジストリ）へ寄せるのが安全です。

よくあるつまずきと対処（2008 R2の現場で多い）

症状	よくある原因	対処
レジストリを設定したのにログが出ない	サービス再起動/再起動していない	メンテ時間でLanmanServer再起動 or サーバー再起動
ログの場所が分からない	ログチャネル名が環境で異なる／無効	wevtutil el | findstr /i smbで候補を洗い出し、有効化して確認
SMB1接続の“テスト”をしたのに出ない	実際はSMB2/2.1で接続している	smbclientでSMB1指定、またはSMB1しか話せない機器で再テスト
クラスタで片ノードだけ設定してしまった	フェールオーバーでログが分散	全ノード設定＋アクティブノードのログ回収計画を作る
ログが大量に増えて見づらい	ログサイズ/保持期間が不足、上書きが早い	ログサイズ拡張、エクスポート運用、期間を区切って収集

SMB1無効化へ進む前の最終チェック

監査ログで棚卸しが進んだら、いよいよSMB1無効化へ進みます。ただし、ここで焦って切ると“最後の1台”が残っていて事故になります。以下のチェックを通してから切替するのが安全です。

チェック項目	OKの目安	補足
監査ログにSMB1接続が出ていない	業務ピークを含む一定期間でゼロ	1日だけではなく数日〜2週間程度
複合機/スキャナーの設定確認	SMB2以上で送れる設定になっている	機種によっては「SMB2」明示設定が必要
バックアップ/ジョブ系の確認	SMB1に依存しない	古いバックアップツールがSMB1固定の場合あり
切替手順とロールバック手順	手順書があり、戻し方も決まっている	無効化→影響→戻す、の判断基準を決めておく

どうしてもSMB1が必要な機器が残る場合の現実的な落としどころ

監査をしても、どうしてもSMB1しか話せない機器が残ることがあります。その場合、セキュリティと業務継続のバランスを取る“落としどころ”を用意しておくと進めやすいです。

• 機器のファーム更新でSMB2対応できないかを最優先で確認
• 機器を更改できない場合、SMB1専用の隔離セグメントに閉じ込め、アクセス制御・監視を強化
• 「スキャン to フォルダ」なら、SMB以外（FTP/SFTP、メール送信、Webアップロード等）に変更できないか検討
• どうしても残すなら、SMB1を本番ファイルサーバーから切り離す（中継サーバー/専用サーバーに寄せる）

ポイントは、SMB1を「全社の共有基盤」に残さないことです。残すにしても範囲を絞り、監視し、短期的な暫定対応として扱う方が安全です。

Windows Server 2008 R2がサポート終了であることも踏まえた推奨

Windows Server 2008 R2自体がサポート終了のため、SMB1棚卸し・無効化ができたとしても、長期的にはOS更改を前提にした方が安心です。SMB1問題は、実は「レガシーが温存されていることのサイン」でもあります。

• ファイルサーバー機能を新OSへ移行し、SMB2/SMB3を前提にする
• 認証方式や暗号化、監査ログ運用も合わせて設計し直す
• 「複合機・設備・端末」側の更新サイクルも可視化する

SMB1を止める作業は“単発の設定変更”ではなく、レガシーの棚卸しと更改を進める起点として扱うと、結果としてトラブルが減り、セキュリティも大きく改善します。

まとめ

• SMB1無効化は、いきなり実施すると業務影響が出やすい
• Windows Server 2008 R2では、レジストリでAuditSmb1Accessを有効化して監査ログを取るのが実用的
• ログの場所は環境差があるため、wevtutilでSMB系ログを検索し、有効化・エクスポートして棚卸しを進める
• 棚卸しが終わったらSMB1無効化へ。残る機器があるなら隔離などでリスクを局所化