Active Directory

Active Directory でキャッチオール サブネットを使用する

John Policelli

 

概要:

  • ドメイン コントローラ ロケータ
  • ハブとスポークのトポロジ
  • キャッチオール サブネットを実装する

目次

クライアント コンピュータによるドメイン コントローラの検出方法
問題点
キャッチオール サブネット
まとめ

ユーザーが適切なドメイン コントローラ (DC) に接続され、Active Directory 認証を受けるのが理想的な環境です。しかし、ほとんどの組織では IP サブネット情報が Active Directory 内で正しく定義されていないために、こうした処理が行われていません。そのため、多くのユーザーが認証を受けるドメイン コントローラは定まっていませんが、これは最適な Active Directory 認証ではありません。

この記事では、IP サブネット情報が Active Directory 内で完全に定義されていない場合に、ユーザーが認証に適した DC を見つけられるようにするソリューションを紹介します。

クライアント コンピュータによるドメイン コントローラの検出方法

クライアント コンピュータ (クライアント) でドメイン コントローラを検出する際には、適切な Active Directory ドメイン コントローラを検出できるようにドメイン コントローラ ロケータ (ロケータ) と呼ばれるプロセスが開始されます。ロケータでは Active Directory と DNS に格納されている情報を使用して、必要な役割が割り当てられている、クライアントに最も近いサイト内にあるドメイン コントローラを検出します。

ロケータでは、フォレストのルート ドメインの構成コンテナで定義されている情報が使用されます (この情報は、フォレスト内の各ドメイン コントローラにレプリケートされます)。サイト オブジェクト、サブネット オブジェクト、およびドメイン コントローラ サーバー オブジェクトは、どれもロケータがクライアントに最も近いドメイン コントローラを検出するために必要不可欠なものです。サイト オブジェクトは、Active Directory サイトを表すために使用されます。サブネット オブジェクトは、IP アドレスのセグメントを表すために使用され、適切なサイト オブジェクトに関連付けられています。ドメイン コントローラ サーバー オブジェクトは、ドメイン コントローラを表すために使用され、サイト オブジェクトに関連付けられています。

Active Directory ドメイン コントローラでは、DC が存在するサイトを指定する DNS レコードを登録します。各ドメイン コントローラによって登録される DNS レコードの数は、DC に割り当てられている役割によって異なります。たとえば、グローバル カタログ サーバーの役割が割り当てられている DC では、そうした役割を担っていることをアドバタイズする追加の DNS レコードを登録します。同様に、操作マスタの役割が割り当てられているドメイン コントローラでは、そうした役割を担っていることをアドバタイズする DNS レコードを登録します。

クライアントによるドメイン コントローラの検出プロセスは次のとおりです。

  1. ローカルの Net Logon サービスへのリモート プロシージャ コール (RPC) によって、クライアントでロケータが開始されます。
  2. クライアントによって、ドメイン コントローラの選択に必要な情報が収集され、その情報が Net Logon サービスに渡されます。
  3. クライアントで実行されている Net Logon サービスによって、クライアントが収集した情報を使用して、適切なドメイン コントローラを識別するためのクエリが作成され、DNS に送信されます。
  4. クライアントで実行されている Net Logon サービスによって、検出されたドメイン コントローラにデータグラムが送信されます。
  5. ディレクトリ サービスによってクエリが取得され、ドメイン コントローラで実行されている Net Logon サービスに渡されます。
  6. ドメイン コントローラで実行されている Net Logon サービスによって、サブネットとサイトのマッピング テーブルで、クライアントの IP アドレスと一致率の高いサブネット オブジェクトが検出されて、クライアントの IP アドレスが検索されます。その後、クライアントが存在するサイトの名前またはクライアントの IP アドレスと最も一致率の高いサイトの名前、現在のドメイン コントローラが存在するサイトの名前、検出された DC がクライアントに最も近いサイト内にあるかどうかを示すビットなどの情報がクライアントに返されます。
  7. クライアントによって、より適切なドメイン コントローラを検索する必要があるかどうかを判断するために情報が精査されます。その必要性の判断は、次のような方法で行われます。検出されたドメイン コントローラが最も近いサイト内にある場合、クライアントでは、そのドメイン コントローラが使用されます。クライアント によって、DC と同じサイト内にクライアントが存在すると報告する DC が検出された場合、クライアントでは、そのドメイン コントローラが使用されます。検出された DC が最も近いサイト内に存在しない場合、クライアントでは、サイト情報が更新され、最も近いサイトの別の DC を検出するために新しい DNS クエリが送信されます。2 回目のクエリが成功した場合は新しい DC が使用され、失敗した場合は最初に検出された DC が使用されます。
  8. クライアントからクエリが送信されているドメインと、クライアントが参加しているドメインが同じ場合、クライアントが存在するサイトがクライアントのレジストリに格納されます。
  9. クライアントによって DC が検出されると、ドメイン コントローラのエントリがキャッシュされます。ドメイン コントローラが最適なサイト内に存在していない場合、クライアントによって 15 分後にキャッシュがフラッシュされ、キャッシュ エントリが破棄されます。その後、クライアントが存在するサイトと同じサイト内で最適なドメイン コントローラが検索されます。

