Active Directory: ニーズに合わせて Active Directory をセットアップする
Active Directory のトポロジを組織のニーズに合わせてセットアップすれば、ユーザーとリソースを適切に整理することができます。
Brien M. Posey
10 年以上前に Windows 2000 Server Edition のリリースに伴って Active Directory が誕生して以来、実績あるマイクロソフトのディレクトリ サービスである Active Directory は、組織が混乱の中で秩序を保つ手助けを行ってきました。もちろん例外もありますが、ほとんどの組織では、現実的にやり過ごせる最も単純な Active Directory の展開に固執しています。
これは驚くことではありません。物事をできる限り単純に保つという原則は、IT の世界では当然のことです。熟練した IT 担当者であれば、物事を単純に保つことによって、問題が発生する可能性が低くなり、トラブルシューティングが非常に簡単になることを知っています。標準の Active Directory トポロジを使用することに、まったく問題はありません。マイクロソフトが標準のトポロジを既定値に設定しているのには、理由があるというわけです。
単純さにメリットがあるのも確かですが、Active Directory に関しては、カスタマイズ構造を採用した方が良い組織もあります。管理作業を分離する必要がある大規模な組織には、よりふさわしい設計が他に存在しています。
ドメイン構造
ほとんどの場合、実際の Active Directory の展開では、組織の地理的な構造を模倣するドメイン構造を使用します。たとえば、組織のオフィスが 3 か所ある場合、ドメインはおそらく 3 つになります。必ずしもすべての組織がこのような構造を使用しているわけではありませんが、これが最も一般的な Active Directory の構造です。以下に、お勤めの組織で検討できる他のドメイン構造の選択肢をいくつか紹介します。
ユーザー ドメイン
Active Directory は、単なるデータベースに過ぎません。このデータベースには、さまざまな種類のオブジェクトが格納されており、各オブジェクトには、1 つ以上の属性が割り当てられています。組織は、特定の種類の Active Directory オブジェクトを、ドメイン構造の基盤にすることがありますが、ユーザー ドメインの使用が、その一例です。
ユーザー ドメインは、ユーザー アカウントの管理のみを目的にセットアップされている Active Directory ドメインです。ユーザー ドメインが便利な理由を説明するために、数千人のユーザーを抱え、従業員の離職率の高い組織について考えてみましょう。この組織には、ユーザー アカウントを作成、プロビジョニング、および削除する役割を担っている従業員が 2 人います。
ユーザー ドメイン構造では、アカウントの保守を行う従業員が完全な管理者レベルの制御をユーザー アカウントに対して持っているので、上記のような状況では便利です。ただし、別の Active Directory オブジェクトや機能にはアクセスできないという制限が生じることがあります。
管理の役割を分離するという目的だけで、ユーザー ドメイン構造を実装する必要はありません。管理を分離する方法は他にもあります。それでも、ユーザー ドメイン構造を使用すると、個々のドメインを整理することで、組織をより整然とした状態に保つのに役立ちます。また、管理を物理的に分離しているような感覚を手に入れることができます。多種多様なオブジェクトの種類が共通のドメインに存在している場合、論理的に管理を分離することがありますが、論理的ではなく物理的な分離を好む組織もあります。
リソース ドメイン
リソース ドメインは、本来は目的が 1 つであるという点で、ユーザー ドメインに似ています。セキュリティを強化するため、または Active Directory 構造をより論理的にしたり、管理しやすくしたりする目的に使用されます。実際の Active Directory の展開では、すべてのデスクトップ コンピューターが、専用のリソース ドメインにグループ化される場合があります。主要な基幹業務アプリケーションを実行しているすべてのサーバーを、専用のリソース ドメインに配置する展開もあります。また、他の種類のリソースにリソース ドメインを使用することもできます。
リソース ドメインが最も便利なのは、管理ドメインとして使用する場合です。たとえば、Hyper-V サーバーには、純粋に Hyper-V サーバーの管理ドメインとして機能するように設計されている専用の Active Directory フォレストを作成することをお勧めします。これにはいくつかの理由があります。
1 つは、管理に関する理由です。System Center Operations Manager 2012 (と、その他多くの管理製品) では、Active Directory ドメインのメンバー サーバーしか管理できません。プライマリ ドメインのドメイン コントローラーがすべて仮想化されている場合、プライマリ ドメインに Hyper-V サーバーを参加させたいとは思わないでしょう。仮想化された DC がオフラインであるために Hyper-V サーバーにログオンできないという状況に組織が陥ることは望ましくありません。専用の Active Directory 管理フォレストに Hyper-V サーバーを追加すると、この問題をうまく解決できます。
Hyper-V サーバー専用のリソース ドメインを作成した方が良いもう 1 つの理由は、Hyper-V バージョン 3.0 に搭載される新機能のいくつかに関連しています。Hyper-V 3.0 には、ホスト サーバー間で仮想マシン (VM) をレプリケートする機能があります。このレプリケーションは、フェールオーバー クラスタリング ソリューションではなく、VM の最新のコピーを別のホスト サーバーに保持できる障害回復ソリューションです。このソリューションを使用すれば、ディスク アレイや主要な Hyper-V ホストで障害が発生した場合に使用できる VM の別のコピーを保持できます。
ただし、この機能を使用するためには、ホスト サーバーとレプリカ サーバーの両方が認証される必要があります。この認証を行う最も簡単な方法は、両方のサーバーを共通のドメインに参加させて、Kerberos を使用することです。そのため、Hyper-V サーバー専用のリソース ドメインを作成することは完全に理にかなっています。これは、ドメイン メンバーシップが必要な他の Hyper-V 機能があることを考えると、その傾向は強くなります。
ちなみに、リソース ドメインとユーザー ドメインは、相互に排他的ではありません。共通の Active Directory フォレストで、ユーザー ドメインとリソース ドメインを組み合わせて使っている組織もあります。
地理的なトポロジ
ユーザー ドメインとリソース ドメインの構造は確かに効果的ですが、実際の Active Directory の展開は、ほとんどが地理的な構造に基づいています。技術的には、この種類の Active Directory トポロジを使用することに問題はありませんが、いくつかの考慮事項があります。
まず、ドメイン構造をサイト構造と混同しないようにしてください。Active Directory サイト構造は、組織の地理的なトポロジを常に模倣する必要があります。Active Directory には、オフィス間のすべてのワイド エリア ネットワーク (WAN) リンクに対応するサイト リンクが必要です。さらに、特定の物理的なオフィス内にあるコンピューターは、共通の Active Directory サイトに配置する必要があります。単一のサブネットは複数の Active Directory サイトをまたぐことはできないので、どの場所でも専用のサブネットを利用するのが理想的です。
Active Directory サイト構造は、WAN リンク経由で発生する Active Directory レプリケーション トラフィック量に直接影響するので重要です。たとえば、複数の支社がある組織について考えてみましょう。この組織では、Active Directory を単一のドメインとして構成しています。これは正しいやり方です。この場合、組織内にある、すべての書き込み可能な DC の Active Directory を更新できます。更新が発生したときには、更新が発生した DC が、他の DC で更新を利用できるようにする必要があります。
この組織が適切なサイト構造を利用していない場合、共通の更新が WAN リンク経由で複数回送信されることがあります。たとえば、支社に DC が 5 つある場合、Active Directory の更新は、WAN リンク経由で 5 回 (つまり、各 DC につき 1 回) 送信される可能性があります。
Active Directory サイトを使用するときには、各サイトの特定の DC がブリッジヘッド サーバーとして機能します。ブリッジヘッド サーバーの役割は、WAN から Active Directory の更新を受け取って、サイト内にある他の DC に配布することです。つまり、Active Directory の更新は、支社にある DC の数にかかわらず、各支社に 1 回だけ送信される必要があります。
支社ごとに別個のドメインを使用する組織についてはどうでしょうか。各支社に専用の Active Directory フォレストがある場合、Active Directory サイトの定義について考慮する必要はありません。これに対し、各ドメインが共通のフォレストのメンバーである場合、フォレスト レベルの Active Directory レプリケーション トラフィックを抑制するために、適切な Active Directory サイト構造を必ず実装する必要があります。
このように、Active Directory ドメインのトポロジをセットアップする方法はたくさんあります。最終的には、自分の組織に最適なトポロジを選択する必要があります。地理的な距離、ユーザー、またはリソースに基づいて、単一のドメイン モデルか複数のドメイン モデルを選択してください。
.jpg)
Brien M. Posey は、MVP であり、数千件の記事と数十冊の書籍を執筆した実績のあるフリーランスのテクニカル ライターです。Posey の Web サイトのアドレスは brienposey.com (英語) です。