次の方法で共有

ドメイン コントローラーとサイトの適切な配置に関する考慮事項

適切なサイト定義は、パフォーマンスにとって重要です。 クライアントがサイトから出た場合、認証とクエリのパフォーマンスが低下する可能性があります。 さらに、クライアントに IPv6 が導入された場合、要求が IPv4 アドレスまたは IPv6 アドレスのいずれかから送信される可能性があり、Active Directory では IPv6 用にサイトが適切に定義されている必要があります。 両方が構成されている場合、オペレーティング システムでは IPv6 が IPv4 よりも優先されます。

Windows Server 2008 以降では、クライアントが存在するサイトを特定するために、ドメイン コントローラーでは名前解決を使用して逆引き参照を実行します。 これにより、ATQ スレッド プールが枯渇し、ドメイン コントローラーが応答しなくなる可能性があります。 これを適切に解決するには、IPv6 のサイト トポロジを適切に定義します。 回避策として、名前解決インフラストラクチャを最適化して、ドメイン コントローラーの要求に迅速に応答することができます。 詳細については、Windows Server 2008 または Windows Server 2008 R2 ドメイン コントローラーによる LDAP または Kerberos 要求への応答の遅延に関する記事を参照してください。

また、RODC が使用されているシナリオで、読み取り/書き込み用の DC を見つけることも、考慮する必要があります。 特定の操作では、読み取り専用ドメイン コントローラーで十分な場合に、書き込み可能なドメイン コントローラーにアクセスするか、書き込み可能なドメイン コントローラーをターゲットとする必要があります。 これらのシナリオを最適化するには、次の 2 つのパスを使用します。

  • 読み取り専用ドメイン コントローラーで十分な場合に書き込み可能なドメイン コントローラーに接続する。 これには、アプリケーション コードの変更が必要です。
  • 書き込み可能なドメイン コントローラーが必要な場合。 待機時間を最小限に抑えるために、読み取り/書き込みドメイン コントローラーを中央の場所に配置します。

詳細については、以下を参照してください。

紹介の最適化

紹介とは、クエリされたパーティションのコピーがドメイン コントローラーにホストされていない場合に LDAP クエリがリダイレクトされる方法です。 紹介が返されるとき、紹介にはパーティションの識別名、DNS 名、ポート番号が含まれています。 クライアントではこの情報を使用して、パーティションがホストされているサーバーでクエリを続行します。 これは DCLocator のシナリオであり、推奨のすべてのサイト定義とドメイン コントローラーの配置が保持されますが、紹介に依存するアプリケーションは見落とされがちです。 サイト定義やドメイン コントローラーの配置を含む AD トポロジに、クライアントのニーズが適切に反映されるようにすることをお勧めします。 また、これには 1 つのサイトに複数のドメインのドメイン コントローラーを含めたり、DNS 設定をチューニングしたり、アプリケーションのサイトを再配置したりすることを含む場合があります。

信頼の最適化に関する考慮事項

フォレスト内のシナリオでは、信頼は次のドメイン階層に従って処理されます。孫ドメイン -> 子ドメイン -> フォレスト ルート ドメイン -> 子ドメイン -> 孫ドメイン。 つまり、フォレスト ルートのセキュリティで保護されたチャネルとそれぞれの親は、信頼階層内の DC を通過する認証要求の集計のために過負荷になる可能性があります。 また、認証が、上記のフローに影響を与える可能性の高い潜在的なリンクも通過する必要がある場合は、地理的に広く分散した Active Directory で遅延が発生する可能性があります。 フォレスト間およびダウンレベルの信頼のシナリオで過負荷が発生する可能性があります。 次の推奨事項は、すべてのシナリオに適用されます。

  • セキュリティで保護されたチャネル全体の負荷をサポートするために、MaxConcurrentAPI を適切に調整します。 詳細については、「MaxConcurrentApi の設定を使用して NTLM 認証のパフォーマンスを調整する方法」を参照してください。

  • 負荷に基づいて、必要に応じてショートカットの信頼を作成します。

  • ドメイン内のすべてのドメイン コントローラーが名前解決を実行し、信頼される側のドメイン内のドメイン コントローラーと通信できる必要があります。

  • 信頼の局所性に関する考慮事項を検討するようにしてください。

  • 可能であれば Kerberos を有効にし、セキュリティで保護されたチャネルの使用を最小限に抑えて、MaxConcurrentAPI のボトルネックが発生するリスクを軽減します。

