non riesco a capire perché l'autenticazione LDAP di Apache fallisce

Improvvisamente, ieri, uno dei miei server apache non è stato in grado di connettersi al mio server LDAP (AD). Ho due siti in esecuzione su quel server, entrambi utilizzano LDAP per l'autenticazione con il mio server AD quando un utente accede a entrambi i siti. Funzionava bene due giorni fa. Per ragioni sconosciute, a partire da ieri, ha smesso di funzionare. Il registro degli errori dice solo questo:

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

Ho pensato che forse il mio certificato SSL autofirmato fosse scaduto, quindi ne ho creato uno nuovo per mysite.com, ma non per il nome host del server stesso, e il problema persisteva. Ho abilitato la registrazione a livello di debug. Mostra la transazione SSL completa con il server LDAP e sembra completarsi senza errori fino alla fine quando ricevo il messaggio "Impossibile contattare il server LDAP". Posso eseguire ldapsearch dalla riga di comando su questo server e posso accedere ad esso, che utilizza anche LDAP, quindi so che il server può connettersi e interrogare il server LDAP / AD. È solo Apache che non può connettersi.

Cercare su Google una risposta non ha prodotto nulla, quindi chiedo qui. Qualcuno può fornire informazioni su questo problema?

Ecco la sezione LDAP dalla configurazione di Apache:

<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>

Una traccia del pacchetto dal server httpd / client LDAP ha rivelato un messaggio sulla CA sconosciuta.

Avviso TLSv1 (Livello: fatale, Descrizione: CA sconosciuta)

Ho trovato e aggiunto la seguente opzione al mio httpd.conf:

  LDAPVerifyServerCert          off

Ciò ha risolto il mio problema con CentOS 6. I server httpd di CentOS 5 non richiedevano alcuna modifica e avevano funzionato senza l'opzione.

Ho avuto un problema simile a questo in precedenza con AD su Windows 2003: la soluzione che ho trovato è stata quella di non legare usando il DN completo ma invece usare la sintassi user @ domain:

AuthLDAPBindDN user@domain.com

Hai accesso ai registri dal tuo server LDAP? Potrebbero essere utili nella risoluzione di questo problema.

Ho visto questo quando un aggiornamento del pacchetto provoca cambiamenti nel client ldap.conf (di solito /etc/ldap.conf o /etc/openldap/ldap.conf) e reimposta l'opzione TLS_REQCERT su un'impostazione più rigorosa. Può negoziare correttamente SSL, ma non riuscirà comunque alla fine in quanto non può convalidare la catena di certificati da una radice attendibile.

Potresti voler controllare l'orologio dei server. Se la differenza oraria è superiore a un paio di minuti, il ticket di autenticazione non sarà valido.

Sebbene questo non sia esattamente il messaggio di errore, la parte "l'altro server improvvisamente ottiene lo stesso problema" potrebbe indicare tale problema.

È necessario impoert il certificato CA LDAP per funzionare con LDAPS

Ho un problema simile, che ho identificato eseguendo questo comando:

openssl s_client -connect $ldap_host:636 -state -nbio 2>&1. Penso che mod_ldap utilizzi openssl sotto, quindi questo dovrebbe essere abbastanza coerente per il debug.

L'ho confrontato con un altro server crittografato SSL che sapevo funzionasse. Una connessione SSL correttamente verificata mostrerà una catena che va a una CA principale e restituisce 0. Un errore della verifica SSL fornirà un numero e un motivo. È possibile utilizzare l'output per determinare cosa non va.

Nel mio caso, i certificati server LDAP sono firmati da Verisign, che utilizza certificati CA intermedi . OpenSSL non è in grado di verificare il certificato e la connessione viene rifiutata ("connessione rifiutata dal server" non è utile).

Ho avuto un problema simile. Potrei ottenere il certificato con openssl, potrei interrogare Active Directory su SSL con ldapsearch sulle stesse porte. Alla fine sono passato alle porte del catalogo globale Microsoft 3268 o 3269 ed entrambe hanno funzionato. I server Microsoft Windows 2003 erano stati patchati, ma ciò accadeva giorni prima che iniziassero i problemi.

Stavo implementando LDAPS su tutti i nostri server e ho riscontrato anche questo problema. Va via se ritorni a LDAP in chiaro (non ideale, ma utile per conoscere l'origine del problema). In tal caso, devo ancora trovare una soluzione, ma forse insieme possiamo isolare un bug in authnz_ldap.

Suppongo che i tuoi esperimenti da riga di comando stessero usando lo stesso "utente di bind" come nelle tue configurazioni di apache. In caso contrario, è necessario verificare di disporre della password corrente corretta.

In passato, una volta dovevo usare la porta del catalogo globale invece della porta LDAP standard per il dominio AD. Non ricordo il motivo per cui. Per ldaps come nel tuo URL sopra, questa sarebbe la porta 3269.

Il modo in cui funziona è che il tuo sito Web deve connettersi ad AD utilizzando prima le credenziali dell'utente associato , quindi, una volta stabilita questa connessione, utilizza questo accesso per convalidare le credenziali dell'utente che tenta di accedere al tuo sito Web.

Secondo il tuo messaggio di errore, sembra che il processo non sia in grado di connettersi ad AD come utente di bind (AuthLDAPBindDN).

Assicurarsi che l' account utente di bind non sia disabilitato in Active Directory e che la password specificata come (AuthLDAPBindPassword) sia corretta . Inoltre, assicurati che il tuo utente di bind disponga delle autorizzazioni necessarie per cercare altri utenti (nel nostro caso deve essere un membro di Domain Users)

Ho appena avuto questo problema ("impossibile contattare il server LDAP") su RHEL6, ed è stato il risultato di modifiche a openldap. yum aveva aggiornato il file di configurazione /etc/openldap/ldap.conf ma invece di sovrascriverlo (nel caso fosse personalizzato; nel mio caso non lo era) ha creato un file ldap.conf.rpmnew.

La copia della versione .rpmnew su ldap.conf ha risolto il problema.

(Non posso essere d'accordo sul fatto che disattivare la verifica del certificato sia una risposta a questo. Evita il problema in un modo potenzialmente pericoloso.)

Sono riuscito a risolvere questo problema installando i pacchetti berkelydbe openldaptrovati qui .

La differenza è che RedHat ha iniziato a collegare le cose nssinvece che opensslper il supporto SSL. In questo caso, ciò rompe tutte le cose. L'installazione di questi pacchetti (che sono collegati a openssl) risolve il problema. Prendi i pacchetti ed esegui:

yum install berkeleydb-ltb* openldap-ltb*

Quindi riavvia apache e dovresti essere in affari.

Ho avuto un problema identico dopo l'aggiornamento da rhel6.6 a rhel7.5. Quando ero senza idee ho concluso che mod_ssl su apache 2.2.32 potrebbe non essere compatibile al 100% su rhel7.4. Ho eseguito l'aggiornamento da Apache 2.2.32 ad Apache2.4, abilitato SSL e sldap ha funzionato.