「ドメインに参加する」——現場に入ってすぐに出てくるこの言葉、正確に説明できますか？
Windows環境を持つ組織であれば、Active Directoryは必ずと言っていいほど使われています。社員がPCにログインする、ファイルサーバにアクセスする、業務システムを使う——その裏側ではADが「誰がログインできるか」「何にアクセスできるか」を静かに管理しています。
ところが、ADは「触れば動く」という性質上、仕組みを理解しないまま運用しているケースが少なくありません。グループポリシーを手探りで設定する、管理者権限を広めに付与する、誰がどの権限を持っているか把握していない——そうした状態が積み重なると、ADは「便利な仕組み」ではなく「攻撃者にとって最高の足場」になります。
この記事では、ADとは何か・何をしているのか・なぜセキュリティ設計が重要なのかを、触り始めたばかりの若手エンジニアに向けて解説します。
「ドメインに参加する」の意味——ADがない世界から考える
ADの話をする前に、ADがない状態を想像してください。
100台のPCがある会社で、ADを使わずに運用するとこうなります。各PCにユーザーアカウントをそれぞれ作成する、パスワードポリシーはPC単位で設定する、ファイルサーバへのアクセス権は1台ずつ設定する、ソフトウェアの配布は各端末を個別に操作する——管理者にとっては悪夢です。
ADは、この問題を解決するために「1か所で全員を管理する」という考え方を実現しています。ユーザーアカウント・パスワードポリシー・アクセス権・ソフトウェア配布を一元管理する——これがADの本質です。
「ドメインに参加する」とは、このADの管理下に入ることを意味します。ドメイン参加したPCは、ADのルールに従い、ADのアカウントでログインできるようになります。
ドメイン（Domain） ADが管理するネットワークの単位。ドメイン内のユーザー・PC・サーバをADが一元管理する。
参考：Active Directory Domain Services の概要 | Microsoft Learn
Active Directoryとは何か——4つの機能で理解する
Active Directory（AD） Microsoftが提供するWindowsネットワーク向けのディレクトリサービス。ユーザー・コンピューター・グループなどのオブジェクトを一元管理する。
ADが提供する機能は大きく4つです。
① 認証（Authentication）——ログインできるかを確認する ADはドメイン内のユーザーが正しい本人かを確認します。PCの電源を入れてパスワードを入力する瞬間、その確認をしているのがAD（より正確にはドメインコントローラー）です。
② 認可（Authorization）——何にアクセスできるかを制御する 認証で「誰か」が確認されたあと、そのユーザーがどのファイル・システムにアクセスできるかを制御します。同じドメインのユーザーでも、営業部は営業フォルダのみ、開発部は開発サーバのみ——という制御をADのグループ設計で実現します。
③ ポリシー適用（Group Policy）——設定を一括で配布する パスワードの最低文字数、画面ロックまでの時間、USBの使用禁止——こうした設定をADのグループポリシー（GPO）で一括配布できます。100台のPCに同じセキュリティ設定を適用するために、1台ずつ触る必要はありません。
④ ディレクトリ管理——組織の情報を管理する ユーザーアカウント・グループ・コンピューター・プリンターなどをAD上で「オブジェクト」として管理します。どの部署に誰がいて、どのPCが存在するかをADで把握できます。
グループポリシー（GPO：Group Policy Object） ADからドメイン内のユーザーやコンピューターに設定を一括適用する仕組み。セキュリティ設定・ソフトウェア配布・スクリプト実行などを管理できる。
認証と認可の概念はクラウドIAMでも共通の考え方です。詳しくは「IAMとは？認証と認可の違いから学ぶアクセス管理の基本」を参照してください。
ADを構成する主要コンポーネント
ドメインコントローラー（DC）——ADの心臓部
ドメインコントローラー（DC：Domain Controller） ADを動かすサーバ。認証・ポリシー適用・ディレクトリ情報の管理を担う。DCが止まるとドメイン認証ができなくなるため、通常2台以上の冗長構成にする。
DCはADの中核です。ユーザーがPCにログインするとき、そのパスワードを照合しているのはDCです。DCが1台しかない環境でそのサーバが障害を起こすと、ドメイン内の全ユーザーがログインできなくなります。
OU（組織単位）——管理の単位を作る
OU（Organizational Unit：組織単位） AD内でユーザーやコンピューターをグループ化する管理単位。部署・拠点・役割ごとに分けて、GPOの適用範囲を制御するために使う。
OUは「ADの中のフォルダ」のようなものです。「東京本社」「大阪支社」「開発部」「営業部」のようにOUを作り、そこに所属するユーザーやPCをまとめて管理します。OUごとに異なるGPOを適用できるため、「開発部だけUSB使用を許可する」「管理者OUには強いパスワードポリシーを適用する」といった柔軟な設定が可能になります。
OU設計の具体的なパターンについては「ADのドメインとOU設計｜組織構造をActive Directoryに落とし込む」（公開予定）で詳しく解説します。
グループ——権限をまとめて管理する
セキュリティグループ ユーザーをまとめてアクセス権を一括管理するためのADオブジェクト。個人ではなくグループに権限を付与することで管理を効率化する。
「営業部グループ」に営業フォルダへのアクセス権を付与し、そのグループに営業部員を追加するだけで全員がアクセスできるようになります。異動のときはグループの所属を変えるだけで権限が切り替わります。個人ごとに権限を設定するより管理コストが大幅に下がります。
この「役割ベースでグループに権限を付与する」考え方は、クラウドのRBACと同じ思想です。詳しくは「RBACとは？クラウド権限管理の基本とAzure RBACの仕組みをわかりやすく解説」も参照してください。
参考：Active Directory のベスト プラクティス | Microsoft Learn
ADの認証はどう動くのか——KerberosとNTLMの役割
ADの認証を支えているのは主に2つのプロトコルです。この2つを知っておくと、後述する攻撃手法がなぜ成立するのかが理解できます。
Kerberos——チケットで認証するADの主役
Kerberos ADが標準で使用するチケットベースの認証プロトコル。パスワードをネットワーク上でやり取りせず、チケット（TGT）を使って認証する。Windows 2000以降のAD環境で標準採用。
Kerberosの仕組みを一言で表すと「パスワードを直接送らずにチケットで認証する」です。ユーザーがログインするとDCからチケット（TGT）を受け取り、そのチケットを使って各サーバにアクセスします。パスワードが毎回ネットワークを流れないため、盗聴に強い設計になっています。
TGT（Ticket Granting Ticket） Kerberosの認証で最初に発行されるチケット。これを持っていることで各サービスへのアクセスチケットを取得できる。GoldenTicket攻撃はこのTGTを偽造する手法。
NTLM——後方互換で残る旧来の認証方式
NTLM（NT LAN Manager） Kerberosより古い認証プロトコル。パスワードのハッシュ値を使ってチャレンジ・レスポンス方式で認証する。古いシステムとの互換性のためAD環境でも残存している。
NTLMはKerberosが使えない場面（古いシステム・ワークグループ環境など）で使われます。Kerberosより弱い点がいくつかあり、特にパスワードのハッシュ値が攻撃に利用されるPass-the-Hash攻撃の原因になります。
なぜ2つが共存しているのか
Kerberosが標準ですが、NTLMは互換性のために残っています。問題は「NTLMを使わないと動かない古いシステムがある」という現場の事情です。完全に無効化できないため、NTLM経由の攻撃リスクが残り続けます。
これらの弱点を突いた攻撃手法（Pass-the-Hash・Kerberoasting・GoldenTicketなど）の詳細は「AD攻撃手法と要塞化」（公開予定）で解説します。
参考：Kerberos 認証の概要 | Microsoft Learn
クラウドとADの関係——Microsoft Entra IDとは何か
Microsoft Entra ID（旧称：Azure Active Directory） MicrosoftのクラウドベースのID管理サービス。オンプレADとは別物だが、連携することでハイブリッド環境を構成できる。
「Azure ADとオンプレのADは同じもの？」という質問は現場でよく出ます。答えはNoです。オンプレADはWindowsサーバ上で動くディレクトリサービス、Entra IDはクラウド上のIDサービスで、設計思想も管理方法も異なります。
ただし2つを連携させる「ハイブリッド構成」を取ることで、オンプレのアカウントをクラウドサービス（Microsoft 365・Azureなど）でも使えるようになります。現在多くの企業がこのハイブリッド構成を採用しています。
クラウド側の権限管理（RBAC・PIM）については既存記事で解説しています。Entra IDとオンプレADの連携設計の詳細は「Entra IDとオンプレAD連携｜ハイブリッド構成の設計と注意点」（公開予定）で解説します。
ADのセキュリティ設計で押さえるべき3つの視点
ADを「動かす」のと「守れる状態にする」のは全く別の話です。セキュリティ設計として押さえるべき視点を3つ整理します。
① 最小権限——管理者権限を日常的に使わない
ADで最も危険な権限がDomain Admins（ドメイン管理者）です。このグループに所属するアカウントはドメイン全体を操作できます。侵害されたときの被害が最大になる権限でもあります。
Domain Admins ADのドメイン全体に対する管理者権限を持つグループ。所属アカウントが侵害されるとドメイン全体が攻撃者の手に渡る。
実務での基本は「日常業務には一般アカウントを使い、管理作業だけ専用の管理者アカウントを使う」です。若手10選でも「ドメイン管理者権限の重さを知る」として取り上げた通り、この感覚を持てるかどうかがセキュリティ強度に直結します。「若手インフラエンジニアが最初に身につけるべきセキュリティ知識10選」も合わせて参照してください。
最小権限の考え方の詳細は「最小権限の原則とは？実務での考え方と設計例」で解説しています。
② グループ設計——役割ベースで権限をまとめる
個人ごとにアクセス権を設定すると、異動・退職のたびに設定変更が発生し、誰がどの権限を持っているか把握できなくなります。基本は「グループに権限を付与し、人をグループに入れる」です。
役割が変わったときはグループ所属を変えるだけで権限が切り替わります。これにより棚卸しも容易になり、不要な権限の残存を防げます。
ADのグループ設計の実践については「ADのユーザーとグループ管理｜最小権限を実現する設計パターン」（公開予定）で詳しく解説します。
③ 監査——何が起きているかを見える状態にする
ADは設計するだけでなく、「何が起きているか見える状態にする」ことが重要です。誰がいつログインしたか、特権グループへの追加が行われていないか、認証の失敗が多発していないか——これらはWindowsのイベントログで確認できます。
セキュリティイベントログ Windowsが記録する認証・権限変更・アクセス失敗などのセキュリティ関連イベントの記録。異常検知・インシデント対応の証跡として活用する。
ログを「取るだけ」でなく「読める状態にする」設計については「ADイベントログ監査｜正常・異常の見分け方と攻撃の兆候を追う実務ガイド」（公開予定）で解説します。
参考：Active Directory をセキュリティで保護するためのベスト プラクティス | Microsoft Learn
まとめ——ADは「設定するもの」ではなく「設計するもの」
ADはWindowsネットワークの認証基盤です。ユーザーのログイン・アクセス権の制御・設定の一括配布を一元管理し、組織のITインフラを支えています。
しかしADは「動かすこと」より「正しく設計すること」の方がはるかに重要です。グループ設計が曖昧なまま運用すれば権限がブラックボックスになり、管理者権限を広く使えば侵害時の被害が最大化し、ログを見ていなければ攻撃が始まっても気づけません。
まず今日確認すべきことは2つです。自分の環境でDomain Adminsに所属しているアカウントが適切に管理されているか。そしてWindowsのセキュリティイベントログが有効になっているか。そこから始めてください。
このブログのADクラスターでは、OU設計・GPO設計・グループ管理・特権アカウント管理・イベントログ監査・攻撃手法と要塞化について順次解説していきます。
あわせてご覧ください
コメント