Active Directory: Active Directory の構造

シンプルが一番ということも多いですが、Active Directory のインフラストラクチャに今よりも創造的なレイアウトを適用してみてはいかがでしょうか。

Brien M. Posey

実際に展開されている Active Directory を検証するときにいつも驚かされるのは、もちろん例外はありますが、多くの企業が実際に使用できる最もシンプルな設定に固執していることです。

ある意味では、これは驚くことではありません。このような状況に遭遇すると、「私たちは "シンプルにしておきなさい (Keep It Simple, Stupid)" という KISS の原則に従って生きなければならない」とよく言っていた大学教授のことを思い出します。この原則が最もよく当てはまるのは、IT の世界です。

シンプルに保つことで問題が発生する可能性を抑えられることは、経験豊かな IT 担当者ならだれでも知っています。また、シンプルに保つと、問題が発生したときのトラブルシューティングが非常に簡単になります。もちろん簡潔さに良いところがあるのは認めますが、Active Directory のインフラストラクチャに関しては、より創造的な構造にした方が良い場合があります。

標準の Active Directory トポロジを使用してもまったく問題はありません。マイクロソフトが標準のトポロジを既定値として採用したのには理由があります。ただ、管理の責任を分割する必要がある大企業には、もう少し手を加えた設計の方が適している場合があります。

ユーザー ドメイン

多くの場合、実際の Active Directory の設定では、ドメインの構造は企業の地理的な構造に沿った形で作成されています。たとえば、企業に 3 つのオフィスがあるとき、ドメインも 3 つあることが多いです。もちろん、すべての企業でこの設計が採用されているわけではありませんが、これが最も一般的な Active Directory の構造です。地理ベースの Active Directory のトポロジは一般的で効果的ですが、他のドメイン構造についても検討することをお勧めします。

ご存じのとおり、Active Directory は高度なデータベースに過ぎません。Active Directory データベースには、さまざまな種類のオブジェクトが格納されており、各オブジェクトには 1 つまたは複数の属性が割り当てられています。一部の企業では、特定の種類の Active Directory オブジェクトに基づいてドメイン構造を設計しています。この分類のわかりやすい例は、ユーザー ドメインです。

ユーザー ドメインは、ユーザー アカウント管理専用の Active Directory ドメインです。このドメインが役立つ理由を説明するために、私が以前勤めていた企業の話をさせてください。その企業には、数千人のユーザーがいました。また、社員の入れ替わりが激しい企業でした。そのため、ユーザー アカウントの作成、プロビジョニング、および削除を担当する社員を 2 名雇用していました。

このような状況では、ユーザー ドメインが役立つことが証明されました。この種のドメイン構造では、アカウント管理を任されたユーザーに、ユーザー アカウントに対する完全な管理機能が提供されます。ただし、ユーザー オブジェクト以外の Active Directory のオブジェクトや機能へのアクセス権は与えられません。

このような管理作業の分離は、他の方法でも行えます。それでも、ユーザー ドメイン構造が、企業を組織化された状態で保つのに役立つ場合があります。少なくとも、個々のドメインが散乱した状態になるのを回避するのに役立ちます。また、物理的に管理を分離する意味もあります。さまざまな種類のオブジェクトが共通のドメインに存在する場合に導入できる論理的な管理の分離よりも、こちらの方が良いと考える企業もあるでしょう。

リソース ドメイン

リソース ドメインはユーザー ドメインと似ています。リソース ドメインの本来の目的は 1 つで、セキュリティの強化と Active Directory の構造をより論理的で管理しやすくすることです。実際には、すべてのデスクトップ コンピューターを専用のリソース ドメインにグループ化している Active Directory の展開があります。それ以外の種類のリソースに使用する他のリソース ドメインもあります。たとえば、主な基幹業務 (LOB) アプリケーションを実行するすべてのサーバーを、専用のリソース ドメインに配置している企業もあります。

リソース ドメインは、管理ドメインとして使用したときに最も役立つでしょう。たとえば、私は、Hyper-V サーバーの管理専用ドメインとして機能するように設計した Active Directory フォレストを作成しました。この方法を選択したのには、いくつか理由があります。

1 つは、管理上の理由です。System Center Operations Manager 2012 (およびその他の数多くの管理製品) では、Active Directory ドメインのメンバー サーバーしか管理できません。プライマリ ドメインのドメイン コントローラーはすべて仮想化されているため、Hyper-V サーバーをプライマリ ドメインに参加させるのは望ましくありませんでした。仮想化されたドメイン コントローラーがオフラインであるだけのために、Hyper-V サーバーにログオンできなくなるというリスクを回避する必要がありました。この問題は、Hyper-V サーバーを専用の Active Directory 管理フォレストに追加することで解決されました。