サブネットとサイトのマッピング テーブルに存在しない IP アドレスがクライアントで使用されている場合、DC から NULL のサイト名が返され、クライアントでは結果として返されたドメイン コントローラが使用されますが、そのドメイン コントローラは任意の Active Directory サイト内に存在するものになります。

問題点

IP サブネット情報が Active Directory 内で定義されていないためにドメイン コントローラで最も近いサイトを特定できない場合、最適ではない DC が認証に使用されることになります。

図 1 に、ハブとスポークのトポロジを使用する Active Directory サイトのサンプル デザインを示します。Active Directory 内で定義されているサブネット上のクライアントにログオンしているユーザーは、最も近い Active Directory サイト内にあるドメイン コントローラに接続され、認証されます。ただし、その他のサブネット (たとえば、10.1.4.0/24) 上のクライアントにログオンしているユーザーは、どの DC に接続されるか決まっていません。

fig01.gif

図 1 ハブとスポークのトポロジを使用するサイトのサンプル デザイン

この問題に対処する適切な解決策は、Active Directory 内で追加のサブネットを定義し、そのサブネットと適切なサイトを関連付けることです。ただし、組織 (特に、中規模および大規模な組織) では、こうした追加のサブネットを Active Directory に追加するために必要な情報を取得する際、問題に直面することがよくあります。どのような問題かと言うと、通常、Active Directory の管理者はエラーやログ ファイルの内容から、追加のサブネットの存在に気付きますが、こうした追加のサブネットがどのオフィスに属しているかを把握できないので、サブネットと関連付けるサイトを特定できません。

キャッチオール サブネット

この問題のより実用的な解決策は、Active Directory 内で 1 つ以上のキャッチオール サブネットを使用することです。キャッチオール サブネットとは、Active Directory 内で定義されていないサブネット上のクライアントの認証を受け付けるために使用する Active Directory サブネットです。実質的に、キャッチオール サブネットはスーパー サブネットです。

図 1 に示すように、10.1.1.0/24 サブネットは Active Directory 内で定義されていて、Toronto という Active Directory サイトに関連付けられています。10.1.4.0/24 サブネットと 10.1.5.0/24 サブネット上の多数のクライアントが、Active Directory に対して認証を行っているとします。プレフィックス (10.1.x.x) から、10.1.4.0/24 サブネットと 10.1.5.0/24 サブネットは Toronto オフィス内にあると考えるでしょう。これらのサブネット上のクライアント、および 10.1.x.x というプレフィックスを使用するその他のサブネット上のクライアントが、Toronto サイト内の DC に対して認証を行うようにする必要があります。そのため、10.1.0.0/16 というプレフィックスを使用するキャッチオール サブネットを作成して Toronto オフィスに存在すると思われるすべてのサブネットからの認証要求を送信し、Toronto サイト内にある DC が認証で使用されるようにします。この例のキャッチオール サブネットのマッピングを図 2 に赤色の文字で示します。

fig02.gif

