> Salve lista,
>
> mi trovo a "combattere" per la prima volta OpenLDAP, e benche'
> alcuni problemi iniziali sono riuscito ad ottenere una
> installazione funzionante con tanto di OpenLDAP 2.3.x, nss_ldap,
> pam_ldap, etcetc.
>
> Ora, l'ultimo problema in cui mi sono imbattuto (e da cui
> non sono ancora riuscito a venirne fuori) riguarda la configurazione
> sicura di LDAP in modo che i dati non viaggino in chiaro sulla rete.
> Leggendo in giro, mi e' smebrato di capire che dalla versione 2.3,
> SSL/TLS faccia parte del sistema base
In realta' dalla 2.0
> e quindi mi sono lanciato nella
> configurazione.
>
> Seguendo diversi documenti [1, 2] ho creato la CA ed i certificati
> necessari, e sono giunto alla seguente configurazione:
>
> slapd.conf:
> -----------
> include /usr/local/etc/openldap/schema/core.schema
> include /usr/local/etc/openldap/schema/cosine.schema
> include /usr/local/etc/openldap/schema/nis.schema
> include /usr/local/etc/openldap/schema/inetorgperson.schema
> include /usr/local/etc/openldap/schema/openldap.schema
> include /usr/local/etc/openldap/schema/sudo.schema
> pidfile /var/run/openldap/slapd.pid
> argsfile /var/run/openldap/slapd.args
>
> modulepath /usr/local/libexec/openldap
> moduleload back_bdb
>
> database bdb
> suffix "dc=test,dc=org"
> rootdn "cn=Manager,dc=test,dc=org"
> rootpw {SSHA}FNoRa4/LVSCsUBLKz6LQjLcayzvMfOw/
> directory /var/db/openldap-data
> index objectClass eq
> index uid pres,eq,sub
>
> TLSCipherSuite HIGH:MEDIUM:+SSLv2
> TLSVerifyClient allow
> TLSCACertificateFile /usr/local/etc/openldap/cacert.pem
> TLSCertificateFile /usr/local/etc/openldap/servercrt.pem
> TLSCertificateKeyFile /usr/local/etc/openldap/serverkey.pem
>
> #access to *
> #by self write
> #by users read
> #by anonymous auth
>
Il file ldap.conf qui sotto si riferisce a PAM/NSS, non ha niente a che
fare con OpenLDAP, se non che PAM/NSS agiscono come client del server
OpenLDAP; ma la libreria libldap di OpenLDAP non prende la sua
configurazione da qui.
> ldap.conf:
> ----------
> base dc=test,dc=org
> host ferret.tomato.lan
> sudoers_base ou=SUDOers,dc=test,dc=org
> #uri ldap://127.0.0.1/
> #uri ldaps://tomato.ferret.lan:636/
>
> #ssl start_tls
> #ssl on
>
> pam_groupdn cn=smtp_box,ou=groups,dc=test,dc=org
> pam_member_attribute memberUid
^^^ questo in ogni caso e' sbagliato e prima o poi ci sbatterai la testa;
infatti il pam_member_attribute deve essere un attributo con la sintassi
di un DN (il fatto che di solito lo si faccia puntare a uniqueMember, che
solo per caso ha una sintassi che assomiglia a un DN, e' un altro
discorso). Quindi memberUid non funziona.
>
> TLS_CACERT /usr/local/etc/openldap/cacert.pem
> TLS_REQCERT demand
^^^ attenzione: questo significa che il client verifichera' il certificato
del server usando il certificato della CA fornito dalla riga sopra, e se
la verifica fallisce la connessione verra' rifiutata. Tutto cio' e bene:
e' esattamente come il TLS andrebbe usato perche' sia sicuro, ma occorre
verificare che funzioni correttamente; vedi sotto.
>
> .ldaprc:
> --------
>
> TLS_REQCERT demand
>
> TLS_CERT /usr/local/etc/openldap/ldap.client.pem
> TLS_KEY /usr/local/etc/openldap/ldap.client.key.pem
"TLS_REQCERT demand" richiede TLS_CACERT...
>
> e le seguenti operazioni mi confermano la bonta' dei ceritifati:
> [EMAIL PROTECTED]:~ >openssl s_client -connect localhost:636 -showcerts
> CONNECTED(00000003)
> depth=1 /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=tomato
> verify error:num=19:self signed certificate in certificate chain
> verify return:0
^^^ questo non va molto bene: c'e' un self-signed nel loop...
> ---
> Certificate chain
> 0 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=ferret.tomato.lan
> i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=tomato
> -----BEGIN CERTIFICATE-----
> [snip]
> Server certificate
> subject=/C=AU/ST=Some-State/O=Internet Widgits Pty
> Ltd/CN=ferret.tomato.lan
> issuer=/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=tomato
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 1522 bytes and written 334 bytes
> ---
> New, TLSv1/SSLv3, Cipher is AES256-SHA
> Server public key is 1024 bit
> Compression: NONE
> Expansion: NONE
> SSL-Session:
> Protocol : TLSv1
> Cipher : AES256-SHA
> Session-ID:
> F4645ED5B23897FD1464F719ABDE826D23B4F9CB4A95F2D1E4E982D046495191
> Session-ID-ctx:
> Master-Key:
> DD9DC50738F62B531055B4714A7F0F1A6DEFB0148DEF7E402F618FFB9DED94CA4C994D3BC00A02C52930FB65F703020F
> Key-Arg : None
> Start Time: 1186136473
> Timeout : 300 (sec)
> Verify return code: 19 (self signed certificate in certificate chain)
> ---
> ^C
>
> [EMAIL PROTECTED]:~ >openssl s_client -connect localhost:636 -showcerts -state
> -CAfile /usr/local/etc/openldap/cacert.pem
> CONNECTED(00000003)
> SSL_connect:before/connect initialization
> SSL_connect:SSLv2/v3 write client hello A
> SSL_connect:SSLv3 read server hello A
> depth=1 /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=tomato
> verify return:1
> depth=0 /C=AU/ST=Some-State/O=Internet Widgits Pty
> Ltd/CN=ferret.tomato.lan
> [snip]
> Server certificate
> subject=/C=AU/ST=Some-State/O=Internet Widgits Pty
> Ltd/CN=ferret.tomato.lan
> issuer=/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=tomato
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 1522 bytes and written 334 bytes
> ---
> New, TLSv1/SSLv3, Cipher is AES256-SHA
> Server public key is 1024 bit
> Compression: NONE
> Expansion: NONE
> SSL-Session:
> Protocol : TLSv1
> Cipher : AES256-SHA
> Session-ID:
> AC753A13D306C5A3AA23F72F371D2AA9904D49A3ECB5F264352945DD3CC7EEA1
> Session-ID-ctx:
> Master-Key:
> 538C4302A4D6404755CE71DAC1886E4F7B7BF6AD993A467682E94663E4FE43A1A8CEDCF50ACF7FDEB0A0E97B668B0F0B
> Key-Arg : None
> Start Time: 1186136589
> Timeout : 300 (sec)
> Verify return code: 0 (ok)
>
> [EMAIL PROTECTED]:~ >openssl s_client -connect ferret.tomato.lan:636 -state
> -CAfile /usr/local/etc/openldap/cacert.pem -cert
> /usr/local/etc/openldap/ldap.client.pem -key
> /usr/local/etc/openldap/ldap.client.key.pem
> CONNECTED(00000003)
> SSL_connect:before/connect initialization
> SSL_connect:SSLv2/v3 write client hello A
> SSL_connect:SSLv3 read server hello A
> depth=1 /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=tomato
> verify return:1
> depth=0 /C=AU/ST=Some-State/O=Internet Widgits Pty
> Ltd/CN=ferret.tomato.lan
> verify return:1
> [snip]
> subject=/C=AU/ST=Some-State/O=Internet Widgits Pty
> Ltd/CN=ferret.tomato.lan
> issuer=/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=tomato
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 1522 bytes and written 334 bytes
> ---
> New, TLSv1/SSLv3, Cipher is AES256-SHA
> Server public key is 1024 bit
> Compression: NONE
> Expansion: NONE
> SSL-Session:
> Protocol : TLSv1
> Cipher : AES256-SHA
> Session-ID:
> 9CC2E8AC144052EFCB750321FC93B6F98A5CAEB2FD3CEBA25668BDB04D8CC6A8
> Session-ID-ctx:
> Master-Key:
> 0D8C62B1FFCC81F6D9424ABBC950899BABD8DFCCF7EB2D3ACDD8FA8C41B35B0B7B5E4F5785C1D1535598BE8D3C5A6AAE
> Key-Arg : None
> Start Time: 1186136718
> Timeout : 300 (sec)
> Verify return code: 0 (ok)
>
> pero' quando cerco utilizzare ldapsearch per una richiesta, c'e' qualcosa
> che nn va:
> [EMAIL PROTECTED]:~ >ldapsearch -H ldaps://localhost:636 -b 'dc=test,dc=org'
> '(objectclass=*)'
> ldap_bind: Can't contact LDAP server (-1)
> additional info: error:14090086:SSL
> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Qui contatti il server come ldaps://localhost:636, quindi risponde
sull'interfaccia localhost; ma il certificato e' per ferret.tomato.lan;
quindi la verifica fallisce. O contatti il server come ferret.tomato.lan,
oppure metti come subJectAtlName localhost (cosa non tanto carina...)
>
> mentre la versione 'liscia' funziona:
>
> [EMAIL PROTECTED]:~ >ldapsearch -LL -H ldap://localhost:389 -b
> 'dc=test,dc=org' '(objectclass=*)'
> version: 1
>
> dn: dc=test,dc=org
> dc: test
> objectClass: top
> objectClass: domain
> objectClass: domainRelatedObject
> associatedDomain: test.org
>
> dn: ou=groups,dc=test,dc=org
> objectClass: top
> objectClass: organizationalUnit
> ou: groups
> [snip]
>
> Alcune info riguardo la mia macchina ed il mio utente:
>
> [EMAIL PROTECTED]:~ >id
> uid=1001(piso) gid=1001(piso) groups=1001(piso),0(wheel)
>
> [EMAIL PROTECTED]:~ >uname -a
> FreeBSD ferret.tomato.lan 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Mon Jul 23
> 18:03:21 CEST 2007
> [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FERRET i386
>
> [EMAIL PROTECTED]:~ >grep ferret /etc/ho
> host.conf hostid hosts hosts.allow hosts.equiv
> hosts.lpd
>
> [EMAIL PROTECTED]:~ >grep ferret /etc/hosts
> 192.168.1.19 ferret.tomato.lan ferret
>
> [EMAIL PROTECTED]:~ >ps -auxww | grep slap
> ldap 57930 0.0 1.4 45948 35416 ?? Is 11:40AM 0:01.03
> /usr/local/libexec/slapd -h ldapi://%2fvar%2frun%2fopenldap%2fldapi/
> ldap:/// ldaps:/// -s-1 -u ldap -g ldap
>
> Lo step successivo consisnte nell'"autenticare" alcuni client (sshd nel
> mio caso) attraverso ldap: allo stato attuale questo mi riesce ma solo
> utilizzando
> traffico in chiaro, e con l'attivazione di SSL/TSL spero di chiudere
> quest'ultima falla cosi' da poter mandare in produzione la mia prima
> installazione LDAP :)
>
> bye,
> P.
>
> [1]: http://www.openldap.org/faq/data/cache/185.html
> [2]: http://www.openldap.org/pub/ksoper/OpenLDAP_TLS.html
^^^ [2] e' vecchiotto e contiene qualche inesattezza; [1] e' anch'esso
vecchiotto, ed e' stato trasferito, riveduto aggiornato e corretto nella
documentazione: <http://www.openldap.org/doc/admin23/tls.html>. La
tradizione vuole che la documentazione di OpenLDAP sia carente e
incompleta; magari in passato questo era vero, ma ora secondo me non e'
piu' cosi': e' completa e accurata (=senza errori, inutili fronzoli,
imprecisioni, divagazioni, ...).
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
