日々の運用や監査が厳しくなる中、Active Directory(AD)のセキュリティ強化は組織を守るうえで欠かせない対策の一つです。Tenableのスキャンで検出される「AD Starter Scan (プラグインID: 150480)」への対応は、その第一歩といえます。この記事では具体的な対処手順や運用のポイントを分かりやすく解説します。
AD Starter Scan（プラグインID: 150480）とは？
Tenableのスキャンを実施すると、Active Directoryサーバー上に「AD Starter Scan」という脆弱性が検出されることがあります。これはプラグインIDが「150480」で、報告される内容として「Primary Group ID Integrity」に関わる問題が指摘されるのが特徴です。
検出される脆弱性の概要
特定のADアカウントの「Primary Group ID」が、標準とは異なる値（例：6604）になっている場合にレポートに表示されます。本来、ADユーザーのプライマリグループは「Domain Users (ID: 513)」などが一般的な既定値ですが、何らかの理由で異なるIDが割り当てられていると、この脆弱性として検知されることがあります。
なぜこの問題が重要なのか
「Primary Group ID」が本来の値から変更されていると、以下のようなリスクが発生する可能性があります。
- グループメンバーシップの整合性が崩れ、権限設定に想定外の影響が及ぶ
- セキュリティ制御が意図せず緩くなり、外部からの不正アクセスにつながるリスク
- 管理者アカウントやサービスアカウントの権限管理が混乱し、脆弱性を生む原因
特に大規模環境や複数ドメインコントローラーを運用している場合は、早期の確認と対策が望まれます。
対策の大原則：Primary Group IDを標準に戻す
この脆弱性に対するTenableの推奨は、「Primary Group IDをデフォルトに戻す」ことです。具体的には、該当ユーザーが所属すべきグループのID（多くは「Domain Users (ID: 513)」）に再設定します。ここでは詳細な手順と共に、対応時の注意点をご紹介します。
対応前に知っておくべき事前確認ポイント
- 影響範囲の把握
- まずは「6604」が設定されているユーザーが何人いるのか、どのような権限を持っているのかを把握しましょう。
- 「AD Starter Scan」のレポートやTenableの管理コンソールから詳細を確認し、対象となるアカウントの使用状況、運用上の重要度をチェックします。
- AD環境のバックアップ
- Active Directoryは企業の基幹システムとも言えるため、設定変更前には必ずシステムのバックアップを行い、復旧手順を確立しておくことが大切です。
- System Stateバックアップやサードパーティツールを用いたバックアップなど、最適な方法を選択しましょう。
- 変更に伴う運用影響の検討
- Primary Groupを変更することで、既存のアクセス権やグループポリシー適用に問題が生じる可能性があります。
- 事前にテストユーザーで試験環境を作成し、同様の変更を行った場合にどのような影響があるかを検証するのがおすすめです。
実際のPrimary Group ID変更方法
AD管理ツール（Active Directoryユーザーとコンピュータ）を用いる場合
最も一般的な方法は、Windows Serverに標準搭載されている「Active Directoryユーザーとコンピュータ(ADUC)」を使うやり方です。
- 「Active Directoryユーザーとコンピュータ」を起動
- ドメインコントローラー、またはAD管理ツールがインストールされた管理用マシンから起動します。
- 対象ユーザーを検索
- 組織単位(OU)やコンテナを指定して該当ユーザーアカウントを探します。
- 可能であれば「フィルター」機能を用いて迅速に対象を特定します。
- ユーザーのプロパティを開く
- 該当ユーザーを右クリックして「プロパティ」を選択し、「所属するグループ」または「メンバーシップ」タブを表示します。
- プライマリグループの設定を変更
- ここでプライマリグループを確認し、「Domain Users (ID: 513)」などの既定グループを選択して変更します。
- 「OK」をクリックし、設定を保存します。
- レプリケーションの完了を待つ
- 複数ドメインコントローラー環境下では、設定変更が全ドメインに反映されるまで時間がかかる場合があります。
- しばらくしてから、どのドメインコントローラーでも設定が反映されているか確認します。
PowerShellを用いて大量ユーザーを一括変更する場合
大規模環境で該当アカウントが多数ある場合、PowerShellで一括変更すると効率的です。以下は代表的なコマンド例です。
# 該当ユーザーのPrimary Group IDを513(Domain Users)に変更するサンプル
Set-ADUser -Identity "<ユーザーのSamAccountNameまたはDN>" -Replace @{primaryGroupID=513}もし複数ユーザーに対して実行したい場合は、以下のようにパイプラインを利用して一括処理します。
# OU内にあるPrimary Group IDが6604のユーザーをすべて513に変更する例
Get-ADUser -Filter {primaryGroupID -eq 6604} -SearchBase "OU=TestOU,DC=example,DC=com" |
ForEach-Object {
Set-ADUser -Identity $_.SamAccountName -Replace @{primaryGroupID=513}
}スクリプト実行時の注意点
- 権限：ドメイン管理者など、十分な権限を持つアカウントで実行する必要があります。
- テスト：実際の本番環境で一度に大量変更を行う前に、必ずテスト環境や限定したユーザーで検証しましょう。
- ログ出力：変更履歴を残すためにも、スクリプト実行時はログを取得しておくとトラブルシュートに役立ちます。
グループID変更による副作用とその対処
グループポリシーの適用範囲の変化
プライマリグループの変更によって、特定のGPOが当たらなくなる可能性があります。通常、主要な権限付与は他のセキュリティグループで管理されることが多いため、影響は限定的かもしれませんが、念のためGPOが想定通り適用されているか検証を実施しましょう。
アプリケーション依存性の確認
アプリケーションによっては、ユーザーのプライマリグループを参照してアクセス制御やライセンス管理を行っている場合があります。該当アプリケーションのマニュアルや運用ドキュメントを確認し、不具合が発生しないか確認しておくことが必要です。
セキュリティ対策を強化する周辺施策
定期的なパッチ適用と更新プログラム
ADサーバーを含むWindows Serverは、定期的にセキュリティパッチをリリースしています。新たな脆弱性が発見された場合や、既知の問題に対する修正プログラムが公開された場合は、早めに適用し、環境を最新の状態に保ちましょう。
監査ログ・イベントログの厳密な運用
Active Directoryの操作履歴やイベントログを定期的に確認することで、想定外の変更や不正アクセスの兆候を早期発見できます。SysmonやSIEMツールと連携させることで、さらに包括的な監視が可能になります。
監査ログ強化の一例（Audit Policy設定）
監査ポリシーを細かく設定することで、ユーザーの追加・削除やグループポリシーの変更、ログオン失敗などのイベントを詳細に記録できます。以下の表は代表的な監査項目と推奨設定の例です。
| 監査カテゴリ | 推奨設定 | 理由 |
|---|---|---|
| アカウントログオンイベント | 成功、失敗 | 不正ログインの試行や失敗回数の監視 |
| アカウント管理 | 成功、失敗 | ユーザーやグループの作成・削除・変更などの履歴 |
| ディレクトリサービスアクセス | 成功、失敗 | ADオブジェクトへのアクセス監視 |
| 権限の使用 | 成功、失敗 | 特権アカウントがどの操作を行ったかを追跡 |
LDAP通信やグループポリシーの保護
- LDAPS（SSL/TLS）：LDAP通信を平文のままやりとりするのではなく、LDAPSを使うことでパスワードなどの機密情報が保護されます。
- グループポリシーの整合性確認：不審なGPOや設定が入っていないか定期的に確認し、不要な設定は削除や無効化を行いましょう。
不要サービスの無効化
Active Directoryサーバーで稼働している不要なサービス（プリントスプーラーなど）が脆弱性を生むケースもあります。利用目的がなければ停止、あるいは無効化を検討します。
運用管理を強化して安定運用を実現
定期的なバックアップの重要性
AD環境が破損したり、セキュリティ侵害を受けた場合に備えて、システムを迅速に復元できるバックアップ戦略は必須です。以下のようなポイントを押さえておきましょう。
- System Stateバックアップ：ADデータベース、SYSVOL、レジストリなどを含む重要要素をカバー
- バックアップの検証：定期的にリストアテストを実行し、復元手順が実際に成功することを確認
- 冗長化：可能であれば別リージョンやオフライン媒体にもバックアップを保管し、災害時に備える
権限設定の再点検
- 最小権限の原則：管理者やサービスアカウントに不要な権限が付与されていないか定期的に見直しましょう。
- グループポリシーのRole-Based Access Control (RBAC)の検討：特定の役職や役割に応じてグループ分けを行い、一括管理できるようにするとミスを減らせます。
スキャンツールの継続利用とレポート運用
Tenableを含む脆弱性スキャンツールを継続的に運用することで、新たに発生した脆弱性や設定ミスを早期発見できます。レポート結果を定期的に振り返り、環境をより安全に保つ習慣を持つことが大切です。
具体的Q&Aと想定シナリオ
Q1. Tenableレポートに「Primary Group IDをデフォルトに戻す」とあるが、どのIDに戻すのが最適？
A. 一般的には「Domain Users (ID:513)」が最適解です。ただし、アプリケーションや特別なポリシーで別のグループIDを指定している場合は、その要件を事前に確認しましょう。
Q2. 「6604」に設定されているユーザーだけでなく、他の異常値はないか確認するには？
A. PowerShellのGet-ADUserコマンドでprimaryGroupIDをフィルターするか、dsqueryやldifdeなどのコマンドを使用して一覧を取得する方法がおすすめです。未知の値が見つかった場合も同様の手順で修正を行います。
Q3. Primary Group IDの変更後、すぐに反映されないのはなぜ？
A. ADはドメインコントローラー間でレプリケーションを行うため、全てのコントローラーに反映されるまでタイムラグがあります。運用上、数分から数十分程度で行き渡るのが一般的ですが、大規模環境ではやや長めになることもあります。
Q4. 設定変更後に権限まわりで問題が出たときはどうする？
A. バックアップからのリストアを検討するか、一時的に元のGroup IDに戻すことができます。ただし、根本的には運用やポリシーの再検討が必要です。変更前の状態に戻すだけでは、本当の解決にならない場合も多いので注意しましょう。
Q5. AD Starter Scan以外にも同時に報告された脆弱性をまとめて対処したいが、優先順位は？
A. まずはADへの影響範囲が大きいもの、あるいは重大度が高いものから優先的に対応しましょう。例えば認証まわりに影響する脆弱性はシステム全体を危うくする可能性があるため、早急な措置が必要です。
まとめと次のステップ
「AD Starter Scan (プラグインID: 150480)」に起因する脆弱性の多くは、Active DirectoryユーザーのPrimary Group IDが標準とは異なる値に設定されていることにより検知されます。これを「Domain Users (ID: 513)」などの適切な既定値に戻すだけでも、レポートで指摘される問題の大部分は解消されるでしょう。
しかし、組織全体を守るためには、OSやAD自体の定期的なパッチ適用や脆弱性スキャン、権限設定の見直し、ログ監視やバックアップ戦略の強化といった包括的な対策が不可欠です。特にADは認証やアクセス制御の根幹を担う重要な基盤であるため、日々のメンテナンスを怠らず、継続的に安全性を向上させる取り組みを行うことが、最終的には組織のリスク低減に繋がります。
コメント