>> 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)
Quello che intendo dire e' che i files
/usr/local/etc/ldap.conf
/usr/local/etc/nss_ldap.conf
nonostante abbiano LDAP nel nome non hanno molto a che fare con OpenLDAP;
sono i files di configurazione di due client che usano 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
>
>
>>> 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
Peccato che la sintassi di memberUid non consenta di inserirvi un DN. E'
questo che intendo. Il client pam_ldap si aspetta di trovarvi un DN, ma
quell'attributo e' parte della classe posixGroup e in genere contiene
l'uid degli utenti POSIX che fanno parte di un gruppo; per intenderci, le
informazioni che troveresti in /etc/group
> 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?
Non sto dicendo questo. Sto dicendo che se un client usa come tecnica di
configurazione la delega a libldap attraverso il meccanismo del file
.ldaprc, e se gli si chiede di verificare il certificato del server, devi
anche dirgli dove sta il certificato della CA, altrimenti come fa a
verificarlo?
Per quanto riguarda invece l'autenticazione via PAM (pam_ldap), il client
LDAP non gira ovviamente con l'identita' dell'utente che ancora deve
identificare, e comunque prende la sua configurazione dal suo proprio file
ldap.conf menzionato in precedenza. Anche in questo caso, se vuoi che
verifichi il certificato del server, devi dirgli dove sta il certificato
della CA che ha emesso quello del server. Se invece il server ha un
certificato self-signed non e' possibile verificarlo (ecco perche' e' male
usare certificati self-signed), ma a questo punto e' altrettanto sbagliato
chiedere al client di verificarlo e di fallire se non ci riesce
("TLS_REQCERT demand").
>
>>> 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...
La CA te la puoi fare con openssl. Il punto non e' "ufficiale", e'
piuttosto "sicurezza" / "no sicurezza". E' chiaro che se ti fai la CA
stai aggiungendo uno strato, ma ti stai anche difendendo da
man-in-the-middle, sia pure interni. Un server con certificato
self-signed ti da' solo la certezza che nessun altro potra' leggere quello
che passa sul cavo, ma non ti da' la certezza di parlare col server
giusto. Se questo ti sembra paranoia (e a volte lo e') allora fai tutto
in chiaro, tanto vale.
>
>>> [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...
Sono d'accordo. Ma OpenLDAP e' il mattone piu' in basso di tutto (beh,
OpenSSL, Berkeley DB e Cyrus SASL stanno sotto...) E' come chiedere al
muratore che costruisce il muro di fornirti il manuale di funzionamento
del condizionatore che verra' appeso a quel muro...
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
