はじめに
Windows Server を扱う上で、避けては通れない機能が Active Directory（AD）です。 企業の社内ネットワークにおいて、ユーザーの ID やパスワード、パソコンのアクセス権限などを一元管理する、「Windows 環境の司令塔」 とも言える重要な機能です。
Active Directory は、実は単一の機能ではなく、5つのサービス から構成されています。 しかし、現場で単に「Active Directory」と言った場合、その 9 割以上は中心的な機能である Active Directory ドメインサービス（AD DS）を指しています。
本記事では、AD を構成する 5 つのサービスの概要と、その主役である AD DS の仕組み（LDAP・認証・DNS） について解説します。
- 全体像: Active Directory を構成する 5 つのサービスの違い
- 仕組み: AD DS の 3 大機能（LDAP、Kerberos、DNS）
- 構成: ドメイン、フォレスト、信頼関係の基礎知識
Active Directory を構成する「5つのサービス」
Active Directory は、役割の異なる以下の 5 つのサービス群から構成されています。
- ① Active Directory ドメインサービス（AD DS）
-
【主役】 最も代表的なサービスであり、一般的に「AD」と言えばこれを指します。 ネットワークを「ドメイン」という単位で区切り、その中のユーザー、コンピューター、プリンターなどの資源を一元管理します。 管理サーバーである ドメインコントローラー (DC) によって、ログイン認証やグループポリシーによる設定配布を行います。
本記事ではこの「AD DS」に焦点をあてて解説します。
- ② Active Directory ライトウェイトディレクトリサービス（AD LDS）
-
【軽量版】 AD DS の簡易バージョンです。 AD DS のように OS のログオン認証やポリシー管理は行わず、純粋にアプリケーションが利用するための「LDAP データベース（住所録）」機能のみを提供します。
- ③ Active Directory 証明書サービス（AD CS）
-
【証明書の発行】 社内用の認証局（CA）を構築するサービスです。 AD DS と連携して、Web サーバー用の「サーバー証明書」や、ユーザーや端末の身元を保証する「クライアント証明書」を発行・配布・管理します。
- ④ Active Directory Rights Management Services（AD RMS）
-
【情報の保護】 ファイルやメールそのものを暗号化し、権限を制御するサービスです。 「閲覧はできるが印刷は不可」「転送禁止」といった細かい制御が可能で、万が一ファイルが流出しても、認証されたユーザー以外は中身を見ることができません。
- ⑤ Active Directory フェデレーションサービス（AD FS）
-
【SSO 連携】 異なるシステム間での シングルサインオン (SSO) を実現する認証サービスです。 社内の AD 認証情報を使って、社外のクラウドサービス（Office 365 など）や、別会社の Web アプリケーションへログインできるようにします。
AD DS の仕組み（機能とプロトコル）
AD DS が正常に動作するために欠かせない、3 つの主要な機能・プロトコルについて解説します。
LDAP（情報の保管庫）
LDAP（Lightweight Directory Access Protocol）は、AD のデータベースにアクセスするための標準的なプロトコルです。 AD 内のユーザーやコンピューターの情報は、ファイルシステムのような 「階層構造（ツリー構造）」 で管理されています。この構造全体を DIT（Directory Information Tree）と呼びます。
例えば、example.com というドメインの中に、SE 部門、NETWORK チームがあり、そこに user01 が所属している場合、住所（DN: Distinguished Name）は以下のように表現されます。
User01 の DN（識別名） CN=user01,OU=NETWORK,OU=SE,DC=example,DC=com
example.com ドメインの DIT認証（Kerberos / ケルベロス）
AD ドメイン環境での標準的な認証方式には、Kerberos (ケルベロス) 認証 が採用されています。 これは、パスワードそのものをネットワークに流すのではなく、「チケット（通行手形）」 を使って安全に認証を行う仕組みです。
ユーザーは ID/PW を入力し、ドメインコントローラー（DC）から TGT（Ticket Granting Ticket）という「身分証明書」をもらいます。
ファイルサーバーなどにアクセスする際、DC に TGT を見せて、そのサーバー専用の ST（Service Ticket）という「利用券」を発行してもらいます。
サーバーに ST を渡すことで、アクセスが許可されます。
DNS（名前解決と場所の特定）
「AD と DNS は一心同体」 と言われるほど、DNS は重要な役割を持っています。AD の DNS には大きく 2 つの役割があります。
- 名前解決
-
ドメインに参加しているコンピューターの IP アドレスとホスト名を自動的に登録・管理します。
- DC の場所特定（重要）
-
クライアント PC がログオンする際、「ドメインコントローラーはどこにいるか？」を探すために DNS を使います。この時使われるのが SRV レコード（サービス リソース レコード）です。
もし「ログオンが遅い」「AD に繋がらない」というトラブルが起きた場合、DNS の SRV レコードが正しく登録されているかを確認するのが鉄則です。
▼ SRV レコードの確認例（コマンドプロンプト）
C:\Users\Administrator> nslookup
> set type=srv
> _ldap._tcp.dc._msdcs.example2.com
サーバー: localhost
Address: 127.0.0.1
権限のない回答:
_ldap._tcp.dc._msdcs.example2.com SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = ad03.example2.com
ad03.example2.com internet address = 192.168.1.133AD DS の適用範囲（論理構造）
Active Directory は、管理のしやすさやセキュリティ要件に応じて、以下の 4 つの階層構造で管理されます。
ドメイン（Domain）
Active Directory の 「基本単位」 です。 ドメインに参加したユーザーやコンピューターは、そのドメイン内のリソース（ファイルサーバーやプリンターなど）に対して、認証を経てアクセスできるようになります。
管理者（Domain Admins）はドメイン全体に対して強力な権限を持ちます。
OU（組織単位 / Organizational Unit）
ドメインの中をさらに細かく区切るための 「フォルダ」 のような管理単位です。 例えば、「営業部」「総務部」といった部署ごとに OU を作成し、そこにユーザーや PC を格納します。
この仕組みの一番のメリットは、OU ごとに異なる グループポリシー（GPO）を適用できる点です。（例：営業部 OU は USB メモリ使用禁止、など）
ドメインツリー（Domain Tree）
1 つのドメインの下に、名前空間を共有する別のドメイン（子ドメイン）を追加した構成です。 これを 「親子関係」 と呼びます。
- 親ドメイン:
example.com - 子ドメイン:
a.example.com（親の名前を引き継ぐ）
親子関係にあるドメイン同士は、自動的に 「双方向の信頼関係」 が結ばれ、お互いのリソースにアクセスが可能になります。
example.com に子ドメイン a.example.com を作成フォレスト（Forest）
Active Directory における 「最大の管理単位」 です。その名の通り、1 つ以上の「ドメインツリー（木）」が集まって「フォレスト（森）」を形成します。
フォレスト内のドメイン同士は、名前空間（例：example.com と test.local）が違っても、互いに信頼関係を結んで連携することができます。
- シングル・フォレスト: すべてのドメインを 1 つのフォレスト内で管理する構成。管理が楽で一般的です。
- マルチ・フォレスト: セキュリティ境界を完全に分けたい場合などに、複数のフォレストに分ける構成
信頼関係（Trust）とは
異なるドメイン間で、ユーザーがリソース（ファイルサーバーなど）を利用できるようにするための契約を 「信頼関係」 と呼びます。 信頼関係には、大きく分けて 「方向」 と 「推移性」 という 2 つの重要な概念があります。
方向（片方向・双方向）
「どちらのドメインのユーザーが、どちらのドメインにアクセスできるか」を定義します。
- 双方向の信頼
-
- お互いのドメインのユーザーが、お互いのリソースにアクセス可能です。
- フォレスト内のドメイン間（親子など） は、既定でこの「双方向」が結ばれます。
- 片方向の信頼
-
- 一方通行のアクセスです。例えば「A ドメインが B ドメインを信頼する」という設定をした場合、「B ドメインのユーザーが、A ドメインにアクセスできる」 ようになります。
- ※「信頼した側（A）」は扉を開け、「信頼された側（B）」が入ってくるイメージです。
推移性（推移性あり・なし）
信頼関係が、その先のドメインにも「波及するかどうか」の性質です。
- 推移性あり（Friend of a Friend）
-
- 「親」と「子」が信頼し、「子」と「孫」が信頼している場合、「親」と「孫」も自動的に信頼関係になります。
- これを「友達の友達は、みな友達」のルールと覚えると分かりやすいです。
- フォレスト内のドメインツリー間は、基本的にこの「推移性」を持ちます。
- 非推移性
-
- 信頼関係はその 2 つのドメイン間だけで有効で、その先には波及しません。
- 外部の別フォレストと手動で信頼を結ぶ場合などは、セキュリティのため非推移性にすることが多いです。
a.example.com が信頼する・されるドメインの一覧【コラム】Azure AD（Entra ID）との違い
最近よく聞く「Azure AD（現在は Microsoft Entra ID に名称変更）」と、今回解説した「Active Directory（AD DS）」は、名前は似ていますが 「全くの別物」 です。
「Azure AD って、単にクラウド上に作った AD サーバーのことじゃないの？」
実はこれ、一番多い勘違いなんです。
プロトコルが違う
オンプレミスの AD DS は 「Kerberos」 や 「LDAP」 を使って、社内のサーバーや PC をガチガチに管理するのが得意です。 一方、Entra ID は 「https（Web の通信）」 ベースのプロトコル（OIDC, SAML など）を使い、インターネット上のクラウドサービス（Microsoft 365, Box, Salesforceなど）への認証を行うのが得意です。
| 機能 | オンプレミス AD（AD DS） | クラウド ID（Entra ID） |
|---|---|---|
| 得意な場所 | 社内ネットワーク（LAN） | インターネット（Cloud） |
| 通信方式 | Kerberos / LDAP | HTTP / HTTPS（REST API） |
| 管理対象 | デバイス（GPO）, サーバー | ユーザー ID, アプリへのアクセス |
| グループポリシー | 使える（得意） | 使えない（Intune 等で代用） |
「ハイブリッド」が今の主流
現在は、社内の PC 管理は AD DS で行い、Microsoft 365 などの利用には Entra ID を使う 「ハイブリッド構成（AD Connect で同期）」 が一般的です。 「どちらかを選ぶ」のではなく、「適材適所で両方使う」のが現代の ID 管理の正解と言えます。
まとめ
本記事では、Active Directory の全体像と、中心となる AD DS の仕組みについて解説しました。
- 5つのサービス: 主役は「AD DS」その他は証明書や SSO などの専門家
- 3大要素: データベースの 「LDAP」、認証の 「Kerberos」、場所特定の 「DNS」
- 構造: ドメイン ＜ ツリー ＜ フォレスト という包含関係
- 信頼関係: 方向と推移性によって、アクセス可否が決まる。
AD は非常に奥が深いシステムですが、トラブルシューティングの際は「DNS（SRV レコード）は正しいか？」「信頼関係の方向は合っているか？」といった基礎を確認することが解決への近道です。
以上、最後までお読みいただきありがとうございました。
