> Pierangelo Masarati wrote:
> /usr/local/etc/openldap/ldap.conf: > > base dc=test,dc=org > uri ldaps://ferret.tomato.lan:636 > bind_policy soft ^^^ Questa direttiva non e' riconosciuta da OpenLDAP, meglio toglierla > > TLS_REQCERT never > TLS_CERT /usr/local/etc/openldap/ldap.client.pem > TLS_KEY /usr/local/etc/openldap/ldap.client.key.pem ^^^ queste due direttive sono ignorate, in quanto sono "user only" (come indicato in ldap.conf(5) di OpenLDAP), mentre questo e' il file di sistema. Non ha senso mettere una chiave privata in un file che e' leggibile globalmente. La chiave privata puo' solo essere definita nel file specifico di un utente (o di un'applicazione, come nel pam_ldap). > TLS_CACERT /usr/local/etc/openldap/cacert.pem > #TLS_CIPHER_SUITE HIGH:MEDIUM:+SSLv2 > > [EMAIL PROTECTED]:~ >ps -auxww | grep slapd > ldap 17893 0.0 1.4 45940 35800 p4 S+ 4:30PM 0:00.78 > usr/local/libexec/slapd -h ldapi://%2fvar%2frun%2fopenldap%2fldapi/ > ldap:/// ldaps:/// -s-1 -d256 -u ldap -g ldap > [EMAIL PROTECTED]:~ >ldapsearch -b "dc=test,dc=org" Ti faccio notare che l'esecuzione di questo comando, data la configurazione che hai mostrato, non prevede nessuna validazione, da parte del server, del certificato del client (in quanto, avendo messp TLS_CERT/TLS_KEY nell'ldap.conf di sistema, e' come non averli messi affatto; d'altra parte, il server e' stato configurato per non verificare il certificato del client. Allo stesso modo, il client non verifica il certificato del server (anche se potrebbe, e dovrebbe!) in quanto TLS_REQCERT e' "never". > Da questo deduco che: > -ldaps/certificati funzionano > -il server e' configurato correttamnente per ricevere > richieste da eventuali client > > Ora pero' il mio problema si e' spostato sui client (ad esempio pam/nss) > i quali non ne vogliono > sapere di funzionare su ldaps: > > /usr/local/etc/ldap.conf - /usr/local/etc/nss_ldap.conf: > > base dc=test,dc=org > #uri ldaps://ferret.tomato.lan:636 > uri ldap://ferret.tomato.lan > bind_policy soft > > sudoers_base ou=SUDOers,dc=test,dc=org > pam_groupdn cn=smtp_box,ou=groups,dc=test,dc=org > pam_member_attribute memberUid Questo attributo e' invalido; ho verificato la documentazione del pam_ldap e in effetti e' ambigua, ma ti assicuro (dalla lettura del codice) che il confronto per l'appartenenza ai gruppi avviene tra i valori di pam_member_attribute e il DN della entry dello user, mentre memberUid e' un numero, non un DN, quindi la richiesta fallisce sicuramente. > > tls_checkpeer no > tls_cacertfile /usr/local/etc/openldap/cacert.pem > tls_cert /usr/local/etc/openldap/ldap.client.pem > tls_key /usr/local/etc/openldap/ldap.client.key.pem In questo caso, si tratta del file di un'applicazione e non di quello di sistema; credo di capire che l'applicazione, quindi, essendo configurata con tls_cert, tls_key, in ogni caso manda il proprio certificato al server, anche se questo poi e' configurato per non verificarla... > > utilizzando la 389 ssh funziona correttamnente e mi posso collegare con > utente testuser e/o utilizzando l'utente definito sulla mia macchina in > /etc/passwd. > Al contrario, se decommento la riga "#uri ldaps://ferret.tomato.lan:636" > nel file sopra citato, ssh smette di funzionare in tutti i sensi: > > [EMAIL PROTECTED]:~ >ssh [EMAIL PROTECTED] > Connection closed by 127.0.0.1 > [EMAIL PROTECTED]:~ > > > slapd log: > > conn=41 fd=14 ACCEPT from IP=192.168.1.19:58542 (IP=0.0.0.0:636) > TLS: can't accept. > conn=41 fd=14 closed (TLS negotiation failure) > > medesima cosa accade se configuro phpldapadmin per usare ldaps al posto > di ldap: > > phpldapadmin: > > *Could not connect to "ldaps://ferret.tomato.lan" on port "636"* > > *Backtrace* > *PHP Version* 5.2.3 > *PLA Version* 1.0.2 > *PHP SAPI* apache2handler > *Web Server* Apache/2.2.4 (FreeBSD) DAV/2 PHP/5.2.3 with > Suhosin-Patch mod_ssl/2.2.4 OpenSSL/0.9.8e > > *File* /usr/local/www/phpldapadmin/lib/server_functions.php (353) > *Function* pla_error > > Array > ( > [0] => Could not connect to "ldaps://ferret.tomato.lan" on port "636" > ) > > > *File* /usr/local/www/phpldapadmin/htdocs/login.php (125) > *Function* connect > > Array > ( > [0] => 1 > [1] => user > [2] => 1 > ) > > > > log slapd: > > conn=47 fd=14 ACCEPT from IP=192.168.1.19:63045 (IP=0.0.0.0:636) > TLS: can't accept. > TLS: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca > s3_pkt.c:1053 > conn=47 fd=14 closed (TLS negotiation failure) ... e il server si lamenta perche' la CA che ha firmato il certificato del client e' sconosciuta. Quindi, il test che fai con ldapsearch non e' rappresentativo della condizione in cui opera pam_ldap, e quindi non ci dice nulla sul reale comportamento del sistema. Suggerisco di rimuovere completamente la configurazione TLS da pam_ldap (al limite, lascia "tls_checkpeer no") e di mettere solo "ldaps://...". Tieni presente che il livello di sicurezza di questa configurazione e' minimo. Oppure (consigliato), richiedi la verifica dei certificati da entrambi i lati, in modo da verificare che tutto sia configurato correttamente usando strumenti semplici come ldapsearch. > Infine, se la lista e' dedicata esclusivamente ad OpenLDAP (come la > controparte 'ufficiale') mi scuso anticipatamente dell'OT, > ma pensavo che qualcuno di voi si fosse gia' imbattuto in problemi > simili e quindi ho pensato di chiedere lo stesso. La lista E' DEDICATA ESCLUSIVAMENTE AD OPENLDAP, come chiaramente indicato nella pagina di iscrizione: Questa lista rappresenta un forum di discussione sull'uso del software OpenLDAP in italiano In genere, discussione sull'uso di software che interagisce piu' o meno con OpenLDAP sono tollerate o addirittura auspicate, tanto piu' quanto piu' la relazione con OpenLDAP e' stretta. Questo non per intolleranza o altro, ma per il semplice motivo che una lista tuttologa e' destinata a fallire (come provato empiricamente in innumerevoli casi; l'ultimo in ordine di tempo, la tanto sbandierata ldap-interop), perche' catalizza solo domande talmente generiche da non essere di alcun interesse, mentre i tuttologi in grado di fornire aiuto su tutto sono rari e spesso non hanno tempo per cose banali. La scelta di focalizzarci su OpenLDAP e' legata al fatto che in SysNet riteniamo di avere una competenza superiore alla norma (= che va oltre aver letto la man page) in questo particolare strumento. Qusto non implica automaticamente una competenza superiore alla norma su tutto cio' che sfiora OpenLDAP, o addirittura LDAP. Ciao, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: [EMAIL PROTECTED] --------------------------------------- _______________________________________________ OpenLDAP mailing list [email protected] https://www.sys-net.it/mailman/listinfo/openldap
