web-dev-qa-db-ja.com

Active Directory LDAPSおよびJava 181 LDAPS検証

Java 8u181（Java 8 Update 181）は、LDAPS接続に関するセキュリティを強化します。

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

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

Javaの外にもこのパターンが表示されます（つまり、Goプログラムはこれを今すぐチェックします Certificate.VerifyのGo 1.10リリースノート ）も参照してください）。

更新される方法で証明書の名前を取得することについて、やや脅迫的なtechnetの記事があります。 https://blogs.technet.Microsoft.com/russellt/2016/06/03/custom-ldap-certs /

これに遭遇しているのは私だけではありません：

  1. 証明書に名前を追加したり、AD固有でない一般的なLDAPクライアントのLDAPSの前にロードバランサーを使用したりすることに成功した人はいますか？
  2. マイクロソフトが「検証を無効にして待機する」ことを正気な戦術にする将来の変更があるかもしれない方法でこの問題に直面しているかどうか誰かが知っていますか？
active-directorysslldapjava
2
Kyle Brandt

私たちは同じ問題に直面し、これを修正するためのいくつかの解決策があります。

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

  • 修正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サーバーに接続してみてください。 CN=属性に正確なFQDNを表示します。そのFQDNを使用してLDAPSサーバーを構成します。

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