「最新版のADMX/ADMLを中央ストアに入れたのに、Lanman Workstation／Lanman Server／SMBの詳細ポリシーがGPOに見当たらない」──現場で頻発するこの疑問は、実は仕組みを正しく理解すれば解決できます。本記事は“どこに設定があるのか”“どう配布すべきか”を、実運用レベルの手順と検証観点まで含めて体系的に整理しました。
結論：SMBの「基本」はセキュリティ オプション、「高度」はSecurity Baseline（SCT）
まず大枠の把握が重要です。
- ADMXに頼らずとも既定で存在するSMB/Lanmanの基本的なセキュリティ項目がある（セキュリティ オプション）。
- 最小SMBバージョンの強制、暗号化の必須化、SMBv1の徹底無効化、署名未対応クライアントの可視化などの高度な制御は、ADMXではなく「Security Baseline」GPOとして提供・適用するのが王道。
- ADMX/ADMLの更新は無駄ではない。最新OSの管理テンプレートが増えるため、ポリシーエディタに新規項目を出す基盤としては必須。ただしSMBの詳細制御はADMXに含まれないことが多い点に留意。
どこに何がある？（設定の所在マップ）
| 目的 | 推奨の設定場所／方法 | 例 | 備考 |
|---|---|---|---|
| SMB署名（クライアント/サーバー） | セキュリティ オプション | Microsoft ネットワーク クライアント/サーバー: 通信のデジタル署名 (常に) | GPOの標準機能。ADMX不要。 |
| SMBv1の無効化 | Security Baselineまたはスクリプト（機能削除） | SMB 1.0/CIFSの削除（PowerShell/機能） | 「機能」の有効/無効で扱うのが確実。 |
| 最小SMBバージョンの実質的な強制 | Security Baseline + 署名/暗号化の併用 | SMB2/3必須の運用（SMB1無効化） | 「最小バージョン」直指定より、SMB1排除＋安全機能必須化で実現。 |
| SMB暗号化の必須化 | Security Baseline または PowerShell（サーバー既定/共有単位） | サーバー既定 EncryptData 有効、共有 EncryptData 有効 | SMB3以降で有効。古いクライアントは接続不可に。 |
| 署名不対応クライアントの監査 | Security Baseline（イベントの可視化）＋ログ分析 | SMBServer/SMBClientのイベントログ、Get-SmbConnection | 「監査のみ」で段階適用し、のちに「強制」へ。 |
GPOに“Lanman/SMBの新しい項目が出ない”根本原因
「最新ADMXを中央ストアに入れたのに見当たらない」ときは、そもそもその設定がADMXで提供されていない可能性が最も高いです。SMBに関する多くの安全設定は、古くからセキュリティ オプション（ローカル ポリシー）で提供されており、ここにはADMXの有無に関係なく項目が出ます。また、近年推奨されるSMBv1の無効化や暗号化の既定化は、Security Baseline（SCT）によるGPOとして配布する方式が実践的です。
基本：セキュリティ オプションで押さえる項目
編集パス：
コンピューターの構成 → ポリシー → Windows の設定 → セキュリティの設定 → ローカル ポリシー → セキュリティ オプション
- Microsoft ネットワーク クライアント: 通信のデジタル署名 (常に)
- Microsoft ネットワーク サーバー: 通信のデジタル署名 (常に)
これらはSMB署名の必須化に直結します。ドメイン内の全端末に適用する場合は、OU単位での段階適用が安全です。
高度：Security Baseline（SCT）で一気に進める
最小バージョンの実質強制（SMB1の徹底排除）や暗号化既定化などは、Microsoft Security Compliance Toolkitに含まれる各OS向けのSecurity Baseline GPOを「バックアップから復元」で取り込み、組織用に複製／調整してリンクします。
- 対象OSのBaselineアーカイブを入手し展開。
- GPMCで「グループ ポリシー オブジェクト」右クリック → バックアップからの復元 → ZIP内のGPOsフォルダを指定。
- 復元されたGPOを複製し、組織用の命名規則（例：SEC-Baseline-Server2022-Core）で管理。
- 必要に応じて編集（署名「監査→必須」への移行計画、暗号化の段階適用など）。
- テストOUにリンク → 段階ロールアウト。
ポイント：Baselineは「そのまま本番に適用」ではなく、監査のみでリスクを可視化してから強制へ切り替える二段階が定石です。
ADMX/ADMLの更新は必要か？
はい。最新OSのポリシー項目を編集できるようにするため、中央ストア（SYSVOL:\PolicyDefinitions）へ最新ADMX/ADMLを展開することは必須です。ただし、SMB詳細設定の有無はADMX更新の可否とは別問題です。行ったうえでGPMCを再起動し、表示項目を更新してください。
導入から検証までの実践フロー
1) 事前準備
- 中央ストアをバックアップし、最新のADMX/ADMLに更新。
- 代表的なファイルサーバー/クライアントをテストOUに移動。影響の大きい業務共有（NAS/複合機プリントサーバー等）を洗い出し。
- レガシー機器のSMBサポート状況（特にSMBv1依存）を棚卸し。
2) 基本ポリシーの適用（セキュリティ オプション）
- クライアント/サーバー双方でSMB署名（常に）を「有効」へ。
- 適用後、テストクライアント上で
Get-SmbConnectionを実行し、SignedがTrueであることを確認。
3) Security Baselineのインポートと段階適用
- GPMCでBaseline GPOを復元。
- 最初は「監査のみ（Audit）」状態が得られるように調整（署名は「常に」を維持しつつ、暗号化は既定化せずログ監視中心）。
- 1～2週間の監査で影響先を特定 → 例外（レガシー）に対する置換/更改の計画を確定。
- 署名/暗号化を段階的に強制へ切替。共有単位の暗号化（次章参照）を併用。
4) 検証と可視化
gpresult /h c:\temp\gp.htmlで端末側の適用状況をエビデンス化。- サーバー側で
Get-SmbServerConfiguration、クライアント側でGet-SmbClientConfigurationを採取。 Get-SmbConnection | Select ServerName,ShareName,Dialect,Signed,Encryptedの出力を日次採取し、未署名/未暗号の接続を洗い出し。
サンプル：GPOのスタートアップ スクリプトで一括適用
Baselineに加え、次のPowerShellをスタートアップ（コンピューター）で配布すると、署名/暗号化/SMBv1排除の「運用上の抜け」を減らせます。
# サーバー側の既定（全共有に対して安全性を底上げ）
# ※本番前にかならずテストOUで検証してください
Try {
Set-SmbServerConfiguration -RequireSecuritySignature $true -EnableSecuritySignature $true -Force
# SMB1の無効化（機能として扱うのが確実）
# サーバー（Windows Server）の場合：
# Uninstall-WindowsFeature FS-SMB1 -ErrorAction SilentlyContinue
# クライアント（Windows 10/11）の場合：
# Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart -ErrorAction SilentlyContinue
# 暗号化をサーバー既定で有効化（SMB3以降のみ接続許可）
Set-SmbServerConfiguration -EncryptData $true -Force
# 既存共有にも暗号化を明示（IPC$などの特殊共有は除外）
Get-SmbShare | Where-Object { $_.Special -eq $false } | ForEach-Object {
Try { Set-SmbShare -Name $_.Name -EncryptData $true -ErrorAction Stop } Catch {}
}
# 監査の強化（SMB1アクセス検知など）
Set-SmbServerConfiguration -AuditSmb1Access $true -Force
} Catch {
# ログ出力（必要に応じてイベントログへ）
} 注意：SMB暗号化の既定化は古いクライアント/機器を遮断します。まず「監査のみ」で影響範囲を可視化し、段階的に移行してください。
グループ ポリシー環境での“運用のコツ”
- 中央ストア更新後はGPMCを再起動。MMCのキャッシュで「新しいテンプレートが見えない」誤認を防止。
- セキュリティ フィルタリングは原則「Authenticated Users（読み取り＋適用）」＋必要に応じてスコープを限定。リンクの強制（Enforce）やブロック継承は最小限に。
- WMIフィルターでOS世代を分けて適用。例：Version like 10.* and ProductType=3（Server）など。
- テスト→パイロット→段階展開の順で、荒い網から細い網へ可視化・強制を移行。
レジストリ（GPP）で補完する場合の代表値
PowerShellで既定を制御するのが簡潔ですが、グループ ポリシーの「基本設定（GPP）→レジストリ」で配布したいケースもあります。主要な署名関連は次の通りです（OSにより差異があるため、テスト必須）。
| 役割 | キー | 値 | 型 | 意味 |
|---|---|---|---|---|
| クライアント | HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters | EnableSecuritySignature=1 RequireSecuritySignature=1 | DWORD | SMB署名を使用／必須 |
| サーバー | HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters | EnableSecuritySignature=1 RequireSecuritySignature=1 | DWORD | SMB署名を使用／必須 |
| サーバー（参考） | HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters | EncryptData=1 | DWORD | 暗号化の既定化（SMB3以降） |
SMBv1無効化は「機能の削除」に当たるため、GPPレジストリだけでの完全制御は推奨しません。機能削除（クライアント系はOptional Feature、サーバー系は役割/機能）をスクリプトで確実に実行する方が安全です。
監査・可視化の実際
「まず監査」は安全移行の鉄則です。以下の観点で“見える化”を進めます。
- SMBServer/SMBClient イベントログ（アプリケーションとサービス ログ配下）を収集し、暗号化なし/署名なしの接続を検知。
- 日次で
Get-SmbConnectionを採取し、Dialect（協定バージョン）、Signed、Encryptedを監視。 - SIEM/ログ基盤に「未署名/未暗号」の接続が来たらアラートを上げるルールを整備。
# 簡易収集例（タスクスケジューラ等で実行）
$log = Get-SmbConnection | Select-Object ServerName, ShareName, Dialect, Signed, Encrypted
$log | Where-Object { -not $_.Signed -or -not $_.Encrypted } | Out-File "C:\Windows\Temp\SmbWeakSessions.log" -Append
「署名未対応クライアントの監査」については、いきなりRequireにせず、まずはログ収集・可視化で接続元/業務影響を絞り込み、置換計画と並行して最終的にRequireへ移行するアプローチが現実的です。
よくあるつまずき
- ADMXを更新したのに項目が出ない：GPMCの再起動を忘れている、または言語別ADML（例：ja-JP）を配置していない。
- Baselineを入れても変化が見えない：リンクしていない／WMIフィルターが適用外／セキュリティ フィルタリングで適用が外れている。
- 古いNAS/複合機が接続不可：SMBv1依存。監査期間に必ず洗い出し、ファーム更新/機器更改/プロトコル代替（FTP/HTTPs印刷）などの回避を用意。
- 共有の暗号化で速度が落ちた：CPUオフロード/暗号アルゴリズム/SMBダイレクト（RDMA）等の設計を再検討。すべての共有を一律暗号化するのではなく、機密度に応じて段階付けを。
「監査→強制」の段階移行モデル（テンプレ）
| フェーズ | 期間目安 | 実施内容 | 出口基準 |
|---|---|---|---|
| 監査 | 2〜4週間 | 署名/暗号化を「監査」中心に。未署名/未暗号セッションのログ集約。 | 影響端末/機器が特定され、対応計画が承認済み。 |
| パイロット強制 | 1〜2週間 | 限定OUで署名「常に」、共有暗号化を優先度の高い共有から適用。 | 業務影響が許容内、性能測定の結果が基準を満たす。 |
| 全社展開 | 2〜6週間 | OUごとに順次リンク。残存例外を許可リスト化。 | 未署名/未暗号セッションが検出されない。 |
FAQ：本件の“よくある質問”
Q. 期待するLanman/SMBのポリシーはADMXに含まれる？
A. 多くは含まれません。SMB署名などはセキュリティ オプションに元々あります。SMBv1無効化や暗号化既定化、詳細な監査などはSecurity Baseline（SCT）のGPOで適用するのが実践的です。
Q. ADMXの入手先は間違っていない？
A. 入手先自体は通常正しいはずです。ADMX/ADMLは最新OSのテンプレート追加が主目的で、SMB詳細制御の追加とは直結しない点が誤解されがちです。
Q. どうやって影響を最小化する？
A. 監査→強制の段階移行に尽きます。Get-SmbConnection とイベントログで実態を可視化し、例外を事前処理してから強制へ。移行は共有単位（重要度の高い共有から）で行うと安全です。
運用テンプレート（チェックリスト）
- 中央ストア（PolicyDefinitions）を更新し、GPMCを再起動した。
- セキュリティ オプションで署名（常に）をクライアント/サーバー双方に適用した。
- Security Baselineを復元し、テストOUにリンクした。
- SMBv1の無効化をスクリプトで実施し、古い機器の影響を棚卸しした。
- 暗号化はまず監査で可視化、のちに共有単位で強制した。
- gpresult と PowerShell（Get-SmbServerConfiguration / Get-SmbClientConfiguration / Get-SmbConnection）で適用と効果を証跡化した。
実務ノウハウ：共有単位の段階暗号化
「全共有を一括でEncryptData有効」はリスクが高い場合があります。機密度/業務重要度で共有を分類し、優先度の高い共有から暗号化を強制しましょう。
| 分類 | 対象例 | 暗号化適用 | 備考 |
|---|---|---|---|
| 高 | 人事・経理・設計 | 即時強制 | 暗号化による性能影響を受容。 |
| 中 | 部門共有 | パイロットで性能確認後、順次 | キャッシュ/オフロード有効化を検討。 |
| 低 | 一時ファイル/開発ビルド | 最終フェーズで適用 | 必要に応じて除外の妥当性を評価。 |
トラブル対処（ケース別）
古い複合機/NASがスキャン書き込みできない
SMBv1依存の可能性。SMBv2対応のファーム/モデルへの更新、または代替プロトコル（FTP/HTTPSアップロード）でのワークアラウンドを整備のうえ、最終的に更改。
アプリケーションの共有アクセスが遅い
SMB暗号化/署名のオーバーヘッドか、ネットワーク/CPUボトルネック。RDMA（SMB Direct）、NICオフロード設定、暗号アルゴリズムの影響、マルチチャネル有効化等を再評価。
ポリシーが競合して結果が読めない
リンク順序と優先度を整理し、GPMCの結果セット（RSOP）で競合を特定。Baselineと既存GPOの役割分担を明確化。
まとめ：迷ったら“所在”から逆引きする
- セキュリティ オプション：署名（常に）などの基本はここ。
- Security Baseline（SCT）：SMBv1排除、暗号化の既定化、監査テンプレなど高度な制御はここ。
- スクリプト/GPPで補完：機能削除（SMB1）や共有単位の暗号化など、GPOだけで足りない部分を確実に。
この“所在マップ”を起点に、監査→強制の段階移行、gpresult/PowerShell/イベントログでのエビデンス化を組み合わせれば、Lanman/SMBの統制は安全に全社適用できます。「ADMXに入っていない＝設定できない」ではありません。GPOの標準機能＋Baseline＋スクリプトを正しく組み合わせて、堅牢かつ再現性の高いガバナンスを実現しましょう。
コメント