Active Directory LDAPS と Java 181 LDAPS 検証

Active Directory LDAPS と Java 181 LDAPS 検証

Java 8u181 (Java 8 Update 181) では、LDAPS 接続に関するセキュリティが強化されています。

変更: LDAP サポートの改善 LDAPS 接続でエンドポイント識別が有効になりました。LDAPS (セキュア LDAP over TLS) 接続の堅牢性を向上させるために、エンドポイント識別アルゴリズムがデフォルトで有効になっています。以前は LDAPS サーバーに正常に接続できた一部のアプリケーションが、接続できなくなる場合があります。このようなアプリケーションは、適切と判断された場合、新しいシステム プロパティ com.sun.jndi.ldap.object.disableEndpointIdentification を使用してエンドポイント識別を無効にすることができます。エンドポイント識別アルゴリズムを無効にするには、このシステム プロパティを定義 (または true に設定) します。JDK-8200666 (非公開)

これらの拡張機能の 1 つは、ドメイン名が証明書にあるかどうかを確認することです。ただし、Active Directory のデフォルトの動作は、AD ドメイン名の多数の A レコードの下に返される AD サーバーの名前のみを持つというもののようです。また、クライアントがホストのリストをサポートすることはまれです。

このパターンはJava以外でも見られます(Goプログラムでも同様にチェックされます)。Go 1.10 リリースノートの Certificate.Verify)。

証明書に名前を登録して更新する方法については、やや威圧的な TechNet の記事があります。https://blogs.technet.microsoft.com/russellt/2016/06/03/custom-ldap-certs/

きっと、この問題に遭遇しているのは私だけではないはずです。

  1. 証明書に名前を追加するか、一般的な非 AD 固有 LDAP クライアントに対して LDAPS の前にロード バランサーを使用することに成功した人はいますか?
  2. Microsoft がこの問題に何らかの形で取り組んでいて、将来的に「検証を無効にして待つ」という戦術が妥当になるような変更を加える可能性があるかどうか、誰か知っていますか?

答え1

私たちも同じ問題に直面しており、これを解決するための解決策はほとんどありません。

根本原因: プールのホスト名を使用する場合にのみ機能しません。

  • 修正 1:-Dcom.sun.jndi.ldap.object.disableEndpointIdentification=trueアプリケーションに含めてJAVA_OPTS、Tomcat/アプリケーション サーバーを再起動します。これは、厳密なエンドポイント検証を回避するためです。

  • 修正 2: LDAPS プレゼンテーション証明書に記載されている正確なホスト名 (FQDN) を使用します。

LDAPS サーバーの FQDN を確認してください: openssl s_client -connect [LDAPS server IP/DNS]:636。IP/DNS を使用して LDAPS サーバーに接続してみてください。属性に正確な FQDN が表示されますCN=。その FQDN を使用して LDAPS サーバーを構成します。

  • 修正 3: アプリケーション サーバーに LDAPS プレゼンテーション証明書 (ルート証明書または中間証明書ではない) をインポートします。

関連情報