LDAPサービスとしてADを使用するアプリケーションでADを高可用性にする方法
私たちの状況
現在、認証にLDAPを使用する多くのWebアプリケーションがあります。このために、LDAPSポートを使用してWebアプリケーションをADドメインコントローラーの1つにポイントします（636）。
ドメインコントローラーを更新する必要がある場合、もう1つのWebアプリケーションが任意のDCに依存する可能性があるため、これにより問題が発生します。
私たちが欲しいもの
Webアプリケーションがクラスターの「仮想」IPを指すようにしたいと思います。このクラスターは、少なくとも2つのサーバーで構成されます（各クラスターサーバーをローテーションして更新できるようにするため）。次に、クラスターサーバーはLDAPS接続をDCにプロキシし、使用可能な接続を特定できるようにします。
質問
ADのLDAPインターフェース用のHAクラスターを作成した経験のある人向け：
- クラスターにはどのソフトウェアを使用しましたか？
- 注意点はありますか？
- それとも、似たようなことを達成するための完全に異なるアーキテクチャですか？
更新
おそらく私の質問は最初は十分に明確ではなかったのでしょう。申し訳ありません。
これらのWebアプリケーションは、当社が開発したものではなく、AD対応ではありません。 LDAPサーバーのホスト名/ IPアドレスのみを要求します。残念ながら、その制限に対処する必要があります。 SRV records動作しますが、これらはアプリケーションではないため、この場合は役に立ちません。
また、開発者にアプリケーションをAD対応にするように強制することも現実的ではありません。
唯一の選択肢は、ソフトウェアではなく、インフラストラクチャ内でこの問題に対処することです。私の質問は、それを具体的に行った人に向けられています。
これには、OpenLDAPサーバーに対して Cisco IOSのサーバーロードバランサー（SLB） を使用します。
LDAPはLDAPであるため、MicrosoftのActiveDirectoryでも機能するはずです。
他のメーカーが同様の製品/機能を提供しています。 tcp 389/636のバランスをとるのは、tcp 80/443（またはその他のtcp）のバランスをとるのと同じです。
ただし、証明書に問題がある可能性があります。警戒を緩めるようにアプリケーションに指示できる場合があります。 （ADの証明書がどのように署名されているか、またはどのCAを信頼しているかは、すでにわかっていない可能性があります。）または、ADサーバーに適切なsubjectAlternativeNameフィールドを持つ証明書を使用させます。
WebアプリサーバーをActiveDirectoryドメインのFQDNに向けることができるはずです。これにより、利用可能なDCに接続されます。
たとえば、ドメインにいくつかのDCがある場合があります。
dc1.example.com
dc2.example.com
Webサーバーをdc1またはdc2に明示的に向けるのではなく、example.comに向けるだけです（ポート636でexample.comにtelnetで接続してみてください。DCに接続できます）。基本的にはラウンドロビンDNSだと思います。
DCがオフラインだった場合、どうなるかわからないことを認めなければなりません。DNSレコードがそれを反映するのに時間がかかる場合がありますが、実際に反映される場合は、価値があるかもしれません。ロードバランサーを間に置く代わりにテストします。
これを行う正しい方法は、 DNS SRV レコードを使用して、ドメインコントローラーの名前とポートを検索し、どのサーバーをどの順序で使用するかを確認することです。残念ながら、SRVレコードルックアップをサポートしているLDAPアプリケーションは多くないようです。
Active DirectoryドメインコントローラーのSRVレコードは_ldap._tcp.domain.tld。これにより、ホストとポートのリストに加えて、使用するサーバーを示す優先度と重み（これらの値はグループポリシーを使用して設定できます）のリストが返されます。
可能な解決策は、LDAPプロキシサーバーです。そこに多くはありませんが、間違いなくトリックを行います。ここに1つありますが、少しやりすぎです- http://www.unboundid.com/products/directory-proxy-server.php 。このLDAPプロキシサーバーに代わる、はるかに安価なオープンソースの選択肢があると確信しています。
編集：考えてみれば、アプリケーション内にLDAP URIを入力する場所がありますか？その場合、次のようにスペースで区切られたサーバーのシーケンスを入力できません：ldap：//123..456.789.111 ldap：//123.456.789.222 ldap：//123.456.789.444
アプリケーションは、1つのドメインコントローラーが使用できない場合にWindowsクライアントが内部で行うことを実行するのに十分な堅牢性を備えている必要があります。つまり、別のドメインコントローラーに接続しようとします。
これが機能する方法は、アプリケーションの起動時に、アプリケーションのディレクトリサービスアクセスコンポーネントが次のことを行うことです。
- サイト内のすべてのドメインコントローラー（および必要に応じて隣接するサイト）のリストを作成します
- 一連のテストを実行して接続を検証します（ping、389/3268/636テスト）。これにより、DC、GC、またはRODCのいずれであるかも確認されます。
- 簡単なクエリを実行して、ディレクトリサービスが機能し、認証が機能していることを確認します。
- 正常なドメインコントローラーのリストと、オフラインドメインコントローラーのリストを保存します。
次に、バインドを実行するときにこれらの既知の適切なサーバーを使用して、バインドパスにサーバーを埋め込みます。例外が発生し、DCの問題を示すタイプの1つである場合（サーバーが操作不能、ビジー、タイムアウトなど）、そのDCをオフラインリストに追加し、他のDCの1つを使用して操作を試みます。
ロードバランサーを使用するか、DNSラウンドロビンに依存する（つまり、ldap.contoso.comは複数のIPに解決される）かを決定した後、証明書が主要な問題になるため、Russell Tomkins（MSFT）は、これらのユースケースはここにあります： 自動更新によるドメインコントローラーのカスタムセキュアLDAP証明書の作成
彼はまた、これはサポートされている構成ではないと述べています。他の回答が指摘しているように、アプリケーションはSRVレコードを使用する必要がありますが、多くの場合は使用しません。
基本的に、証明書を発行するための新しいテンプレートを追加する必要があります。このテンプレートでは、プロパティタブの[件名]で[リクエストで提供]に切り替えます。ロードバランサーの名前（ldap.contoso.com）を追加のSNとして指定して、最初の証明書を自分で発行する必要があります。その後、自動登録が引き継ぎます。