この連載について
Active Directory を「機能の一覧」ではなく「なぜその機能が必要になったのか」から説明する連載です。各記事は答えられるようになる問いを掲げています。
この記事は「全体像編」です。
この連載の最初の記事です。AD に触れたことがない方でも読めます。
続きは順次公開します。
この記事の注意事項
- 社内勉強会用に作成した資料を、公開用に整えたものです。個人の見解であり、所属組織を代表するものではありません。
- 製品仕様（Windows Server の機能レベル、AWS Directory Service のエディションなど）は変わります。設計・提案に使う際は必ず最新の公式ドキュメントで確認してください。 記事末尾に参考リンクを置いています。
- 一部に実機で検証していない箇所があります。該当箇所にはその旨を明記しています。
- 誤りや古い記述にお気づきの場合、コメントでご指摘いただけると助かります。
対象: サーバー・ネットワーク・DNS の基礎知識を持ち、これから AD の構築・設計補助・障害切り分けに関わる人（AD の経験は不要）
この連載の到達点: AD の基本構造を理解し、代表的な障害について一次切り分けができること
この記事のゴール: AD が何のために生まれ、どの機能が土台で、どれが応用かを俯瞰できる状態
この資料について
予定しているテーマ
各記事は「読み終えたときに答えられる問い」を掲げています。以下の順で公開していきます（構成は今後変わることがあります）。
| テーマ | 読み終えたときに答えられる問い |
|---|---|
| 全体像編（この記事） | 「なぜ AD にこれだけの機能があるのか」「AD DS で解ける問題と解けない問題は何か」 |
| 認証編 | 「クライアントがドメイン参加できない。何をどの順に確認するか」 |
| GPO 編 | 「GPO を設定したのに一部の端末で効かない。何をどの順に確認するか」 |
| 権限編 | 「既存の AD 環境を引き継いだ。権限まわりで最初に何を確認するか」 |
| 冗長化・運用編 | 「片方の DC で作ったユーザーが、もう片方で見えない。何を疑うか」 |
| AWS 編 | 「EC2 の DC にインスタンスをドメイン参加させたい。何をどの順に設定するか」 |
| 設計編 | 「お客様にユーザー削除だけをさせたい。何をどう設計するか」 |
全体像編だけは手を動かす前提知識を必要としません。AD に触れたことがない方でも読めます。ここで全体像をつかんでから、認証編以降の個別機能に進んでください。
この記事を最初に置く理由
Active Directory は多機能で、初学者から見ると機能が雑然と並んでいるように見えます。DNS があり、Kerberos があり、GPO があり、レプリケーションがあり、証明書があり、フェデレーションがある。なぜこれらが1つの製品にまとまっているのか、最初は分かりません。
個別の機能から学び始めると、どれが重要でどれが後回しでよいかの判断がつきません。だからこの記事では、機能の説明をしません。代わりに次の順で見ていきます。
- どんな困りごとがあって AD が生まれ、どう機能が増えてきたか（第0節）
- そもそもディレクトリサービスとは何か（第1節）
- 認証と認可は何が違うのか（第2節）
- Kerberos とは何者で、なぜ AD の中心にいるのか（第3節）
- 「AD」と呼ばれる複数の製品の整理（第4節）
- 用語の地図と、機能の重要度マップ（第5〜6節）
第1節から第3節は、AD 固有ではない一般的な基礎概念です。他の場面でも使えます。
前提とする知識
この連載を通じた前提です。右の列は説明しますので、知らなくても問題ありません。
| # | 分野 | 前提とします（説明を省きます） | 前提としません（この資料で説明します） |
|---|---|---|---|
| 1 | DNS の基礎 | A レコード、CNAME、ゾーン、リゾルバー、フォワーダー | SRV レコード（認証編） |
| 2 | DNS の運用 | 名前解決に失敗すると通信できないという因果 |
動的登録（サーバーが自分で DNS にレコードを書く仕組み）、_msdcs という特殊な名前空間 |
| 3 | ネットワーク | TCP/UDP とポート番号、ファイアウォールの考え方 | AD が使うポート群（RPC 動的ポートを含む） |
| 4 | 認証の一般知識 | ID とパスワードで認証するという基本的な考え方 | Kerberos、LDAP（この記事の第2〜3節、認証編） |
| 5 | Windows Server | サーバーマネージャーからの役割（Role）追加、管理ツールの起動 | AD 固有の管理ツール（ADUC、GPMC、サイトとサービス） ※これらは MMC スナップインという形式の管理画面です。「管理ツールを別々のウィンドウで開く仕組み」と考えてください |
| 6 | 調査ツール |
nslookup の使い方 |
klist、gpresult、repadmin、dcdiag、w32tm
|
必須の前提と、そうでない前提
上の表を、必須度で整理します。
| # | 区分 | 内容 |
|---|---|---|
| 1 | 必須 | TCP/IP とポートの基礎、DNS の基礎（A レコード、ゾーン、リゾルバー、フォワーダー）、サーバー運用の一般知識 |
| 2 | どちらか一方でよい | Linux の実務経験、または Windows Server の実務経験。両方は不要です |
| 3 | AWS 編だけの前提 | AWS の基礎（VPC、サブネット、EC2、セキュリティグループ）。AWS 編を飛ばすなら不要です |
| 4 | 不要 | AD の経験。これから学ぶ対象です |
2 番について。 この資料は Linux 寄りの方と Windows 寄りの方が混在する前提で書いています。
-
Linux 中心で Windows の経験が少ない方 → 巻末の対応表を先に読むと入りやすくなります。
realm/ KDC /sudoers/ Ansible といった対応物から入れます - Windows は触るが Linux は分からない方 → 対応表は飛ばして構いません。本文だけで完結します
この資料が扱わないもの
この連載を通じて、以下は明示的に対象外とします。
| # | 対象外 | 触れる範囲 | 理由 |
|---|---|---|---|
| 1 | AD CS（証明書サービス） | 「LDAPS には証明書が必要」という接点のみ | CA 階層設計・テンプレート設計は独立した領域。中途半端な知識は危険側に働く |
| 2 | AD FS（フェデレーション） | 名前と用途のみ | 出番が限定的 |
| 3 | Entra ID 連携の詳細 | 「AD DS とは別物」の対比のみ（第4節） | 認証モデルが別系統 |
| 4 | Linux の AD 統合の実装 | 「標準プロトコルなので使える」という事実のみ | つまずく箇所がほぼ Linux 側にあり、学習対象がずれる |
| 5 | 既存 AD からの移行・アップグレード | 扱わない | 新規構築を学ぶ資料 |
| 6 | RODC、DFS、SIEM 連携 | 扱わない | 小規模・新規構築では出番がない |
| 7 | フォレスト全損からの復旧手順 | 「公式ガイドが存在する」ことのみ | 実行機会が稀。手順を書くと誤った自信を与える |
用語の表記について
日本語を主体とし、初出時に英語と略語を併記して以降は略語を使います（例: ドメインコントローラー（Domain Controller, DC）→ 以降「DC」）。
「Microsoft のドキュメントは日本語が充実しているのに、なぜ英語を併記するのか」と思われるかもしれません。おっしゃる通り、Microsoft Learn の多くのページには日本語版があります。理由はドキュメントの言語ではなく、実務で目にする文字列にあります。
| # | 英語・略語を併記する理由 |
|---|---|
| 1 |
コマンドの出力とエラーメッセージは英語のままです。dcdiag や repadmin の結果、イベントログの詳細に出てくる用語は、OS の表示言語にかかわらず英語のものが多くあります |
| 2 | 現場で口にするのは略語です。「ドメインコントローラー」より「DC」、「グループポリシーオブジェクト」より「GPO」。会話や設計レビューについていくには略語が必要です |
| 3 |
検索語として機能するのは英語・略語です。特にニッチな論点（USN rollback、Kerberoasting、FSMO seize など）は、日本語で検索すると情報量が大きく落ちます |
| 4 | 新しい内容は英語が先に公開される傾向があります。日本語版は遅れて追随するか、機械翻訳のまま置かれている場合があります |
| 5 | 日本語訳の用語が、GUI の日本語表記と一致しないことがあります。両方を知っておくと突き合わせができます |
GUI の画面名称は日本語版 Windows の表記を基準にし、必要に応じて英語表記を括弧で添えます。
各節の構成
各節は次の3層です。
- 要点 — 3〜6 行。この節の結論です。急いでいる場合はここだけ読んでも通じます
- 解説 — なぜそうなるか、知らないと何が起きるか
- やらかしポイント — 初学者が実際に踏む失敗と、その症状（該当する節のみ）
全部を一度に覚えようとしないでください
この資料は情報量が多めです。実務で切り分けができるところまで引き上げることを狙っているためですが、初回で全部を吸収する必要はありません。
各回の冒頭に「必ず持ち帰ること」を置いています。 まずそこだけ確実に押さえ、それ以外は「そういう論点がある」と認識したうえで、必要になったときに戻ってきてください。戻ってこられることの方が、一度で覚えることより重要です。
（参考）社内勉強会で使う場合の進め方
クリックで展開 ― この連載を社内勉強会の教材として使う場合の構成案
本文をそのまま読み上げる形は想定していません。 本文は事前配布する教科書として使い、当日は要点と実演に絞る構成を推奨します。
各回の進め方の案です。
| 順 | やること | 時間の目安 |
|---|---|---|
| 1 | 今日解けるようになるトラブルを提示する（各回のゴールの問い） | 5 分 |
| 2 | そのトラブルに必要な概念だけ説明する（要点ブロックを提示） | 40 分 |
| 3 | Mermaid 図で全体の流れを確認する | 10 分 |
| 4 | 実機、または記録済みのコマンド出力を見る | 20 分 |
| 5 | 最初のトラブルに戻り、確認順序を参加者に答えてもらう | 15 分 |
4 の実演価値が特に高いコマンドを挙げておきます。この資料は「正常な出力を知らないと異常が判別できない」という立場を取っているので、講義形式もそれに合わせるのが一貫します。
| # | コマンド | 何を見せるか | 関連する回 |
|---|---|---|---|
| 1 | nslookup -type=SRV _ldap._tcp.dc._msdcs.<ドメイン> |
DC が DNS に自動登録されている様子 | 認証編 |
| 2 | nltest /dsgetdc:<ドメイン> |
どの DC が選ばれ、どのサイトと判定されたか | 認証編・冗長化・運用編 |
| 3 | klist |
実際に保持しているチケットの一覧 | 認証編 |
| 4 | gpresult /h report.html |
適用された GPO と、拒否された GPO とその理由 | GPO 編 |
| 5 | repadmin /replsummary |
レプリケーションの正常時の出力 | 冗長化・運用編・AWS 編 |
| 6 | w32tm /monitor |
DC 間の時刻差 | 冗長化・運用編・AWS 編 |
この記事で必ず押さえること
この4点だけは、この記事を終えた時点で説明できるようにしてください。 それ以外は「そういう話があった」で構いません。
| # | 必ず持ち帰ること | 対応する節 |
|---|---|---|
| 1 | AD は「サーバーごとにアカウントを作る運用が破綻した」ことから生まれた。以後の機能はすべて、困りごとへの回答として積み重なっている | 第0節 |
| 2 | 認証（誰か）は DC が行い、認可（何をしてよいか）はアクセス先が判断する。DC が渡すのは所属情報という「材料」 | 第2節 |
| 3 | AD の土台は DNS と Kerberos。これは AD 独自の機能ではなく、独自方式を捨てて標準に乗り換えた結果 | 第0節・第3節 |
| 4 | 「AD」と呼ばれる製品は複数あり、Entra ID は別系統。AD DS 単体で解ける問題と解けない問題がある | 第4節 |
以下は発展です。今回は流し読みで構いません（認証編以降で再登場します）。
- Kerberos が NTLM に対して持つ具体的な利点（第3節）
- ディレクトリサービスと一般的なデータベースの技術的な差異（第1節）
- 用語の地図に出てくる個々の言葉の意味（第5節）
0. なぜ Active Directory は生まれたのか
要点
- AD の機能は、一度に設計されたのではなく、困りごとへの回答として順に積み重なった
- 出発点はきわめて単純: サーバーが増えるとアカウント管理が破綻する
- 解決するたびに新しい限界が現れ、それを解決するために次の機能が入った
- この順番を知ると、どの機能が土台で、どれが後付けの応用かが分かる
- この資料が扱う範囲は「土台に近いもの」に絞られている
解説
AD は最初から今の形だったわけではありません。 「困った → 解決した → 新しく困った」の繰り返しで今の姿になっています。その順番を先に見ておくと、機能の重要度が俯瞰できます。
段階 1: AD 以前 ― サーバーごとにアカウントがあった
最初の困りごとは、拍子抜けするほど単純です。
サーバーが 10 台あると、同じユーザーのアカウントを 10 個作る必要がありました。
初期の Windows サーバーは、それぞれが独立したアカウントのデータベースを持っていました。ファイルサーバー、プリントサーバー、業務サーバー——それぞれに tanaka を作ります。
結果として起きたことです。
| # | 作業 | 必要な手間 |
|---|---|---|
| 1 | 新入社員が1人入る | 10 台すべてにアカウントを作る |
| 2 | パスワードを変更する | 10 台すべてで変更する（利用者が） |
| 3 | 退職者が出る | 10 台すべてから削除する。1台でも忘れると権限が残る |
| 4 | 誰がどこにアクセスできるか調べる | 10 台を1台ずつ調べる |
| 5 | 利用者が業務でサーバーを使う | アクセスするたびに ID とパスワードを入力する |
管理者側は、ユーザー数 × サーバー数だけ管理対象が増えます。規模が大きくなるほど破綻する構造でした。
そして 5 行目は利用者側の苦痛です。ファイルサーバーを開くたび、業務システムを使うたびにパスワードを求められる。これを解消したい、というのが **SSO（シングルサインオン）**への要求です。一度認証したら、以降は入力なしで各サービスを使えるようにしたい。 AD が広く受け入れられた理由の大きな部分がここにあります。管理コストの削減だけでなく、利用者にとって体感できる改善だったからです。
段階 2: ドメインの登場 ― アカウントを1か所に集めた
そこで「アカウントのデータベースを1か所に集め、各サーバーはそこに問い合わせる」という仕組みが作られました。これがドメインの始まりです。AD 以前の、Windows NT の時代の話です。
この時代の構成はこうでした。
- PDC（Primary Domain Controller）が1台。書き込みができるのはここだけ
- BDC（Backup Domain Controller）が複数台。読み取り専用の複製
アカウントの一元管理は、これで達成されました。SSO も、この段階でドメイン単位では実現しています。 一度ドメインにログオンすれば、ドメイン内のサーバーへのアクセスで再入力を求められません。
しかし新しい限界が生まれます。
| # | 残った困りごと | 具体的に何が起きたか |
|---|---|---|
| 1 | 書き込みが1台に集中する | PDC が落ちるとパスワード変更などができない。手動で BDC を昇格させる必要があった |
| 2 | 規模の上限 | アカウントのデータベースが大きくなると性能が頭打ちになった |
| 3 | 階層構造がない | アカウントが平らに並ぶだけ。「この部門の担当者に、この範囲だけ管理させる」ができない |
| 4 | 権限が全か無か | 管理者になるか、ならないか。中間がない |
| 5 | ドメインを分けると連携が地獄 | ドメイン間の信頼関係は一方向で、かつ他へ波及しない。3つ4つと増えると、必要な信頼関係の数が急増した |
| 6 | 独自の名前解決に依存 | インターネット標準の DNS ではなく、Windows 独自の仕組みでサーバーを探していた |
3行目と4行目に注目してください。「階層構造がない」「権限が全か無か」——これが次の段階を生みます。
段階 3: Active Directory の誕生 ― 5つの発明が同時に入った
これらを解決するために作られたのが Active Directory です（Windows 2000 Server で登場）。重要なのは、5つの変更が同時に入ったことです。
この5つ（6項目）が、そのままこの資料の骨格です。
| # | AD が入れた答え | 何のためだったか | この資料での扱い |
|---|---|---|---|
| 1 | DNS と Kerberos | 独自方式をやめ、標準に乗るため。SSO をドメインの枠を越えて成立させるためでもある | 認証編の中心。すべての土台 |
| 2 | 階層構造（OU） | 組織の中を区切り、範囲を作るため | 認証編・GPO 編。土台 |
| 3 | 権限の委任 | 「全か無か」をやめるため | 権限編。重点 |
| 4 | グループポリシー（GPO） | 1台ずつ設定して回るのをやめるため | GPO 編。重点 |
| 5 | マルチマスター複製 | 書き込みの集中をやめるため | 冗長化・運用編 |
| 6 | 推移的な信頼関係 | ドメイン間連携を簡単にするため | 冗長化・運用編 |
なぜ DNS と Kerberos が認証編の中心なのかが、ここで分かります。これは AD の一機能ではなく、AD が独自方式を捨てて標準に乗り換えたという土台の変更だからです。DC を探すのも、認証するのも、この2つの上で動いています。
ここで「なぜ時刻まで」と思われたかもしれません。先に結論だけ書きます。
Kerberos は「時間制限つきの通行証」を発行する方式です。通行証には「いつ発行したか」が書き込まれていて、受け取った側は自分の時計と照らし合わせます。差が大きすぎると「昔の通行証を拾って使い回しているのではないか」と疑い、拒否します（既定の許容差は 5 分）。
つまり時計がずれると、正しい通行証まで拒否されます。「サーバーの時刻が数分ずれただけで認証が全面的に失敗する」という、AD で最も多いトラブルの正体がこれです。
仕組みは第3節で扱います。ここでは「DNS・時刻・ポートのどれかが崩れると、AD は何もかも動かなくなる」という感覚だけ持ってください。
そしてもう1つ。マルチマスターにした結果、「全部の DC で書けると困る操作」が残りました。 スキーマの変更、ドメインの追加、時刻の基準——こういった「1台が決めないと困る」役割を切り出したものが FSMO（Flexible Single Master Operation、柔軟な単一マスター操作）です（冗長化・運用編）。マルチマスター化の副産物として理解すると、FSMO が5つある理由が腑に落ちます。
なお展開形は覚えなくて構いません。 現場では全員「FSMO（エフエスエムオー）」と呼びます。ただし何の略かを知らないと、検索やドキュメントの読解で困ります。この資料では初出でこうして併記し、以降は略語を使います。
段階 4: その後の拡張 ― 3つの方向
AD の登場後、機能は主に3方向に増えました。方向を知っておくと、機能の分類ができます。
| # | 方向 | なぜ必要になったか | 代表的な機能 | この資料での扱い |
|---|---|---|---|---|
| 1 | セキュリティの強化 | 攻撃が高度化し、「管理者権限が1つ漏れると終わり」の構造が問題化した | サービスアカウントの保護（gMSA）、特権アカウントの保護 | 権限編で扱う（パスワードポリシーはGPO 編） |
| 2 | 運用性の向上 | 「消したものが戻せない」「1台ずつ手作業」への対処 | AD ごみ箱、PowerShell による管理、支店向けの読み取り専用 DC | 冗長化・運用編で一部扱う |
| 3 | 適用範囲の拡大 | 社内 LAN の外（Web、他社、証明書）へ広げる要求 | フェデレーション（AD FS）、証明書サービス（AD CS）、権限管理 | 扱わない（後述） |
「Active Directory」という名前が複数の製品に付いているのは、この3番目の方向で機能が増えたためです。AD FS も AD CS も、名前は似ていますが別のサーバー役割です。 この資料が扱うのは AD DS（Active Directory Domain Services）、つまり段階3で生まれた本体だけです（第4節で整理します）。
段階 5: クラウドという新しい圧力
そして現在です。AD DS は「社内ネットワークにある端末」を前提に設計されています。ところが実際には、社外から SaaS を使い、スマートフォンからアクセスし、社内サーバーを持たない組織が現れました。
AD DS 単体は、インターネット上の SaaS へ直接認証するための基盤ではありません。 Kerberos も LDAP も、社内ネットワークを前提としたプロトコルだからです。（VPN 越しの利用や、フェデレーション・同期の仕組みを組み合わせて AD DS を裏側の ID ソースにする構成は存在します。ここで言っているのは「単体では直接の答えにならない」ということです）
そこで別系統として作られたのが Microsoft Entra ID（旧 Azure AD）です。名前が似ていますが、認証プロトコルから設計思想まで別物です（第4節で対比します）。
同じ流れで、クラウド上で AD DS を動かす需要も生まれました。AWS における選択肢はAWS 編で扱います。
やらかしポイント
- 「Active Directory」という名前がついた製品を混同する。 AD DS、AD CS、AD FS、そして Entra ID は別物です。会話の中で「AD」と言われたら、どれを指しているか確認する価値があります。
- 古い前提のまま設計する。 「ドメインは分けた方が安全」「PDC が主で BDC が従」といった知識は、AD 以前の時代のものです。既存環境や古い資料には残っているので、注意してください。
1. ディレクトリサービスとは何か
要点
- ディレクトリサービスとは、「誰がいて、何があるか」を集めて引けるようにした仕組み
- 電話帳に近い。書き込みより読み取りが圧倒的に多いという前提で作られている
- 普通のデータベースと違う点は、階層構造、分散配置、読み取り優先の3つ
- 引くための共通の言葉が LDAP（Lightweight Directory Access Protocol）という標準プロトコル
- AD DS は「LDAP で引けるディレクトリ + 認証機能」だと考えるとよい
解説
「ディレクトリ」は directory、つまり名簿や電話帳のことです。
なぜ普通のデータベース（RDBMS）ではなく、専用の仕組みが作られたのか。用途の性質が違うからです。
| # | 観点 | ディレクトリサービス | 一般的な業務データベース |
|---|---|---|---|
| 1 | 読み書きの比率 | 読み取りが圧倒的に多い（認証のたびに引かれる） | 用途による |
| 2 | データの形 | 階層構造（組織の入れ子を素直に表せる） | 表と関連 |
| 3 | 配置 | 複数拠点に分散して置き、それぞれで読める | 集中しがち |
| 4 | 一貫性 | 多少遅れて揃えばよい（結果整合性） | 即時の一貫性が求められることが多い |
| 5 | 更新の頻度 | 低い（人事異動やパスワード変更のとき） | 高い |
「多少遅れて揃えばよい」という割り切りが重要です。社員の所属が数分遅れて他拠点に届いても、業務は成立します。 この割り切りがあるから、DC を各拠点に置いて分散させられます（冗長化・運用編で扱います）。
そして引くための共通の言葉が LDAP です。X.500 という重厚な国際標準の系譜を、TCP/IP 上で軽量に使えるようにしたものです（Lightweight の L はここから来ています）。
LDAP が標準であることの意味は、後で効いてきます。AD は Microsoft の製品ですが、引く方法は公開された標準なので、Linux からでも、他社製品からでも参照できます。
**AD DS を一言で言うなら、「LDAP で引けるディレクトリに、認証の仕組みを組み合わせたもの」**です。第2節と第3節で、この「認証」の部分を見ていきます。
2. 認証と認可 ― 何が違うのか
要点
- 認証（Authentication）＝「あなたは誰か」を確かめること
- 認可（Authorization）＝「あなたは何をしてよいか」を決めること
- この2つは別の処理であり、別の場所で行われる
- AD では、認証は DC が行い、認可の判断はアクセス先のサーバーが行う
- DC が渡すのは「認可のための材料」であって、認可の答えではない
解説
初学者が最も混同しやすく、しかも AD の設計を理解するうえで避けて通れない区別です。
建物の入館に例えます。
| 例えると | AD では | |
|---|---|---|
| 認証 | 受付で身分証を見せ、本人だと確認して入館証を受け取る | DC（＝Kerberos の KDC）が行う |
| 認可 | 各部屋の前で入館証を見せ、その部屋に入ってよいか判定される | アクセス先のサーバーが行う |
受付は「この人は田中さんで、営業部所属です」とまでは保証します。しかし「田中さんが会議室 A に入ってよいか」は判定しません。それは部屋ごとに決まっているからです。
AD もこの通りに動きます。
この分担が、実務上の重要な帰結を2つ生みます。
1つめ、DC は「誰がどのファイルを見られるか」を知りません。 権限はリソース側（フォルダ、共有、アプリ）に書かれています。「AD を見れば全部の権限が分かる」わけではありません。
2つめ、DC が渡すのは所属情報です。 つまり認可の設計とは、所属（グループ）の設計にほかなりません。権限編でグループ設計を厚く扱う理由がここにあります。
覚え方: 認証は「1回」、認可は「その都度」。 朝1回受付を通り、以降は部屋ごとに判定される。
3. Kerberos とは何か ― なぜこれが選ばれたのか
要点
- Kerberos は Microsoft の技術ではない。1980 年代に MIT で作られた認証方式
- 解決した問題は「ネットワークにパスワードを流したくない」「全サーバーにパスワードを預けたくない」
- 答えは「信頼できる第三者（KDC）が、時間制限つきの通行証を発行する」方式
- 標準として既に普及していたから、Microsoft は独自方式をやめてこれを採用した
- 従来方式（NTLM）に対する利点は、相互認証、サーバー側で完結する検証、委任の仕組み
解説
認証編では Kerberos の詳しい手順を追いますが、その前に「そもそも何者で、なぜ AD の中心にいるのか」を押さえます。
何を解決するために生まれたのか
1980 年代、MIT のキャンパスには多数の端末とサーバーがあり、ネットワークは信頼できない前提でした。誰でも通信を盗み見できる環境です。そこで2つの問題がありました。
| # | 問題 | 素朴な方法だとどうなるか |
|---|---|---|
| 1 | ネットワークにパスワードを流したくない | サーバーに毎回パスワードを送る方式だと、盗聴されれば終わり |
| 2 | 全サーバーにパスワードを預けたくない | 各サーバーがパスワードを保持すると、1台の侵害で全員のパスワードが漏れる |
Kerberos の答えは、信頼できる第三者を1つ置くことでした。この第三者を KDC（Key Distribution Center、鍵配布センター）と呼びます。
- 利用者のパスワードを、各サーバーに預ける必要がなくなる。KDC は利用者と各サービスの鍵情報を管理し、各サーバーは自分自身の鍵だけを持つ
- 利用者は KDC に本人確認を受け、**時間制限つきの通行証（チケット）**を受け取る
- 以降は、各サーバーにパスワードではなくチケットを見せる
ここは誤解しやすいので明確にします。「サーバーが鍵を1つも持たない」わけではありません。 各サービスは自分自身の鍵（AD ではコンピューターアカウントやサービスアカウントのパスワードから導出されたもの）を持ちます。KDC はその鍵でチケットを暗号化し、サービスは自分の鍵で復号します。**持たなくてよいのは「利用者のパスワード」**です。
この区別は後で重要になります。サービスアカウントの鍵が推測されると何が起きるか——権限編の Kerberoasting と Silver Ticket が、まさにこの構造の裏返しです。
名前の由来は、ギリシャ神話の番犬ケルベロスです。三つの頭を持つことから、利用者・サーバー・KDC の3者が登場する構造に掛けられています。
なぜ Microsoft はこれを採用したのか
ここが「なぜ AD の中心にいるのか」の答えです。
Windows 2000 で AD を作るにあたり、Microsoft には独自の認証方式（NTLM）が既にありました。しかし NTLM には限界がありました。
| # | NTLM の問題 | Kerberos ではどうなるか |
|---|---|---|
| 1 | サーバー側が本物かを確認できない（利用者は偽サーバーに接続しても気づけない） | 相互認証ができる。サーバーも自分の正当性を示せる |
| 2 | アクセスのたびに DC への問い合わせが必要 | チケットは原則としてサービス側が自分の鍵で検証できる。毎回 DC へ問い合わせる方式ではない |
| 3 | 別のサーバーへ資格情報を引き継げない | 委任の仕組みがある |
| 4 | Microsoft 独自方式で、他 OS と繋がらない | 公開された標準（RFC 4120）。UNIX/Linux とも相互運用できる |
| 5 | パスワードのハッシュがパスワードと等価に機能する | チケット方式のため、同じ形の攻撃が成立しにくい（GPO 編で扱います） |
そして決定的な点として、Kerberos は当時すでに認証方式の事実上の標準として普及していました。UNIX 系で広く使われ、仕様も公開されていました。
第0節の「段階3」で述べた通り、AD の設計思想は「独自方式をやめて標準に乗る」ことでした。名前解決を独自方式から DNS へ、認証を NTLM から Kerberos へ。同じ判断の2つの現れです。
したがって Kerberos は、AD の一機能ではありません。AD が標準に乗り換えたという土台そのものです。認証編でここを最も厚く扱う理由です。
「では NTLM はもう使われていないのか」——結論は「現役だが、廃止に向かっている途中」です。そして重要なのは、新規構築でも「意図せず NTLM に落ちる」ことが日常的に起きるという点です。詳しくは巻末の付録にまとめました。先を急ぐ場合は飛ばして構いません。
押さえておく3つの性質
認証編で詳しく見ますが、先に結論だけ示します。この3つが、後で数多くの現象を説明します。
| # | 性質 | 何が起きるか |
|---|---|---|
| 1 | 通行証（チケット）を貰って、それを見せて回る | 一度認証すれば、以降はサーバーごとに認証し直さない |
| 2 | チケットには時刻が書き込まれている | 時計がずれると認証が失敗する（AD 最大のトラブル要因） |
| 3 | チケットには所属グループが書き込まれている | グループに追加しても、チケットを取り直すまで反映されない |
なお Microsoft は標準の Kerberos をそのまま使っているわけではなく、所属グループの情報を運ぶための拡張を加えています。標準に乗りつつ、自社の認可モデルに必要な情報を載せた形です。
やらかしポイント
- NTLM で動いていることに気づかない。 Kerberos が使えない条件（IP アドレス直接指定など）では、Windows は自動的に NTLM に切り替えて動いてしまいます。エラーにならないため、気づかないまま古い方式を使い続けることになります。認証編で条件を扱います。
- 「Kerberos は AD の機能」だと思う。 別製品・別 OS でも使われている標準です。Linux 側の知識がそのまま通じます。
4. 「Active Directory」という名前の製品は複数ある
要点
- 「AD」と呼ばれるものは1つではない。会話に出てきたら、どれを指しているか確認する
- この資料が扱うのは AD DS（Active Directory Domain Services）だけ
- Microsoft Entra ID（旧 Azure AD）は、名前が似ているが別系統の製品
- 認証プロトコルから設計思想まで異なる。「AD のクラウド版」ではない
解説
第0節の「段階4」で述べた通り、AD の適用範囲を広げる過程で、いくつもの製品に「Active Directory」の名前が付きました。
| # | 名前 | 何をするものか | この資料での扱い |
|---|---|---|---|
| 1 | AD DS（Domain Services） | 本体。ユーザー・端末の管理と認証 | これだけを扱う |
| 2 | AD CS（Certificate Services） | 社内の証明書発行局 | 接点のみ（LDAPS に証明書が必要、という程度） |
| 3 | AD FS（Federation Services） | 社外の Web サービスとの認証連携 | 名前のみ |
| 4 | AD LDS（Lightweight Directory Services） | アプリ専用の軽量ディレクトリ | 扱わない |
| 5 | Microsoft Entra ID（旧 Azure AD） | クラウド向けの ID 基盤。別系統の製品 | 対比のみ（下記） |
Entra ID は AD のクラウド版ではない
これは特に混同されるので、構造で示します。
| # | 観点 | AD DS（この資料の対象） | Microsoft Entra ID |
|---|---|---|---|
| 1 | 認証プロトコル | Kerberos、LDAP、NTLM | OAuth 2.0、OpenID Connect、SAML |
| 2 | 管理スコープ | OU による階層構造 | OU に相当する階層構造はない。グループや管理単位（Administrative Unit）など、異なる方法で構成する |
| 3 | 端末の構成配布 | GPO | Intune（MDM）。GPO は存在しない |
| 4 | 想定する接続元 | 社内ネットワーク | インターネット |
| 5 | 連携の入口 | — | Microsoft Entra Connect による同期 |
認証プロトコルの行が決定的です。 Kerberos はチケットを扱い、OAuth / OIDC はトークンを扱います。設計思想が別系統なので、AD DS の知識がそのまま通じるわけではありません。
実際にある誤解を挙げておきます。
「Entra ID に参加させれば GPO が当たる」——当たりません。 Entra ID に GPO という仕組みは存在せず、端末の構成配布は Intune の領域です。
連携（Entra Connect による同期、ハイブリッド構成）は独立した学習領域なので、この資料では扱いません。「なぜ別物なのか」を構造で理解しておくことが、この節の目的です。
5. AD の全体像 ― 言葉の地図
要点
- この先で出てくる主要な言葉を、関係とともに1枚で見ておく
- 今すべてを理解する必要はない。戻ってくるための地図として使う
- 大きく「入れ物の階層」「中身のオブジェクト」「配る仕組み」「支える基盤」に分かれる
解説
認証編以降で出てくる言葉の関係です。この時点では、名前と位置関係だけ分かれば十分です。
図から読み取ってほしい点を3つ挙げます。
1つめ、ユーザーとコンピューターは「グループのメンバーになる」。 オブジェクトとして横並びですが、グループとの間には所属という関係があります。コンピューターもグループに入れられる点は見落とされがちです。
2つめ、GPO がリンクできるのは OU（とサイト・ドメイン）だけです。 ユーザーやコンピューターに直接ひも付けることはできません。「この端末にこの GPO を当てる」ではなく「この端末を、GPO がリンクされた OU に置く」という操作になります（GPO 編・設計編）。
3つめ、権限はリソース側に書かれます。 グループは「名指しされる側」です。この向きは設計編で詳しく扱います。
各回でどこを扱うかを対応させます。
| # | 領域 | 主に扱う回 |
|---|---|---|
| 1 | 支える基盤（DNS / Kerberos / 時刻） | 認証編 |
| 2 | 入れ物の階層（フォレスト / ドメイン / OU） | 認証編（構造）、GPO 編（活用） |
| 3 | 配る仕組み（GPO） | GPO 編 |
| 4 | 中身と権限（グループ / 委任） | 権限編 |
| 5 | レプリケーションと DC の冗長化 | 冗長化・運用編 |
| 6 | AWS 上での実装 | AWS 編 |
| 7 | 権限・OU・外部製品連携の設計判断 | 設計編 |
6. まとめ ― 重要度の地図
ここまでの内容を、実務での重要度として1枚にまとめます。この資料の構成は、この順番に従っています。
トラブルに遭ったら、下から上に戻ってください。 GPO が効かないときも、レプリケーションが止まったときも、信頼関係が張れないときも、原因の多くは一番上の土台（DNS・ポート・時刻）にあります。認証編でそこを扱う理由です。
理解度確認
問題
以下の要件を持つ相談を受けたとします。それぞれについて、AD DS が答えになるか、ならないかを判断し、理由を述べてください。 ならない場合、代わりに何を検討すべきかも示してください。
- 社内に Windows サーバーが 15 台ある。同じ社員のアカウントを全台に作っており、退職時の削除漏れが起きている。何とかしたい
- 全社の PC 300 台に、画面ロックを 15 分に統一したい
- 社員が自宅から SaaS（クラウドの業務サービス）にログインする際の認証を統一したい
- ファイルサーバーの共有フォルダごとに、部署単位でアクセス権を設定したい
- 取引先企業の担当者に、自社の Web システムを使わせたい
解答例（クリックで展開）
1. アカウントの一元管理 → AD DS が答え
まさに AD が生まれた理由そのものです（第0節・段階1〜2）。アカウントを DC に集約し、各サーバーはそこに問い合わせる形にします。退職時は1か所で無効化すれば、全サーバーに反映されます。
2. 全端末に同じ設定を配る → AD DS が答え（GPO）
AD が「段階3」で入れた答えの1つ、グループポリシーの用途です（GPO 編）。ただし判断として、端末管理を Intune などの MDM で行う選択肢も現代では並びます。社内ネットワーク前提なら GPO、社外の端末が多いなら MDM、という切り分けになります。
3. 自宅から SaaS への認証 → AD DS は答えにならない
AD DS 単体は、インターネット上の SaaS へ直接認証するための基盤ではないからです（第0節・段階5）。Kerberos も LDAP も、インターネット越しの直接利用を想定していません。
検討すべきは Microsoft Entra ID です。SaaS 連携は OAuth / OIDC / SAML といったプロトコルで行われ、これは Entra ID 側の領域です。
ただし「AD DS が無関係」という意味ではありません。既存の AD DS を ID の元とし、Entra Connect で同期する構成や、フェデレーションで連携する構成があります（この資料では扱いません）。**「AD DS 単体では答えにならないので、クラウド側の ID 基盤を検討し、必要なら既存 AD と連携する」**というのが正確な整理です。
この問いに「AD で何とかする」と答えてしまうのが、最も典型的な誤りです。
4. フォルダごとの部署単位のアクセス権 → AD DS が答え。ただし注意点あり
グループを設計し、そのグループに対してフォルダの権限を与えます（GPO 編）。
ただし第2節で扱った通り、認可の判断はファイルサーバー側が行います。AD が持つのは「誰がどのグループに属するか」だけで、「どのフォルダに何ができるか」はフォルダ側に書かれます。**「AD で権限を管理する」という言い方は、正確には「AD で所属を管理し、権限はリソース側で設定する」**です。
5. 取引先に自社システムを使わせたい → 複数の選択肢があり、AD DS 単体では答えにならない
社外の人に自社の AD DS アカウントを配るのは、管理上も安全上も現実的ではありません。
検討すべき方向は2つです。
- 相手も AD を持っているなら、信頼関係（冗長化・運用編）で連携する
- Web システムなら、フェデレーション（AD FS）や Entra ID 側の外部連携機能
いずれもこの資料の範囲外ですが、**「AD DS は社内向けであり、社外との連携は別の仕組みが要る」**という切り分けができていることが重要です。
この問題の狙い
正解を当てることではなく、「AD DS で解ける問題」と「解けない問題」の境界が見えているかを確認するものです。
3番と5番のように、AD DS の外側にある要件を見分けられることが、提案の場では特に重要になります。「Active Directory」という名前が付いた製品が複数あり、Entra ID は別系統である——第4節の内容がここで効いてきます。
付録: NTLM は今どうなっているのか（読み飛ばし可）
この付録は、第3節「Kerberos とは何か」の補足です。本編の理解には必須ではありません。 既存環境の調査や移行を担当する場合に読んでください。
「では NTLM はもう使われていないのか。歴史として覚えるだけでよいのか」——結論は「現役だが、廃止に向かっている途中」です。
そもそも身近なのか ― 「古いシステムだけの話」ではありません
先にここから答えます。新規に構築したシステムでも、NTLM は普通に出てきます。 ただし「使う」のではなく「意図せず落ちる」形で。
| # | 新規環境でも NTLM に落ちる場面 |
|---|---|
| 1 | IP アドレスでアクセスした（SPN が引けないため。認証編で扱います） |
| 2 | SPN が未登録・重複しているサービスにアクセスした |
| 3 | DNS が引けなかった |
| 4 | ローカルアカウントでの認証 |
| 5 | ドメイン参加していない機器（複合機、NAS、監視エージェント、ネットワーク装置） |
| 6 | DC に到達できない状況 |
「いつ頃のシステムが怪しいか」への答えは、年代ではなく構成です。 ドメイン参加していない機器、IP アドレス直打ちで接続する設定、SPN を登録していないカスタムサービス。これらがあれば、構築が去年でも NTLM です。
そして厄介なのは、エラーにならず動いてしまうことです。だから気づきません。
廃止に向けた動き
2026年9月時点の状況を整理します。この領域は動きが速いので、必ず最新の公式情報を確認してください。
| # | 状況 |
|---|---|
| 1 | すべてのバージョンの NTLM が「非推奨（deprecated）」 として扱われています（2024年6月に Microsoft が表明） |
| 2 | 最も古い NTLMv1 は、Windows Server 2025 / Windows 11 24H2 で削除されました |
| 3 | NTLMv2 は動作します。 後方互換のために残されており、今すぐ使えなくなるわけではありません |
| 4 | Windows は認証時に Kerberos を先に試し、駄目なときだけ NTLM に落ちる（Negotiate という仕組み） |
| 5 | Windows Server 2025 / Windows 11 24H2 では、「どこで NTLM が使われているか」を調べる監査機能が強化されました |
| 6 | Microsoft は、NTLM に落ちる原因（DC に到達できない、ローカルアカウントの認証など）を解消する新機能を投入し、将来のリリースでネットワーク NTLM を既定で無効にする方針を示しています |
実務上の含意は3つです。
- 「動いているから問題ない」では済まなくなります。 将来 NTLM が既定で無効になったとき、NTLM に依存していた処理は止まります
- したがって 「今どこで NTLM が使われているか」を把握することが、現在の運用課題になります
- NTLM に落ちる原因の多くは設定不備です。IP アドレス直接指定、SPN の未登録、DNS の問題。つまり Kerberos を正しく動かせば、NTLM 依存は自然に減ります
この資料では NTLM の移行作業そのものは扱いませんが、**「なぜ Kerberos を正しく動かすことに価値があるのか」**の答えの1つがここにあります。
付録: サンプル環境「みなと商事」（詳細）
冒頭に要約を載せています。以下は認証編以降で使う構成の詳細です。この記事の時点で覚える必要はありません。
要点
- この連載で同一の架空環境を使う。回が進むごとに構成図を拡張していく
- 公開ドメイン:
minato-corp.example - AD ドメイン:
corp.minato-corp.example/ NetBIOS 名:CORP - 組織単位（Organizational Unit, OU）は部署ではなく用途で分ける
- AWS 環境: VPC 1つ、2つのアベイラビリティゾーンに DC を1台ずつ（AWS 編で登場）
解説
章ごとに別の例を使うと、読むたびに文脈を作り直すことになります。またこの資料は後の回で「ドメイン名は後から変えられないので慎重に決めろ」と主張します。資料自身がその原則を守っていなければ説得力がありません。
認証編の時点での構成は以下です。DC は1台、まだ AWS の話は出てきません。
OU を用途で分けている点が意図的です。初学者が独力で AD を設計すると、ほぼ確実に「営業部 OU」「開発部 OU」のように組織図をそのまま写します。しかし OU の本来の役割は「グループポリシーを適用する単位」と「管理権限を委任する単位」であって、組織図の表現ではありません。組織改編のたびに OU 構造を組み替えると、リンクされたグループポリシーも権限委任も全部やり直しになります。
用途別にしておけば、組織改編は後述するグループのメンバー変更だけで吸収できます。
.example という TLD を使っているのは、RFC 2606 でドキュメント用に予約されているためです。実在ドメインと衝突しません。
付録: Linux 管理者のための AD 対応表
Linux / UNIX 系の管理経験がある方向けの読み替え表です。
| # | 分野 | Linux / UNIX | AD / Windows | 注意点 |
|---|---|---|---|---|
| 1 | ID の格納先 |
/etc/passwd、OpenLDAP |
AD DS のディレクトリ DB（NTDS.dit） |
直接編集はしない。管理ツール経由で操作する |
| 2 | ID の識別子 | UID / GID | SID（Security Identifier） | 削除・再作成で SID が変わる。UID のように使い回せない |
| 3 | 権限の付与 | sudoers |
特権グループ（Domain Admins など） | 権限編で扱う |
| 4 | 構成の配布 | Ansible / Puppet などの構成管理 | GPO（グループポリシー） | 適用は「取りに行く」プル型。既定 90 分間隔 |
| 5 | 認証の管理範囲 | MIT Kerberos の realm | AD ドメイン | 概念は同一 |
| 6 | 認証サーバー | MIT Kerberos の KDC | ドメインコントローラー（DC） | DC が KDC を兼ねる |
| 7 | チケットの確認 |
kinit / klist
|
Windows でも klist が使える |
チケット確認は同じ発想 |
| 8 | 時刻同期 |
ntpd / chronyd
|
Windows Time Service（w32time） |
同期階層が AD の構造に従う（PDC エミュレーターが頂点） |
| 9 | 名前解決 | DNS（BIND など） | AD 統合 DNS（多くの場合 DC 上で動作） | SRV レコードの動的登録が前提 |
参考リンク
- Kerberos authentication overview（Microsoft Learn）
- Windows Authentication Overview（Microsoft Learn）
- Active Directory Domain Services modules on Microsoft Learn（Microsoft Community Hub）
- Overview of Microsoft Entra Domain Services（Microsoft Learn / Entra との対比の参考）
- Advancing Windows security: Disabling NTLM by default（Windows IT Pro Blog / NTLM の段階的廃止）
続きは順次公開します。誤りや分かりにくい箇所があれば、コメントで指摘いただけると助かります。