Pierangelo Masarati wrote:
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.
uhmmm.. se ti riferisci alle direttive TLS*, quelle le ho inserite io a
mano prendendo spunto dai vari
esempi che si trovano in giro.
Il server ldap fa riferimento al file sldapd.conf in
/usr/local/etc/openldap:
[EMAIL PROTECTED]:~ >pkg_info -L openldap-server-2.3.37 | grep slapd.conf
/usr/local/etc/openldap/slapd.conf.default
che e' proprio quello di cui si parlava poco sopra.
Il port di pam_ldap fa riferimento al file ldap.conf:
[EMAIL PROTECTED]:~ >pkg_info -L pam_ldap-1.8.2
Information for pam_ldap-1.8.2:
Files:
/usr/local/man/man5/pam_ldap.5.gz
/usr/local/etc/ldap.conf.dist
/usr/local/lib/pam_ldap.so
mentre nss_ldap punta ad nss_ldap.conf:
[EMAIL PROTECTED]:~ >pkg_info -L nss_ldap-1.255
Information for nss_ldap-1.255:
Files:
/usr/local/etc/nss_ldap.conf.sample
/usr/local/lib/nss_ldap.so.1
/usr/local/man/man5/nss_ldap.5.gz
Quindi nel mio caso ho 3 file di configurazione:
/usr/local/etc/openldap/slapd.conf (server ldap)
/usr/local/etc/ldap.conf (pam_ldap e client)
/usr/local/etc/nss_ldap.conf (nss_ldap)
e dato che ldap.conf e nss_ldap.conf mi sembravano dover contenere la
medesima configurazione,
li ho linkati:
[EMAIL PROTECTED]:~ >ls -i /usr/local/etc/ | grep ldap
6627174 ldap.conf
6627160 ldap.conf.dist
6627174 nss_ldap.conf
6627156 nss_ldap.conf.sample
6811146 openldap
Inoltre, quando ho compilato il server LDAP ho abilitato SASL e poer
questo ho installato i client
con supporto sasl:
[EMAIL PROTECTED]:~ >pkg_info | grep ldap
nss_ldap-1.255 RFC 2307 NSS module
openldap-sasl-client-2.3.37 Open source LDAP client implementation with
SASL2 support
openldap-server-2.3.37 Open source LDAP server implementation
pam_ldap-1.8.2 A pam module for authenticating with LDAP
php5-ldap-5.2.3_1 The ldap shared extension for php
phpldapadmin-1.0.2,1 A set of PHP-scripts to administer LDAP over the web
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.
cercavo un modo per abilitare (o meno) l'accesso a certe macchine per
certi utenti e, guardando in giro,
mi sono imbattuto in pam_goupdn:
da quello che ho capito, con "pam_groupdn" si specifica una entita'[*]
in LDAP, nel cui attributo 'memberUid'
si specifica il DN di tutti gli utenti che appartengono a tale entita',
i quali riceveranno risposta positiva durante
la fase di controllo dell'account quando cercheranno di accedere ad un
client LDAP che utilizza PAM.
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...
intendi dire che devo utilizzare TLS_CACERT anche in .ldaprc?
Inoltre, nel caso fosse necessario questo file .ldaprc nella dir di tutti
gli utenti che si autenticano in LDAP tramite TLS, cosa dovrei fare
per crittare il traffico che si scambiano sshd e il server? Girando come
utente root sshd, devo forse creare un file .ldaprc e piazzarlo nella home
di root?
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...
e' fatale od e' solo un warning? dovendo utilizzare LDAP all'interno di
una rete privata non mi va proprio di pagare
una CA ufficiale...
[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...)
hai ragione, non mi ero accorto della cosa...
[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, ...).
beh, se debbo essere sincero, se ci fosse stata una guida che
contemplasse l'integrazione di LDAP, pam, nss, TLS/SSL, etcetc
ci avrei messo molto meno tempo e magari avrei capito meglio diversi
punti che tutt'ora mi rimangono oscuri...
Comunque per ora vi ringrazio, ci risentiamo dopo il 15 Agosto quando
ricomincero' a fare esperimenti con LDAP... :)
bye,
P.
[*]: e passatemi anche la licenza poetica, in quanto non conosco ancora
la terminologia esatta utilizzata in LDAP... :)
_______________________________________________
OpenLDAP mailing list
OpenLDAP@sys-net.it
https://www.sys-net.it/mailman/listinfo/openldap
