Active Directory の概要

Active Directory™ (AD) Domain Services は、DNS 名前解決サービスを使用してドメイン・コントローラーを見つけ、ディレクトリー・サービスをホストする複数のドメイン・コントローラーが相互に通信できるようにします。 AD には論理階層包含構造があり、この最上位コンテナーはフォレストです。フォレスト内にはドメインがあり、ドメイン内には組織単位 (OU) があります。この論理モデルは、デプロイメントの物理的側面から独立しています。

Active Directory の用語

AD は以下の用語を使用します。

フォレスト - 共通の論理構造、ディレクトリー・スキーマ、ディレクトリー構成、およびグローバル・カタログを共有する 1 つ以上のドメインの集合。同じフォレスト内のドメインは、両方向の推移的な信頼関係と自動的にリンクされます。
ドメイン - ドメインはフォレスト内の区画です。データの区画化により、組織は必要な場所にのみデータを複製できます。このようにして、使用可能な帯域幅が限られているネットワーク上で、ディレクトリーをグローバルにスケーリングできます。ネットワークの領域は、1 つの認証データベースによってカバーされます。
スキーマ - ディレクトリーに含まれるオブジェクトのクラスおよび属性、これらのオブジェクトのインスタンスに対する制約と制限、およびそれらの名前のフォーマットを定義する、一連のルール。
ドメイン・コントローラー - ドメイン・コントローラーは、企業がサーバー、ワークステーション、ユーザー、およびアプリケーションを効率的に管理できるようにするサービスとデータを提供することに加えて、Active Directory Domain Services データベースの物理ストレージも提供します。 Active Directory のデータが漏洩しないように、ドメイン・コントローラーを保護してください。
ルート・ドメイン - ルート・ドメインには、Enterprise Admins グループと Schema Admins グループが含まれます。これらのサービス管理者グループは、ドメインの追加や削除、スキーマへの変更の実装など、フォレスト・レベルの操作を管理するために使用されます。
親ドメイン - 複数のドメインをリンクしてツリー構造を形成できます。階層構造では、最上位のドメインは親ドメインと呼ばれ、それにリンクする1つ以上の子ドメインを持つ。
子ドメイン - これらのドメインは、親ドメインにリンクし、親のアドレス・スペースを継承します。したがって、子はサブドメインです。あるドメインの子を他のドメインの親にすることもできます。子ドメイン名には、常に完全な親ドメイン名が含まれます。子ドメインと親ドメインは双方向の推移的信頼を共有する。
グローバル・カタログ - グローバル・カタログ・サーバーは、フォレスト内のすべての Active Directory オブジェクトの部分コピーを保管するドメイン・コントローラーです。これには、ドメインのディレクトリー内のすべてのオブジェクトの完全なコピーと、他のすべてのフォレスト・ドメインのすべてのオブジェクトの部分コピーが保管されます。ユーザーおよび管理者は、ディレクトリー内のどのドメインにデータが含まれているかに関係なく、ディレクトリー情報を検索できます。これは、そのフォレストのメンバーであるすべてのドメイン・コントローラーに複製されます。
AD サイト - AD では、サイトはドメイン・コントローラーで定義された物理エンティティーまたは論理エンティティーを表します。各サイトは、ドメインと関連付けられます。各サイトには、どの IP アドレスまたは範囲がそのサイトに属するかの IP 定義もあります。ドメイン・コントローラーは、サイト情報を使用して、AD クライアントに、そのクライアントに最も近いサイト内に存在するドメイン・コントローラーに関する情報を通知します。
サイト・リンク - サイト・リンクは、AD サイト間のリンクを確立するために使用されます。スケジュール、レプリケーション費用、間隔などのサイト・リンク・プロパティーを構成することで、サイト間のレプリケーションを管理できます。
信頼 - 信頼関係は、共有リソースに対する認証と許可を可能にするためにドメイン間に確立される論理関係です。認証プロセスで、ユーザーの ID が検査されて、許可プロセスで、ユーザーがコンピューター・システムまたはネットワーク上で実行できる内容が決定します。
ディレクトリー - AD は、ディレクトリー情報の論理的階層編成の基礎として構造化データ・ストアを使用します。このデータ・ストアはディレクトリーとも呼ばれ、AD オブジェクトに関する情報を格納します。これらのオブジェクトには通常、サーバー、ボリューム、プリンター、ネットワーク・ユーザー、コンピューター・アカウントなどの共有リソースが含まれます。
レプリケーション - ネットワーク全体にディレクトリー・データを配布するサービス。ドメイン内のすべてのドメイン・コントローラーはレプリケーションに参加し、ドメインのすべてのディレクトリー情報の完全なコピーを格納します。ディレクトリー・データに対する変更は、ドメイン内のすべてのドメイン・コントローラーに複製されます。
組織単位 - OU は、ドメイン内のコンテナーの階層を形成するために使用できます。 OU は、グループ・ポリシーの適用や権限の委任などの管理目的でオブジェクトをグループ化するために使用されます。 (OU およびその中のオブジェクトに対する) 制御は、OU および OU 内のオブジェクトに対するアクセス制御リスト (ACL) によって決まります。多数のオブジェクトの管理を容易にするために、Active Directory Domain Services では権限の委任の概念がサポートされています。委任を使用することにより、所有者は、オブジェクトに対する完全な管理制御または限定された管理制御を他のユーザーまたはグループに譲渡できます。委任が重要なのは、大量のオブジェクトの管理を、管理タスクを完了する信頼できる多くの人に分散させるのに役立つからである。
機能レベル - 機能レベルは、利用可能な Active Directory Domain Servicesドメインまたはフォレストの機能と、ドメインまたはフォレスト内のドメインコントローラー上で実行できるWindows® Serverオペレーティングシステムを決定します。ただし、機能レベルは、ドメインまたはフォレストに参加しているワークステーションおよびメンバー・サーバーで実行できるオペレーティング・システムには影響しません。

