次の方法で共有

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

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

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

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

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

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

紹介の最適化

参照とは、ドメイン コントローラーがクエリ対象のパーティションのコピーをホストしていない場合に、LDAP クエリがどのようにリダイレクトされるかを示します。 紹介が返されると、パーティションの識別名、DNS 名、およびポート番号が含まれます。 クライアントはこの情報を使用して、パーティションをホストするサーバーでクエリを続行します。 これは DCLocator シナリオであり、サイト定義とドメイン コントローラーの配置に関するすべての推奨事項が維持されますが、紹介に依存するアプリケーションは見過ごされることがよくあります。 サイト定義やドメイン コントローラーの配置を含む AD トポロジがクライアントのニーズを正しく反映していることを確認することをお勧めします。 また、これには、1 つのサイト内に複数のドメインのドメイン コントローラーを配置したり、DNS 設定を調整したり、アプリケーションのサイトを再配置したりする場合があります。

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

フォレスト内シナリオでは、信頼は次のドメイン階層に従って処理されます。 Grand-Child ドメイン -> 子ドメイン -> フォレスト ルート ドメイン -> 子ドメイン -> Grand-Child ドメイン。 つまり、フォレストルートおよび各親のセキュリティチャネルは、信頼階層内のDCを通過する認証要求の蓄積によって過負荷となる可能性があります。 また、認証が上記のフローに影響を与えるために非常に潜在的なリンクを転送する必要がある場合は、大規模な地理的分散のアクティブ ディレクトリでも遅延が発生する可能性があります。 オーバーロードは、フォレスト間および下位レベルの信頼シナリオで発生する可能性があります。 次の推奨事項は、すべてのシナリオに適用されます。

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

  • 負荷に基づいて適宜ショートカットの信頼を作成します。

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

  • 信頼については、ローカリティに関する考慮事項が考慮されていることを確認します。

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

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

  • 信頼するドメイン コントローラーが使用している DNS と WINS の名前解決で、信頼されたドメインのドメイン コントローラーの正確な一覧を解決できることを確認します。

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

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

  • 信頼するドメイン内のドメイン コントローラーは、最初に同じサイト内にある信頼されたドメイン内のドメイン コントローラーの検索を試み、その後、汎用ロケーターにフェールバックします。

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

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

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

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

      注

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

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

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

その他の参照情報