freeipa sslldapおよびラウンドロビンDNS
私は答えられる方法でこの質問をしようとしていますが、問題の一部は私の現在の状況の影響を知ることであり、問題や技術的負債があるかどうかは私をさらに悩ませます。
マスターとレプリカのセットアップでいくつかのIPAサーバーをセットアップしました。
server1：dnsレコード（およびfqdnホスト名）：srv1.mydomain.com
server2：dnsレコード（およびfqdnホスト名）：srv2.mydomain.com
server3：dnsレコード（およびfqdnホスト名）：srv3.mydomain.com
サーバーのcnameはそれぞれauth-a、auth-b、auth-cであり、通常のIPAインストールに従って自己署名証明書を使用します。
これは、ssh接続やsssdなどで数か月間正常に機能しました。この問題は、1つのLDAPサーバーのみを指定できるアプリケーションをフックしようとしたときに発生しました。フェイルオーバー用にセットアップされたSRVDNSレコードがありますが、これらのアプリを機能させるために、DNSラウンドロビンレコードも入力します。
キャッチは、このラウンドロビンが通常のLDAPルックアップでのみ機能し、LDAPsslでは機能しないことです。 ssl証明書のチェックを無効にすると、sslを機能させることができます。
だから...質問！
a）現実的には、内部サービスで証明書のチェックを無効にすることはどれほど悪いことですか？このLDAPサーバーは、常にLANから照会されます。私はMITM攻撃の可能性に開かれていると思いますが、それについてどれほど心配する必要があるのかはわかりません。つまり、今のところ、他のオプションはSSLを使用していないということですが、それは恐ろしいソースです。 MITM攻撃を実行するには、彼らはすでに私のネットワーク上にいて、DNSを制御している必要がありますね。その懸念を実際の用語に定量化できるアドバイスがあれば役に立ちます。
b）これを実際に修正することを理解しているので、サーバーの自己署名証明書のサブジェクト代替名としてRRdnsエントリを指定する必要があります。つまり、サーバーのキーを再入力するということですよね？これは、IPAの場合、新しい証明書のためにeveryクライアントをIPAに再参加させることを意味します。それは私が思うに初心者ではありません。
c）（a）と（b）の現在の状況と結果を考えると、1つのLDAPサーバーのみを指定できる（そしてSRV dnsレコードを使用しない）アプリを許可するための最善のアクションとして何をお勧めしますか方法）他のサーバーにフェイルオーバーするには、一方がダウンしても、LDAP over sslが証明書を提供できるようにしますか？
SubjectAlternitiveNamesを使用して新しい証明書を発行し、その名前のDNSレコードをロードバランサーにポイントする必要があります。
- A）証明書チェックをオフにすると、MITMにアクセスできるようになります。利点は、暗号化されたチャネルを受動的に軒を落とすことはできないことです。暗号化されたチャネルをMITMするのはもっと手間がかかりますが、それほど多くはありません。価値が高くなく、（VPNリンクではなく）ワイヤレスまたはオープンインターネットを介して動作しない場合、証明書のチェックをオフにすることはそれほど危険ではありませんが、そうしないでください。正しい方法で物事を行うのも同じくらい簡単です。
- B）はい、サーバーにはsubjectAlternitiveNameまたはワイルドカードsubjectNameが必要です（これは行いません）。 ただし、FreeIPAは独自のPublicKeyInfrastucture（PKI）を実行します。つまり、自己署名証明書のコレクションではなく、独自の自己署名認証局（CA）があります。つまり、FreeIPAサーバー（LDAPで使用されるサーバー）の証明書を生成して置き換えるだけで済みます。署名に使用されるCA証明書（すべてのマシンに展開される証明書）は同じままなので、他のマシンに触れる必要はありません。また、サーバーの秘密鍵は必要ありません。公開証明書だけが必要です。
- C）上部を参照してください、AとBは正当化です。
ラウンドロビンDNSは、クライアントが障害のあるサーバーを含むサーバーの1つにランダムに接続しようとするため、DNSからA/AAAAレコードをプルしない限り、サーバーに障害が発生した場合に必ずしも可用性を高めるとは限りません。アプリケーションが再接続を試みない場合、または運が悪く、同じレコードを連続して十分な回数取得して失敗した場合。前にロードバランサーを追加すると、複雑さが増しますが、この可能性が少なくなることを意味します。負荷分散のラウンドロビンに満足している場合は、証明書にサブジェクト代替名を入力することでクライアントがLDAPに満足できるかどうか、またはワイルドカードが適切であるかどうかを確認します。中間者を防ぐには、独自の内部PKIを実行し、これを信頼できるCAとしてクライアントマシンに展開することもできます。これには、独自の証明書を持つ各ホスト/サービスでこれを管理する必要がなく、期限切れまたは期限切れの証明書を確認できる中心的な場所であるという追加の利点があります。
あなたが求めているのがHAだけの場合、私は少し単純ですが便利なことをします。
IPA用にHAクラスターをセットアップし（トラブルを回避するために、libvirtサービスが保護されたプロセスであるVMで実行するだけです）、他のIPAはユーザー認証を行う傾向がありますが、そのIPAインスタンスをすべての制限付きアプリに使用します。 IPAはKVMでうまく機能します。私は何年にもわたって問題がなく、かなりの数のインスタンスを実行してきました。