Hyper-V サーバー専用のリソース ドメインを作成することを選択したもう 1 つの理由は、Hyper-V 3.0 で導入された新機能と関係があります。最もすばらしいと感じている Hyper-V 3.0 の新機能の 1 つは、ホスト サーバー間で仮想マシン (VM) をレプリケートする機能です。

この種のレプリケーションは、必ずしもフェールオーバー クラスタリング ソリューションであるわけではなく、別のホスト サーバーで最新の状態の VM のコピーを管理するのに役立つ障害回復ソリューションです。ディスク アレイやプライマリ Hyper-V ホストで問題が発生した場合は、VM のもう 1 つのコピーを使用できます。ただし、この機能を使用するには、ホスト サーバーとレプリカ サーバーが両方認証されている必要があります。

この認証を提供する最も簡単な方法は、2 台のサーバーを共通のドメインに追加し、Kerberos 認証を使用することです。そのため、Hyper-V サーバー専用のリソース ドメインを作成するのは、理にかなっています。特にドメイン メンバーシップが必要な他の Hyper-V 機能があることを考えると、これが理にかなっていることがわかるでしょう。

ちなみに、リソース ドメインとユーザー ドメインは互いに排他的ではありません。一部の企業では、共通の Active Directory フォレストでユーザー ドメインとリソース ドメインを組み合わせて使用しています。どちらにも利点があり、必要に応じて、どちらも使用できます。

地理ベースのトポロジ

多くの実際に展開されている Active Directory は、地理的な構造に基づいています。たとえば、ブランチ オフィスが 5 つある企業では、各ブランチ オフィスでそのブランチ オフィスの全物理コンピューターを含むドメインを 1 つずつ使用し、合計 5 つの個別のドメインを使用する場合があります。技術的には、この種の Active Directory トポロジの使用には何の問題もありませんが、いくつか考慮すべきことがあります。

まず、ドメイン構造とサイト構造を混同しないことが重要です。Active Directory のサイト構造は、必ず企業の地理的なトポロジに沿った形になっている必要があります。Active Directory 内には、ブランチ オフィス間のすべてのワイド エリア ネットワーク (WAN) のリンクに対応するサイト リンクが存在している必要があります。また、物理オフィスに配置されているコンピューターは、共通の Active Directory サイトに配置される必要があります。理想的には、それぞれの場所では専用のサブネットを使用する必要があります。これは、複数の Active Directory サイトをまたぐ単一のサブネットを使用できないためです。

Active Directory のサイト構造が非常に重要なのは、サイト構造が WAN リンクで通信できる Active Directory レプリケーション トラフィックの量に直接影響するためです。たとえば、複数のブランチ オフィスを持っている企業が、Active Directory を単一のドメインとして構成する場合を想像してみてください。ここでも、この方法には技術的には何の問題もありませんが、非効率になる場合があります。

このような状況では、Active Directory への更新は、企業内のあらゆる場所にある書き込み可能なドメイン コントローラーに対して行われる可能性があります。更新が行われたときに、他のドメイン コントローラーに更新内容を適用できるようにするのは、そのドメイン コントローラーの役割です。

この企業では適切なサイト構造を使用していなかったため、共通の更新内容を 1 つの WAN リンクを通じて複数回渡すことができません。たとえば、ブランチ オフィスに 5 台のドメイン コントローラーがある場合、Active Directory の更新内容は WAN リンクを通じて、各 DC に 1 回ずつ、合計 5 回別々に送信される可能性があります。

各 Active Directory サイトでは、1 台のドメイン コントローラーが、ブリッジヘッド サーバーとして機能します。ブリッジヘッド サーバーの役割は、WAN リンクを通じて Active Directory の更新内容を受け取って、更新内容をサイト内の他のドメイン コントローラーに配布することです。つまり、Active Directory の更新内容を各ブランチ オフィスに送信する必要があるのは、ブランチ オフィスに存在するドメイン コントローラーの台数にかかわらず、1 回だけです。

ブランチ オフィスごとに個別のドメインを使用する企業はどうでしょうか。各ブランチ オフィスに専用の Active Directory フォレストがある場合、Active Directory サイトの定義について考慮する必要はありません。他方で、各ドメインが共通のフォレストのメンバーになっている場合は、必ずフォレスト レベルの Active Directory レプリケーション トラフィックをチェックする手段として、適切な Active Directory のサイト構造を実装する必要があります。

Active Directory のドメイン トポロジを設定するのには、さまざまな方法があります。最終的には、企業の物理レイアウトとネットワーク インフラストラクチャに最適なトポロジを選択する必要があります。ニーズに応じて、単一のドメイン モデルか、地理的近接性、ユーザー、またはリソースに基づいた複数のドメインを使用するモデルを選択することになります。

Brien M. Posey

Brien Posey は、MVP であり、数千件の記事と数十冊の書籍を執筆した実績のあるフリーランスのテクニカル ライターです。Posey の Web サイトのアドレスは brienposey.com (英語) です。

関連コンテンツ