クロス ドメイン信頼のシナリオは、多くのお客様にとって常に問題点となっていた分野です。 名前解決と接続の問題は、多くの場合はファイアウォールが原因ですが、この問題によって、信頼する側のドメイン コントローラーでリソースが枯渇し、すべてのクライアントに影響を与えます。 さらに、見落とされがちなシナリオは、信頼されたドメイン コントローラーへのアクセスを最適化することです。 これを正しく機能させるための重要な分野は、次のとおりです。

  • 信頼する側のドメイン コントローラーが使用している DNS と WINS の名前解決によって、信頼される側のドメインのドメイン コントローラーの正確な一覧を解決できる必要があります。

    • 静的に追加されたレコードは、時が経つにつれて古くなり、接続の問題が再発する傾向があります。 DNS 転送、動的 DNS、WINS/DNS をマージしたインフラストラクチャの方が、長期的な保守性が向上します。

    • クライアントがアクセスする必要がある環境内のすべてのリソースについて、前方参照ゾーンと逆引き参照ゾーンの両方に対して、フォワーダー、条件付き転送、およびセカンダリ コピーを適切に構成するようにします。 繰り返しになりますが、これには手動のメンテナンスが必要であり、古くなる傾向があります。 インフラストラクチャの統合が理想的です。

  • 信頼する側のドメイン内のドメイン コントローラーは、最初に同じサイト内にあって後に汎用ロケーターにフェールバックする、信頼される側のドメイン内のドメイン コントローラーを見つけようとします。

    • DCLocator のしくみの詳細については、「最も近いサイトでのドメイン コントローラーの検索」を参照してください。

    • 同じ場所にあるドメイン コントローラーを反映するように、信頼される側のドメインと信頼する側のドメインの間でサイト名を収束させます。 サブネットと IP アドレスのマッピングが、両方のフォレストのサイトに正しくリンクされるようにします。 詳細については、「フォレストの信頼全体でのドメイン ロケーター」を参照してください。

    • ドメイン コントローラーの場所について、DCLocator のニーズに応じてポートが開いている必要があります。 ドメイン間にファイアウォールが存在する場合は、すべての信頼に対してファイアウォールが正しく構成されているようにします。 ファイアウォールが開いていない場合、信頼する側のドメイン コントローラーは引き続き信頼される側のドメインへのアクセスを試行します。 何らかの理由で通信が失敗した場合、信頼する側のドメイン コントローラーは最終的に、信頼される側のドメイン コントローラーへの要求をタイムアウトにします。 ただし、これらのタイム アウトには要求ごとに数秒かかる場合があるため、受信要求の量が多い場合は、信頼する側のドメイン コントローラーのネットワーク ポートが枯渇する可能性があります。 クライアントではこの待機が、ハングしたスレッドとしてドメイン コントローラーでタイムアウトとなる可能性があり、これはアプリケーションがハングしたことになる可能性があります (アプリケーションがフォアグラウンド スレッドで要求を実行している場合)。 詳細については、ドメインと信頼のためのファイアウォールの構成方法に関する記事を参照してください。

    • DnsAvoidRegisterRecords を使用して、パフォーマンスの低いドメイン コントローラーや待機時間の長いドメイン コントローラー (サテライト サイト内のドメイン コントローラーなど) を、汎用ロケーターにアドバタイズするものから除外します。 詳細については、「クライアントのサイトの外部に存在するドメイン コントローラーまたはグローバル カタログの場所を最適化する方法」を参照してください。

      注意

      クライアントで使用できるドメイン コントローラーの数には、約 50 個という現実的な制限があります。 これらはサイトに最適で、容量が最も高いドメイン コントローラーである必要があります。

    • 信頼される側のドメインと信頼する側のドメインのドメイン コントローラーを、物理的に同じ場所に配置することを検討してください。

すべての信頼シナリオで、資格情報は認証要求で指定されたドメインに従ってルーティングされます。 これは、LookupAccountName および LsaLookupNames (これらはただ最も一般的に使用されるというだけで、他も同様です) の API に対するクエリにも当てはまります。 これらの API のドメイン パラメーターに NULL 値が渡された場合、ドメイン コントローラーは、信頼される側の使用可能なすべてのドメインで指定されたアカウント名の検索を試みます。

その他の参照情報