Active Directory認証の負荷分散とフェイルオーバー

Active Directory DCに対して認証するアプリケーションの場合、明らかに、フェイルオーバーやロードバランシングなどの特定のDCではなく、メインドメインのDNSレコードを指すようにするのが最善です。

DCのIPをハードコードすることを強制するこれらのアプリケーションのベストプラクティスは何ですか？代わりに、ロードバランサーのIPアドレスをハードコーディングして、1つのDCがダウンしても、そのアプリケーションが認証できるようにすることができます。より良い代替案はありますか？

Active Directoryにはすでに負荷分散技術が組み込まれています。Windowsクライアントは、独自のサイトで冗長ドメインコントローラーを見つける方法と、最初のドメインコントローラーが利用できない場合に別のドメインコントローラーを使用する方法を知っています。冗長なDCがある限り、「クラスター化された」DCなどの追加の負荷分散を実行する必要はありません。

ある意味では、Active Directoryサイトは "ロードバランサー"と考えることができます。これは、そのサイトのクライアントが同じサイトのDCの1つをランダムに選択するためです。サイト内のすべてのDCに障害が発生した場合、またはサイトにDCがない場合、クライアントは別のサイト（次に近いサイトまたはランダムに）を選択します。

ハードウェアロードバランサーにVIPを配置し、VIPを複数のドメインコントローラー間で負荷分散することにより、ドメインに参加しているクライアントにActive Directoryが提供するDNSサービスの負荷を分散できます。次に、クライアントで、そのVIPを優先DNSサーバーとしてTCP / IP構成に配置します。

私は今、グローバルインフラストラクチャのためにそれを行っています。

ただし、これはDNSサービスにのみ適用されます。

認証のためにドメインコントローラの負荷を分散しようとしないでください。困ったことです。少なくとも、多くの複雑なカスタムSPN作業を行う必要があり、Microsoftサポートの境界から自分自身を解放することになります。あなたが読むべきこのブログから、私は彼を引用します：

ベンダーに戻って、それらがAD統合されているとは見なさないことを伝え、別のソリューションを見つけます。

ここで、ドメインコントローラのIPアドレスを入力するように要求するアプリケーションについてはどうでしょうか。まあ、私は私のコメントを繰り返します。

ドメインコントローラーのIPアドレスをそのアプリケーションにハードコードするように強制するアプリケーションを書いた人は、彼または彼女が何をしているのか知りません。

IPをハードコーディングしたり、IPを使用してADクエリを解決したりする正当な理由はありません。バッドプラクティスのベストプラクティスはありません。

この質問に対する他のいくつかの回答は、Microsoft対応アプリケーション以外の世界はないと想定しているようです。元の質問による証拠として、残念ながらこれは当てはまりません：

DCのIP をハードコードすることを強制するこれらのアプリケーションのベストプラクティスは何ですか？

マイクロソフトはActive Directoryの前でNLBソリューションを使用することをサポートまたは推奨していませんが、Microsoft以外のAD対応アプリケーションを認証するためのいくつかのオプションがあるようです。

• AD LDSでのプロキシ認証について
• LDAPの負荷分散のためのF5認定iApp
• SASLによるパススルー認証

外部の「負荷分散」ADが実際に必要になることはまれであり、適切に行うことは困難です。一般的なクエリの必要性は問題なく機能しますが、一般的なWindowsクライアントとアプリケーションは更新を実行する必要があります。Windowsクライアントは特定のDCとのアフィニティを確立しようとするため、何かを更新してすぐに後続の操作を試みると、同じDCにヒットします。アプリケーション開発者も同じことを行います。ユーザーアカウントを作成するコードを記述し、そのアカウントのパスワードを1ミリ秒後に変更しようとすると、同じDCをヒットする必要があります。

ロードバランサーソリューションを使用してADのフロントエンドを行う場合は、それらのアプローチとアフィニティが壊れないようにする責任を負います。

負荷を分散するのではなく、可用性が必要な場合は、クラスタリングの方が適切な場合があります（ワームのクラスタは別として）。

大規模なADの実装では、より伝統的なアプローチは、大多数のコンシューマーを識別し、それらを独自のDCがあるサイトに配置することです。たとえば、5つのExchangeサーバーがある場合、それらのサーバーのサブネット用のサイトを作成し、そのサイトに専用GCを配置します。SharePointなどの他のサーバーにも同じことが当てはまります。