図 2 ハブ サイトにキャッチオール サブネットを使用

ほとんどの組織では、リモート オフィスの IP サブネット情報が Active Directory 管理者に伝達されます。通常、本社、ハブ サイト、およびデータ センターの IP サブネットは異なります。そのような場合でも、キャッチオール サブネットを使用して認証を強化できます。リモート オフィスの IP サブネットが変更されることはほとんどなく、通常、Active Directory の管理者はリモート オフィスの IP サブネットについて十分理解しているので、その他のすべてのサブネットに対応するキャッチオール サブネットを作成できます。

この例では、10.0.0.0/8 というプレフィックスを使用するキャッチオール サブネットを作成して、特定のリモート オフィスに属していないと思われるすべてのサブネットからの認証を受け付け、中央の Toronto サイト内にある DC で認証が行われるようにすることができます。この例のキャッチオール サブネットのマッピングを図 3 に赤色の文字で示します。また、必要に応じて、図 4 に示すように複数のキャッチオール サブネットを使用することもできます。

fig03.gif

図 3 すべてのサイトに対応したキャッチオール サブネット

fig04.gif

図 4 複数のキャッチオール サブネットの使用

図 3 と図 4 のキャッチオール サブネットでは、リモート サイトで使用されているプレフィックスと重複するプレフィックスが使用されています (たとえば、10.0.0.0/8 の対象範囲には 10.1.1.0/24 が含まれます)。このような場合でも、リモート オフィスのクライアントから行われた認証要求が、適切なリモート オフィスのドメイン コントローラに送信されるかどうか、疑問に思う人もいるでしょうが、問題ありません。重複する IP サブネットが Active Directory 内に存在する場合、サブネット マスクの最下位が一致する IP サブネットが使用されます。たとえば、クライアントの IP アドレスのサブネットが 10.1.1.5/24 である場合、10.0.0.0/8 ではなく 10.1.1.0/24 が使用されます。ただし、IP アドレスが 10.1.1.5 であるクライアントの場合は、10.1.1.0/24 ではなく 10.1.1.1./32 が使用されます。

まとめ

キャッチオール サブネットを実装する前に、キャッチオール サブネットの概念がすべての環境に適しているわけではないことを知っておく必要があります。このソリューションを実現できるかどうかは、使用している IP アドレス体系に大きく左右されます。

ここで紹介した例の IP アドレス体系は非常に単純ですが、IP アドレス体系が複雑になればなるほど、キャッチオール サブネットを使用できる可能性は低くなります。たとえば、環境が複数のネットワーク セグメントで構成されていて、それぞれの場所で連続した IP アドレスが使用されていない場合、任意の値を渡すキャッチオール サブネットを作成することは現実的に不可能です。あらゆるソリューションと同様に、キャッチオール サブネットを実装できるかどうかを判断する際には、環境に固有の技術的な要因、ビジネス要因、および環境要因を考慮する必要があります。

また、キャッチオール サブネットを使用しても、サブネットが存在しないという問題は完全には解決されません。実際、ご使用の環境にキャッチオール サブネットを導入する場合は、Active Directory 内ですべての既知のサブネットを明示的に定義することがさらに重要になります。

キャッチオール サブネットを使用すると、最も近いドメイン コントローラを見つけられるユーザーが増加します。しかし、その場合でも、目標は問題の原因に対処し、ネットワーク サブネットに対して行われたすべての追加、変更、および削除についての適切な情報を受け取るようにして、すべてのユーザーが効率的に認証され Active Directory サイトの最新デザインを維持できるようにすることです。

John Policelli は、ソリューションを専門とした IT コンサルタントで、アーキテクチャ、セキュリティ、戦略計画、障害復旧計画の分野で 10 年以上に渡って成功を収めています。また、ディレクトリ サービス、MCTS、MCSA、ITSM、iNet+、Network+、A+ の Microsoft MVP 受賞者です。ここ 9 年ほどは、ID とアクセスの管理に重点を置いており、カナダで最大規模を誇るいくつかの Active Directory の実装では、思想的なリーダーシップを発揮しました。彼のブログは http://policelli.com/blog で読むことができます。