突然、昨日、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を使用してログインすることもできるので、サーバーが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 [email protected]
同様の問題がありました。 opensslで証明書を取得できます。同じポートでldapsearchを使用して、SSL経由でActive Directoryにクエリを実行できます。最後に、Microsoftグローバルカタログのポート3268または3269に変更しましたが、どちらも機能しました。 Microsoft Windows 2003サーバーにはパッチが適用されていましたが、問題が発生し始める数日前に発生しました。
LDAPサーバーからログにアクセスできますか?これらは、この問題のトラブルシューティングに役立つ場合があります。
サーバーのクロックを確認することもできます。時間差が数分を超える場合、認証チケットは無効になります。
これは厳密にはエラーメッセージではありませんが、「他のサーバーで突然同じ問題が発生する」部分がそのような問題を示している可能性があります。
LDAPSを使用するには、LDAP CA証明書をインポートする必要があります
これは、パッケージの更新によってクライアントのldap.conf(通常は/etc/ldap.confまたは/etc/openldap/ldap.conf)が変更され、TLS_REQCERTオプションがより厳格な設定にリセットされるときに見られました。 SSLを適切にネゴシエートできますが、信頼されたルートからの証明書チェーンを検証できないため、最後に失敗します。
これが機能する方法は、Webサイトが最初にバインドユーザーの資格情報を使用してADに接続する必要があり、次にこの接続が確立されると、このアクセスを使用して、試行するユーザーの資格情報を検証しますあなたのウェブサイトにアクセスします。
エラーメッセージによると、プロセスがADに接続できないようですバインドユーザー(AuthLDAPBindDN)。
Active Directoryでバインドユーザーアカウントが無効になっていないであること、および(AuthLDAPBindPassword)として指定したパスワードが正しいであることを確認します。また、他のユーザーを検索するために、バインドユーザー必要な権限があるであることを確認してください(この場合、ドメインユーザーのメンバーである必要があります)
RHEL6でこの問題(「LDAPサーバーに接続できない」)が発生しましたが、それはopenldapへの変更の結果です。 yumは構成ファイル/etc/openldap/ldap.confを更新しましたが、それを上書きする代わりに(カスタマイズされた場合、私の場合はそうではありませんでした)、ldap.conf.rpmnewファイルを作成しました。
.rpmnewバージョンをldap.confにコピーすると、問題が修正されました。
(私は証明書の検証をオフにすることがこれに対する答えであることには同意できません。それは潜在的に危険な方法で問題を回避します。)
私はすべてのサーバーにLDAPSを実装していましたが、この問題にも遭遇しました。プレーンテキストLDAPに戻した場合、それはなくなりますか(理想的ではありませんが、問題の原因を知るのに役立ちます)。もしそうなら、私はまだ解決策を見つけていませんが、おそらく一緒にauthnz_ldapのバグを分離できます。
同様の問題があり、次のコマンドを実行して特定しました。
openssl s_client -connect $ldap_Host:636 -state -nbio 2>&1
。私はmod_ldapがその下でopensslを使用していると思うので、これはデバッグに対してかなり一貫しているはずです。
動作していることがわかっている別のSSL暗号化サーバーと比較しました。適切に検証されたSSL接続は、ルートCAに行くチェーンを示し、0を返します。SSL検証の失敗は、数と理由を与えます。出力を使用して、問題の原因を特定できます。
私の場合、LDAPサーバー証明書はVerisignによって署名されており、Verisignは Intermediate CA certs を使用しています。 OpenSSLは証明書を検証できず、接続は拒否されます(「サーバーによって拒否された接続」は役に立ちません)。
見つかったberkelydb
およびopenldap
パッケージをインストールすることで、この問題をなんとか解決しました here 。
違いは、RedHatがSSLサポートのためにnss
ではなくopenssl
に対してリンクを開始していることです。この場合、それはすべてのものを壊します。これらのパッケージ(opensslにリンクされている)をインストールすると、問題が修正されます。パッケージを取得して実行するだけです:
yum install berkeleydb-ltb* openldap-ltb*
次に、Apacheを再起動してください。
コマンドラインの実験では、Apacheの設定と同じ「バインドユーザー」を使用していると思います。そうでない場合は、現在のパスワードが正しいことを確認する必要があります。
以前は、ADドメインの標準LDAPポートではなく、グローバルカタログポートを使用する必要がありました。理由が思い出せない。上記のURLのLDAPの場合、これはポート3269になります。