Ho riletto la pagina man di slapd.access ma non mi sembra che si possa
usare le netmask con sockurl. Sbaglio?
Ho comunque pensato ad una proposta:
supponendo di avere due macchine A e B con indirizzo pubblico
$PUBLIC_NAME_A e $PUBLIC_NAME_B passerei dalla seguente ACL sulla
macchina A:
access to *
by sockurl="ldap://$PUBLIC_NAME_A"; ssf=128 break
by sockurl="ldap://$PUBLIC_NAME_A"; stop
by * break
alla seguente (sempre sulla macchina A):
access to *
by sockurl="ldap://$PUBLIC_NAME_A"; ssf=128 break
by sockurl="ldap://$PUBLIC_NAME_A"; stop
by sockurl="ldap://$PUBLIC_NAME_B"; ssf=128 break
by sockurl="ldap://$PUBLIC_NAME_B"; stop
by * break
E similmente sulla macchina B.
E questo non dovrebbe dare problemi, il problema reale è che comunque
devo specificare tramite il parametro -h le socket in cui stare in
ascolto. Dai miei esperimenti non posso aprire una socket su un ip non
appartenete alla macchina. Quindi siamo punto e a capo: devo riavviare
il demone slapd in A nel caso in cui la macchina B smetta di funzionare
con l'aggiunta del parametro "-h ldap://$PUBLIC_NAME_A $PUBLIC_NAME_B"
con buona pace del failover resilente. :-(
C'è un motivo tecnico per cui si deve per forza specificare l'indirizzo
presente nelle ACL che hanno sockurl nella parte <who> della regola come
parametro d'avvio del demone?
Non si può aggirare questo vincolo in nessun modo?
Grazie a tutti.
Michele
Il giorno sab, 02/02/2008 alle 15.17 +0100, Pierangelo Masarati ha
scritto:
> Michele Codutti wrote:
> > Ciao a tutti mi sto scervellando per trovare una soluzione ottimale per
> > imporre connessioni cifrate di tipo tls o ssl per il servizio ldap.
> > Qualche mese fa ho postato una mail chiedendo come poter imporre questa
> > cosa tramite la configurazione del demone ldap. Il risultato è una serie
> > di ACL che devono essere utilizzate da slapd in cui bisogna specificare
> > delle socket sulle quali il demone è in ascolto ed in più bisogna
> > aggiungere quelle socket al parametro -h all'avvio del demone.
> > Tutto è documentato a questo indirizzo:
> > http://www.sys-net.it/pipermail/openldap/2007-September/000736.html
> > Ora, nella mia configurazione vorrei gestire slapd con heartbeat e per
> > questo motivo gli indirizzi ip potrebbero non essere fissati a priori e
> > migrare sulle macchine del cluster (a causa dei come vangono gestite le
> > risorse da heartbeat). Il problema è che con le ACL devo sapere a priori
> > l'indirizzo dell'interfaccia su cui voglio mettere slapd in ascolto
> > altrimenti non parte. Ho provato ad inserire uno strato di software in
> > più che si occupi solo della crittografia in modo da separare l'ssl/tls
> > dal servizio ldap. L'unico software che io conosca che possa fare una
> > cosa del genere è stunnel <http://stunnel.mirt.net/>, il quale è capace
> > di instaurare delle connessioni ssl/tls rimandndo in ascolto su una
> > porta e redirigere il traffico non crittografato verso un altra
> > porta/indirizzo.
> > Stunnel funziona bene con ssl ma non va con tls.
> > Qualcuno ha mai provato l'accoppiata openldap+stunnel?
> > Qualcuno è mai riuscito a far funzionare il tls con stunnel?
>
> Se il problema e' avere ACL basate su gruppi di IP, puoi usare la forma
> con netmask, in modo che IP con le stesse prerogative siano
> selezionabili a gruppi in questo modo. Per dettagli, slapd.access(5).
>
> 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
