目次
ドメイン/フォレスト/ツリー
目次ドメインとは
Active Directory（AD）ドメインとは、ネットワーク上のリソースを管理するための論理的な境界であり、Windowsネットワーク環境における中核的な組織単位です。
一つのドメインは、共通のセキュリティポリシー、認証システム、管理設定を持つ対象の集合体として機能します。
ドメインの核心には1台以上のドメインコントローラー( = ADサーバ)があります。
これらのサーバーはActive Directoryデータベースのコピーを保持し、ユーザー認証やポリシーの適用、ディレクトリ検索といったサービスを提供します。
ドメインの実態は、ADサーバの中にあるデータベースです。
ドメインを複数のADサーバで管理するということは、複数のドメインコントローラーは互いに定期的にデータを同期させ（レプリケーション）、冗長性と負荷分散を実現させています。
各ドメインには必ずDNS（Domain Name System）名が割り当てられます。
例えば「contoso.com」のような形式です。
この名前はインターネットドメイン名と同じ形式ですが、必ずしもインターネット上に公開されているわけではありません。
むしろ、基本的にはプライベートな管理目的のため、公開しないことの方が多いです。
このドメイン内では以下のような要素が管理されています。
これらの要素はお互いに密接に関係しながら、共通のセキュリティポリシーや認証システム、管理設定を形作っています。
また、ドメインの重要な特徴として、「信頼関係」があります。
これによりドメイン間でのリソース共有やユーザー認証が可能になります。
信頼関係には一方向と双方向があり、親子関係や外部との連携など様々な構成が可能です。
また、ドメインはActive Directoryの論理構造であると同時に、物理的なサイト構造と組み合わせることで、地理的に分散した環境での効率的なレプリケーションと認証処理を実現しています。
一つのドメインは、共通のセキュリティポリシー、認証システム、管理設定を持つ対象の集合体として機能します。
ドメインの核心には1台以上のドメインコントローラー( = ADサーバ)があります。
これらのサーバーはActive Directoryデータベースのコピーを保持し、ユーザー認証やポリシーの適用、ディレクトリ検索といったサービスを提供します。
ドメインの実態は、ADサーバの中にあるデータベースです。
ドメインを複数のADサーバで管理するということは、複数のドメインコントローラーは互いに定期的にデータを同期させ（レプリケーション）、冗長性と負荷分散を実現させています。
各ドメインには必ずDNS（Domain Name System）名が割り当てられます。
例えば「contoso.com」のような形式です。
この名前はインターネットドメイン名と同じ形式ですが、必ずしもインターネット上に公開されているわけではありません。
むしろ、基本的にはプライベートな管理目的のため、公開しないことの方が多いです。
このドメイン内では以下のような要素が管理されています。
- ユーザーアカウント（従業員の認証情報）
- コンピューターアカウント（ドメインに参加しているPC、サーバーなど）
- グループ（ユーザーやコンピューターの論理的な集合）
- 組織単位（OU：ドメイン内の管理を階層化するための構造）
- グループポリシー（セキュリティ設定やソフトウェア配布などの一元管理ルール）
- 共有リソース（フォルダ、プリンタなど）への権限設定
これらの要素はお互いに密接に関係しながら、共通のセキュリティポリシーや認証システム、管理設定を形作っています。
また、ドメインの重要な特徴として、「信頼関係」があります。
これによりドメイン間でのリソース共有やユーザー認証が可能になります。
信頼関係には一方向と双方向があり、親子関係や外部との連携など様々な構成が可能です。
また、ドメインはActive Directoryの論理構造であると同時に、物理的なサイト構造と組み合わせることで、地理的に分散した環境での効率的なレプリケーションと認証処理を実現しています。
フォレストとは
Active Directoryフォレストとは、Active Directory環境における最大の論理的な境界であり、セキュリティの独立した単位です。
フォレストは一つ以上のドメインから構成され、これらのドメイン間に完全な信頼関係を自動的に確立します。
フォレストは、組織全体のディレクトリ情報を包含する最上位の構造といえます。
フォレストの最も重要な特徴は、共通のスキーマを持つことです。
スキーマとは、Active Directoryデータベース内に格納できるオブジェクトの種類とその属性を定義するルールセットです。
オブジェクトを作成するときに記入する情報のフォーマットと言ってもいいかもしれません。
フォレスト内のすべてのドメインは同一のスキーマを共有するため、オブジェクトの定義に一貫性があります。
もしこのスキーマがないと、みんなが好き勝手な情報でユーザーを作り始めてしまいます。
これでは、情報を検索するときに「こっちの人は姓がsn(姓)に記入されているのに、別の人はlastName(姓)に入っている・・・！」みたいになって大変ですよね。
なので、フォレスト全体でオブジェクトに記入すべき情報を定義して、全員に遵守してもらうことで一貫性を保てるということです。
このようなスキーマの変更は、フォレスト全体に影響がでます。
スキーマに関連して、フォレストには「グローバルカタログ」という特別なデータベースが存在します。
これはフォレスト内のすべてのドメインから頻繁に使用される属性情報を集約したもので、クロスドメイン検索やユーザー認証プロセスを効率化します。
例えば、ユーザー情報の中でも「userName(名前)」と「employeeNumber(社員番号)」が、この企業では色々な認証情報などで使われていて検索頻度が高いとします。
この時に、フォレストの中には複数のドメインが混在する場合、そのドメインを管轄するADサーバまで問い合わせにいき確認する必要があるので時間がかかってしまいます。
それを解消するために、「グローバルカタログ」というものによく使うものは全ドメインから情報を常に収集しておくということをしているものになります。
最初に作成されるドメインはフォレストルートドメインと呼ばれ、フォレスト全体の管理において特別な役割を持ちます。
Enterprise Admins（企業の管理者）やSchema Admins（スキーマ管理者）といった、フォレスト全体に影響を与える権限を持つグループはここに存在します。
セキュリティの観点からは、フォレストは「セキュリティ境界」と見なされます。
フォレスト内ではドメイン間に暗黙の信頼があるため、異なるセキュリティ要件や管理者権限の独立性が必要な場合は、複数のフォレストを設計する場合があります。
フォレストは一つ以上のドメインから構成され、これらのドメイン間に完全な信頼関係を自動的に確立します。
フォレストは、組織全体のディレクトリ情報を包含する最上位の構造といえます。
フォレストの最も重要な特徴は、共通のスキーマを持つことです。
スキーマとは、Active Directoryデータベース内に格納できるオブジェクトの種類とその属性を定義するルールセットです。
オブジェクトを作成するときに記入する情報のフォーマットと言ってもいいかもしれません。
フォレスト内のすべてのドメインは同一のスキーマを共有するため、オブジェクトの定義に一貫性があります。
もしこのスキーマがないと、みんなが好き勝手な情報でユーザーを作り始めてしまいます。
これでは、情報を検索するときに「こっちの人は姓がsn(姓)に記入されているのに、別の人はlastName(姓)に入っている・・・！」みたいになって大変ですよね。
なので、フォレスト全体でオブジェクトに記入すべき情報を定義して、全員に遵守してもらうことで一貫性を保てるということです。
このようなスキーマの変更は、フォレスト全体に影響がでます。
スキーマに関連して、フォレストには「グローバルカタログ」という特別なデータベースが存在します。
これはフォレスト内のすべてのドメインから頻繁に使用される属性情報を集約したもので、クロスドメイン検索やユーザー認証プロセスを効率化します。
例えば、ユーザー情報の中でも「userName(名前)」と「employeeNumber(社員番号)」が、この企業では色々な認証情報などで使われていて検索頻度が高いとします。
この時に、フォレストの中には複数のドメインが混在する場合、そのドメインを管轄するADサーバまで問い合わせにいき確認する必要があるので時間がかかってしまいます。
それを解消するために、「グローバルカタログ」というものによく使うものは全ドメインから情報を常に収集しておくということをしているものになります。
最初に作成されるドメインはフォレストルートドメインと呼ばれ、フォレスト全体の管理において特別な役割を持ちます。
Enterprise Admins（企業の管理者）やSchema Admins（スキーマ管理者）といった、フォレスト全体に影響を与える権限を持つグループはここに存在します。
セキュリティの観点からは、フォレストは「セキュリティ境界」と見なされます。
フォレスト内ではドメイン間に暗黙の信頼があるため、異なるセキュリティ要件や管理者権限の独立性が必要な場合は、複数のフォレストを設計する場合があります。
ツリーとは
Active Directoryツリーとは、ドメイン名空間が連続する複数のドメインが階層的に結合された構造を指します。
具体的には、親子関係を持つドメインの集合体であり、DNSの名前空間を共有しています。
ツリーはフォレスト内の構造であり、一つのフォレストには一つ以上のツリーが存在する可能性があります。
ツリー構造の特徴として、親ドメインと子ドメインの間には連続した命名規則があります。
例えば、親ドメインが「contoso.com」であれば、その子ドメインは「sales.contoso.com」や「hr.contoso.com」のように、親ドメイン名を継承した形になります。
この名前の連続性により、DNS階層との整合性が保たれ、ネームレゾリューション（名前解決）が効率的に行われます。
親ドメインと子ドメインの間には、自動的に双方向の推移的信頼関係が確立されます。
推移的信頼とは、A→BとB→Cの信頼関係がある場合、A→Cの信頼も暗黙的に成立するという性質です。
これにより、ツリー内のすべてのドメイン間でシームレスな認証とリソースアクセスが可能になります。
ツリー構造の主な目的は、組織の階層や地理的構造を反映した論理的な管理単位を作ることです。
例えば、地域ごとに異なる管理ポリシーが必要な多国籍企業では、「europe.company.com」「asia.company.com」などのように地域別の子ドメインを設定することで、地域特有の要件に対応しつつ、全体的な一貫性も維持できます。
ドメインツリーの深さ（階層レベル）に技術的な制限はありませんが、管理の複雑さやパフォーマンスの観点から、通常は2〜3レベル程度に抑えられることが一般的です。
深すぎるツリー構造は、認証プロセスやレプリケーションの効率を低下させる可能性があります。
大規模な組織では、異なる命名規則や管理ポリシーが必要な場合、単一のフォレスト内に複数のツリーを作成することができます。
例えば、買収により「fabrikam.com」というドメインを持つ会社が「contoso.com」のフォレストに統合される場合、それぞれがツリーのルートとなる形で共存させることが可能です。
ただし、名前空間の連続性はなくなります。
ツリー構造は、組織の成長や変化に応じて柔軟に拡張できる点が大きな利点です。
新しい部門や子会社が増えた場合、既存のツリーに子ドメインを追加するだけで、セキュリティと管理の整合性を維持しながら対応できます。
具体的には、親子関係を持つドメインの集合体であり、DNSの名前空間を共有しています。
ツリーはフォレスト内の構造であり、一つのフォレストには一つ以上のツリーが存在する可能性があります。
ツリー構造の特徴として、親ドメインと子ドメインの間には連続した命名規則があります。
例えば、親ドメインが「contoso.com」であれば、その子ドメインは「sales.contoso.com」や「hr.contoso.com」のように、親ドメイン名を継承した形になります。
この名前の連続性により、DNS階層との整合性が保たれ、ネームレゾリューション（名前解決）が効率的に行われます。
親ドメインと子ドメインの間には、自動的に双方向の推移的信頼関係が確立されます。
推移的信頼とは、A→BとB→Cの信頼関係がある場合、A→Cの信頼も暗黙的に成立するという性質です。
これにより、ツリー内のすべてのドメイン間でシームレスな認証とリソースアクセスが可能になります。
ツリー構造の主な目的は、組織の階層や地理的構造を反映した論理的な管理単位を作ることです。
例えば、地域ごとに異なる管理ポリシーが必要な多国籍企業では、「europe.company.com」「asia.company.com」などのように地域別の子ドメインを設定することで、地域特有の要件に対応しつつ、全体的な一貫性も維持できます。
ドメインツリーの深さ（階層レベル）に技術的な制限はありませんが、管理の複雑さやパフォーマンスの観点から、通常は2〜3レベル程度に抑えられることが一般的です。
深すぎるツリー構造は、認証プロセスやレプリケーションの効率を低下させる可能性があります。
大規模な組織では、異なる命名規則や管理ポリシーが必要な場合、単一のフォレスト内に複数のツリーを作成することができます。
例えば、買収により「fabrikam.com」というドメインを持つ会社が「contoso.com」のフォレストに統合される場合、それぞれがツリーのルートとなる形で共存させることが可能です。
ただし、名前空間の連続性はなくなります。
ツリー構造は、組織の成長や変化に応じて柔軟に拡張できる点が大きな利点です。
新しい部門や子会社が増えた場合、既存のツリーに子ドメインを追加するだけで、セキュリティと管理の整合性を維持しながら対応できます。
ドメイン/フォレスト/ツリーの関係性と違い
Active Directoryの階層構造において、ドメイン、フォレスト、ツリーはそれぞれ異なる役割と範囲を持ち、相互に関連しながらWindowsネットワーク環境の基盤を形成しています。
まず基本的な関係性として、フォレストは最上位の境界であり、その中に一つまたは複数のツリーが含まれ、各ツリーは一つまたは複数のドメインから構成されています。
言い換えれば、ドメインは最小の管理単位であり、連続した名前空間を持つドメインの集合がツリー、そして一つまたは複数のツリーの集合体がフォレストとなります。
セキュリティの観点では、フォレストがセキュリティの最も厳格な境界として機能します。
フォレスト間では明示的に信頼関係を設定しない限り、認証やリソース共有は行われません。
一方、同一フォレスト内のドメイン間では自動的に推移的信頼関係が確立され、特にツリー内のドメイン間では親子関係に基づく双方向の信頼が形成されます。
つまり、フォレスト内で共存している全てのドメイン(サブドメイン含む)において相互の信頼関係が暗黙的に確立されることになります。
管理範囲の違いも重要です。
ドメインレベルでは、ユーザーアカウント、コンピューターアカウント、グループなどの日常的な管理対象が含まれ、ドメイン管理者がこれらを制御します。
ツリーレベルでは連続したDNS名前空間の管理が主な焦点となります。
フォレストレベルでは、スキーマやグローバルカタログといった全体に影響を与える要素が対象となり、フォレスト管理者（Enterprise Admins）が管理権限を持ちます。
名前空間の観点では、ツリー内のドメインは連続した階層的なDNS名を共有します（例：parent.com、child.parent.com）。
しかし、同一フォレスト内の別々のツリーは、不連続な名前空間を持ちます（例：contoso.comとfabrikam.com）。
フォレストは異なる名前空間を束ねる役割を果たしています。
データ共有の点では、フォレスト内ではスキーマとグローバルカタログが共有されます。
これにより、フォレスト全体で一貫したオブジェクト定義と検索機能が提供されます。
ツリー内のドメイン間では、親子関係による管理上の一貫性があります。
ドメインはそれぞれ独自のディレクトリパーティションを持ち、基本的なレプリケーションの単位となります。
実際の運用においては、組織の規模や複雑さに応じて適切な構造が選ばれます。
小規模組織では単一ドメインのシンプルな構造が一般的ですが、多国籍企業や複雑な組織構造を持つ大企業では、複数のドメイン、ツリー、場合によっては複数のフォレストを組み合わせた設計が採用されます。
この階層構造の適切な設計が、セキュリティ、管理効率、パフォーマンスの鍵となります。
まず基本的な関係性として、フォレストは最上位の境界であり、その中に一つまたは複数のツリーが含まれ、各ツリーは一つまたは複数のドメインから構成されています。
言い換えれば、ドメインは最小の管理単位であり、連続した名前空間を持つドメインの集合がツリー、そして一つまたは複数のツリーの集合体がフォレストとなります。
セキュリティの観点では、フォレストがセキュリティの最も厳格な境界として機能します。
フォレスト間では明示的に信頼関係を設定しない限り、認証やリソース共有は行われません。
一方、同一フォレスト内のドメイン間では自動的に推移的信頼関係が確立され、特にツリー内のドメイン間では親子関係に基づく双方向の信頼が形成されます。
つまり、フォレスト内で共存している全てのドメイン(サブドメイン含む)において相互の信頼関係が暗黙的に確立されることになります。
管理範囲の違いも重要です。
ドメインレベルでは、ユーザーアカウント、コンピューターアカウント、グループなどの日常的な管理対象が含まれ、ドメイン管理者がこれらを制御します。
ツリーレベルでは連続したDNS名前空間の管理が主な焦点となります。
フォレストレベルでは、スキーマやグローバルカタログといった全体に影響を与える要素が対象となり、フォレスト管理者（Enterprise Admins）が管理権限を持ちます。
名前空間の観点では、ツリー内のドメインは連続した階層的なDNS名を共有します（例：parent.com、child.parent.com）。
しかし、同一フォレスト内の別々のツリーは、不連続な名前空間を持ちます（例：contoso.comとfabrikam.com）。
フォレストは異なる名前空間を束ねる役割を果たしています。
データ共有の点では、フォレスト内ではスキーマとグローバルカタログが共有されます。
これにより、フォレスト全体で一貫したオブジェクト定義と検索機能が提供されます。
ツリー内のドメイン間では、親子関係による管理上の一貫性があります。
ドメインはそれぞれ独自のディレクトリパーティションを持ち、基本的なレプリケーションの単位となります。
実際の運用においては、組織の規模や複雑さに応じて適切な構造が選ばれます。
小規模組織では単一ドメインのシンプルな構造が一般的ですが、多国籍企業や複雑な組織構造を持つ大企業では、複数のドメイン、ツリー、場合によっては複数のフォレストを組み合わせた設計が採用されます。
この階層構造の適切な設計が、セキュリティ、管理効率、パフォーマンスの鍵となります。
まとめ
ADにおける最も基本的な設計項目であるドメインとフォレスト、ツリーについて解説しました。
初規模な環境であれば、1フォレスト1ドメインの単純構造で構成することも可能ですが、大規模な企業になるとそのような構成ではセキュリティが担保できません。
ADの設計に置いては、今後の企業の成長性も考慮して柔軟に管理が可能な構成が望ましいです。
今一度、違いや役割を理解して置きましょう。
今回の解説内容を表で整理しておきますので、是非参照してください。
初規模な環境であれば、1フォレスト1ドメインの単純構造で構成することも可能ですが、大規模な企業になるとそのような構成ではセキュリティが担保できません。
ADの設計に置いては、今後の企業の成長性も考慮して柔軟に管理が可能な構成が望ましいです。
今一度、違いや役割を理解して置きましょう。
今回の解説内容を表で整理しておきますので、是非参照してください。
| 項目 | ドメイン | ツリー | フォレスト |
|---|---|---|---|
| 定義 | 共通のセキュリティポリシーと管理設定を持つリソースの基本的な境界 | 連続した名前空間を共有する階層的なドメインの集合体 | 共通のスキーマとグローバルカタログを共有する1つ以上のツリーの集合体 |
| 階層関係 | 最小の管理単位 | 1つ以上のドメインから構成 | 1つ以上のツリーから構成 |
| 名前空間 | 一意のDNS名（例：sales.contoso.com） | 連続したDNS名前空間（例：contoso.com、hr.contoso.com） | 不連続な名前空間を含む場合がある（例：contoso.comとfabrikam.com） |
| 信頼関係 | ドメイン内のリソース間で共通認証 | 親子ドメイン間の自動的な双方向の推移的信頼 | フォレスト内の全ドメイン間の推移的信頼 |
| 管理範囲 | ユーザー、グループ、コンピューター、OUの管理 | 連続する名前空間の管理 | スキーマ、構成、グローバルカタログの管理 |
| 管理者 | ドメイン管理者（Domain Admins） | 各ドメインのドメイン管理者の集合 | フォレスト管理者（Enterprise Admins）とスキーマ管理者（Schema Admins） |
| セキュリティ境界 | 限定的なセキュリティ境界 | ドメイン間の信頼があるため完全な境界ではない | 最も強固なセキュリティ境界 |
| 共有要素 | ドメイン内のディレクトリパーティション | 連続したDNS名前空間 | スキーマ、構成、グローバルカタログ |
| 使用シナリオ | 単一の管理単位が必要な場合 | 階層的な管理構造を反映する場合 | 異なる名前空間や大規模な組織分割が必要な場合 |