ドメイン・モデル

ドメインをオンプレミスまたは IBM Cloud® に指定するときには、お客様が使用できる次の標準的なドメイン・モデルについて確認してください。

単一フォレスト、単一ドメインのモデル
単一フォレスト、複数ドメインのモデル
多重森林モデル

フォレスト・モデルおよびドメイン・モデルについて詳しくは、論理構造の設計を参照してください。

単一フォレスト、単一ドメインのモデル

単一フォレスト、単一ドメインのモデルは、管理と保守が最も簡単です。設計は、単一のドメインを含む 1 つのフォレストで構成されます。そのドメインが唯一のドメインであるため、フォレストのルート・ドメインになり、フォレスト内のすべてのユーザー・アカウントとグループ・アカウント、およびリソース・オブジェクトが含まれます。一部の企業では、このモデルで十分です。　しかし、複雑な企業では、このモデルを使用できないことがあります。

単一フォレスト、複数ドメインのモデル

単一フォレスト、複数ドメインのモデルは、多様な地域または事業単位に分散している多数のユーザーがフォレストに含まれている大きな企業で使用されます。各ロケーションに独自のドメインがある場合は、ロケーション間のレプリケーションのトラフィックが減ります。多くの場合、複数のドメインが異なる事業単位に使用されるユース・ケースでは、管理が容易です。このドメイン・モデルは、フォレスト・ルート・ドメインと 1 つ以上のリージョン・ドメインで構成されます。多くの場合、フォレスト・ルート・ドメインは Enterprise Admins グループと Schema Admins グループのみに制限されます。これらのグループは、ドメインの追加や削除、スキーマへの変更の実装など、フォレスト・レベルの操作を管理するために使用されます。

複数のドメイン・モデル設計を作成するには、どのドメインがフォレスト・ルート・ドメインであるかを識別し、レプリケーション要件を満たすために必要な追加ドメインの数を決定する必要があります。これらのドメインは、ドメイン構造が組織構造をどのように反映する必要があるかに応じて、親ドメインまたは子ドメインにすることができます。一般的に、管理するドメインはできるだけ少ない方がいい。複雑さを軽減するために、企業は、リソースをさまざまなドメインやサブドメインに分けることによるセキュリティーの利点と複雑さのバランスを取る必要があります。

複数フォレスト・モデル

企業内の他のグループからのデータの分離またはサービスの分離を必要とするグループが企業に含まれている場合は、複数フォレスト・モデルを使用して、これらのグループ用の個別のフォレストを作成できます。ドメインは、データの分離もサービスの分離も提供しません。フォレスト・サービス管理者は、フォレスト内のすべてのリソースに対する全アクセス権限を持ちます。このアクセスは禁止できません。そのため、このグループがアクセスしてはいけないリソースがある場合は、それらのリソースを別のフォレストに配置する必要があります。

複数フォレスト・モデルは、企業がマージされた場合にも見受けられます。2 つの企業には 2 つの異なる Active Directory Domain Services 構造があります。

以下の 3 つのフォレスト・モデルを確認してください。

組織フォレスト・モデル - このモデルでは、ユーザー・アカウントとリソースは両方のフォレストに含まれますが、個別に管理されます。フォレストがフォレスト外の誰にもアクセスできないように構成されている場合、このモデルは自律性と分離を提供できます。組織フォレスト内のユーザーが他のフォレスト内のリソースにアクセスする必要がある場合、またはその逆の場合、1 つの組織フォレストと他のフォレストの間に信頼関係を確立できます。
リソース・フォレスト・モデル - このモデルでは、個別のフォレストを使用してリソースを管理します。これらのフォレストには、サービス管理者以外のユーザー・アカウントは含まれません。フォレストの信頼は、他のフォレストのユーザーがリソース・フォレストに含まれるリソースにアクセスできるように確立されます。このモデルは、サービスの分離を提供します。
アクセス制限フォレストモデル - このモデルでは、企業の他の部分から隔離する必要があるユーザーアカウントとリソースを格納するために、別のフォレストが作成されます。フォレスト間に信頼が存在しないため、あるフォレストのユーザーにはもう一方のフォレストへのアクセス権限を付与できません。このモデルは、多くの場合、インフラストラクチャー管理サービスを提供できるサービス・プロバイダーなどによって採用されます。このモデルでは、ユーザーが両方のフォレスト内のリソースにアクセスする必要がある場合、ユーザーは 1 つのフォレストにアカウントを持ち、もう一方のフォレストに別のユーザー・アカウントを持ちます。このモデルは、データの分離を提供します。アクセス制限フォレストモデルは、 VMware Cloud Foundation for Classic - Automated インスタンスのプロビジョニング時に作成されます。