Apache LDAP認証が失敗する理由を理解できません

突然、昨日、私のApacheサーバーの1つがLDAP（AD）サーバーに接続できなくなりました。私はそのサーバーで2つのサイトを実行しています。どちらのサイトにもユーザーがログインするときに、どちらのサイトもLDAPを使用してADサーバーに対して認証します。2日前は問題なく動作していました。理由は不明ですが、昨日の時点で機能しなくなりました。エラーログはこれだけを言っています：

auth_ldap authenticate: user foo authentication failed; URI /FrontPage [LDAP: ldap_simple_bind_s() failed][Can't contact LDAP server], referer: http://mysite.com/

おそらく自己署名SSL証明書の有効期限が切れていると思ったので、mysite.com用に新しい証明書を作成しましたが、サーバーのホスト名自体には作成しなかったため、問題は解決しませんでした。デバッグレベルのロギングを有効にしました。LDAPサーバーとの完全なSSLトランザクションが表示され、「LDAPサーバーに接続できません」というメッセージが表示される最後まで、エラーなしで完了したように見えます。このサーバーのコマンドラインからldapsearchを実行し、LDAPを使用してldapsearchにログインできるため、サーバーがLDAP / ADサーバーに接続してクエリを実行できることがわかります。接続できないのはApacheだけです。

答えを求めてグーグルで調べても何も起こらないので、ここで質問します。誰かがこの問題について洞察を提供できますか？

Apache設定のLDAPセクションは次のとおりです。

<Directory "/web/wiki/">
    Order allow,deny
    Allow from all
    AuthType Basic
    AuthName "Login"
    AuthBasicProvider ldap
    AuthzLDAPAuthoritative off
    #AuthBasicAuthoritative off
    AuthLDAPUrl ldaps://domain.server.ip/dc=full,dc=context,dc=server,dc=name?sAMAccountName?sub
    AuthLDAPBindDN cn=ldapbinduser,cn=Users,dc=full,dc=context,dc=server,dc=name
    AuthLDAPBindPassword password
    require valid-user
</Directory>

httpdサーバー/ LDAPクライアントからのパケットトレースにより、不明なCAに関するメッセージが明らかになりました。

TLSv1アラート（レベル：致命的、説明：不明なCA）

次のオプションを見つけ、httpd.confに追加しました。

  LDAPVerifyServerCert          off

これにより、CentOS 6での私の問題が修正されました。CentOS5のhttpdサーバーは変更を必要とせず、オプションなしで問題なく動作していました。

以前にWindows 2003のADでこれと同様の問題がありました。解決策は、完全なDNを使用してバインドせず、代わりにuser @ domain構文を使用することでした。

AuthLDAPBindDN user@domain.com

LDAPサーバーからログにアクセスできますか？これらは、この問題のトラブルシューティングに役立つ場合があります。

これは、パッケージの更新によってクライアントのldap.conf（通常は/etc/ldap.confまたは/etc/openldap/ldap.conf）が変更され、TLS_REQCERTオプションがより厳格な設定にリセットされるときに見られました。SSLを適切にネゴシエートできますが、信頼されたルートからの証明書チェーンを検証できないため、最後に失敗します。

サーバーのクロックを確認することもできます。時間差が数分を超える場合、認証チケットは無効になります。

これは厳密にはエラーメッセージではありませんが、「他のサーバーで突然同じ問題が発生する」部分がそのような問題を示している可能性があります。

LDAPSを使用するには、LDAP CA証明書を適用する必要があります

同様の問題があり、次のコマンドを実行して特定しました。

openssl s_client -connect $ldap_host:636 -state -nbio 2>&1。mod_ldapはその下でopensslを使用していると思うので、これはデバッグのためにかなり一貫しているはずです。

動作していることがわかっている別のSSL暗号化サーバーと比較しました。適切に検証されたSSL接続は、ルートCAに行くチェーンを示し、0を返します。SSL検証の失敗は、数と理由を与えます。出力を使用して、問題の原因を判別できます。

私の場合、LDAPサーバー証明書は、中間CA証明書を使用するVerisignによって署名されています。OpenSSLは証明書を検証できず、接続は拒否されます（「サーバーによって拒否された接続」は役に立ちません）。

同様の問題がありました。opensslで証明書を取得できます。同じポートでldapsearchを使用して、SSL経由でActive Directoryにクエリを実行できます。最後に、Microsoftグローバルカタログのポート3268または3269に変更しましたが、どちらも機能しました。Microsoft Windows 2003サーバーにはパッチが適用されていましたが、問題が発生し始める数日前に起こりました。

私はすべてのサーバーにLDAPSを実装していましたが、この問題にも遭遇しました。プレーンテキストLDAPに戻した場合、それはなくなりますか（理想的ではありませんが、問題の原因を知るのに役立ちます）。もしそうなら、私はまだ解決策を見つけていませんが、おそらく一緒にauthnz_ldapのバグを分離できます。

コマンドラインの実験では、Apacheの設定と同じ「バインドユーザー」を使用していると思います。そうでない場合は、現在のパスワードが正しいことを確認する必要があります。

以前は、ADドメインの標準LDAPポートではなく、グローバルカタログポートを使用する必要がありました。理由が思い出せない。上記のURLのLDAPの場合、これはポート3269になります。

これが機能する方法は、まずバインドユーザーの資格情報を使用してWebサイトにADに接続し、次にこの接続が確立されると、このアクセスを使用してWebサイトにアクセスしようとしているユーザーの資格情報を検証することです。

エラーメッセージによると、プロセスはバインドユーザー （AuthLDAPBindDN）としてADに接続できないようです。

バインドユーザーアカウントが Active Directoryで無効になっていないこと、および（AuthLDAPBindPassword）として指定したパスワードが正しいことを確認します。また、バインドユーザーが他のユーザーを検索するために必要なアクセス許可を持っていることを確認してください（この場合、ドメインユーザーのメンバーである必要があります）

RHEL6でこの問題（「LDAPサーバーに接続できません」）が発生しましたが、それはopenldapへの変更の結果です。yumは構成ファイル/etc/openldap/ldap.confを更新しましたが、それを上書きする代わりに（カスタマイズされた場合、私の場合はそうではありませんでした）、ldap.conf.rpmnewファイルを作成しました。

.rpmnewバージョンをldap.confにコピーすると、問題が修正されました。

（私は証明書の検証をオフにすることがこれに対する答えであることには同意できません。それは潜在的に危険な方法で問題を回避します。）

ここにあるberkelydbおよびopenldapパッケージをインストールして、この問題をなんとか修正しました。

違いは、RedHatがSSLサポートのnss代わりにリンクを開始していることopensslです。この場合、それはすべてのものを壊します。これらのパッケージ（opensslにリンクされている）をインストールすると、問題が修正されます。パッケージを取得して実行するだけです：

yum install berkeleydb-ltb* openldap-ltb*

次に、Apacheを再起動してください。

rhel6.6からrhel7.5にアップグレードした後、同じ問題が発生しました。アイデアがなくなったとき、apache 2.2.32のmod_sslはrhel7.4で100％互換性がない可能性があると結論付けました。Apache 2.2.32からApache2.4にアップグレードし、SSLを有効にすると、sldapが機能しました。