Re: [OpenLDAP] OpenLDAP + stunnel
Il giorno gio, 07/02/2008 alle 22.48 +0100, Pierangelo Masarati ha scritto: Michele Codutti wrote: Ho riletto la pagina man di slapd.access ma non mi sembra che si possa usare le netmask con sockurl. Sbaglio? Infatti, pensavo a peername. Quindi, supponendo che la sotto-rete privata dei due server sia 10.0.0.0/8, per imporre l'accesso SSL a tutti gli IP tranne quelli della sotto-rete privata posso scrivere la seguente ACL: access to * by ! peername.ip=10.0.0.0%255.0.0.0 ssf=128 break by ! peername.ip=10.0.0.0%255.0.0.0 stop by * break No vero? 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. esatto. 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? Quello che chiami vincolo in realta' corrisponde al fatto che il daemon, in avvio, si mette in ascolto su quelle interfacce. Se non esistono, non puo' farlo. Sono perfettamente conscio che non posso fare un bind su un IP non configurato. Il vincolo che intendevo è che non posso fare delle ACL che contengano un sockurl che non sia specificato nel parametro d'avvio -h di slapd. Il problema di base è che se aggiungo un IP sulla macchina devo per forza riavviare il server slapd con il parametro -h aggiornato per fare in modo che la regola ACL abbia effetto. E' proprio questa cosa che sto cercando di evitare. ___ OpenLDAP mailing list OpenLDAP@sys-net.it https://www.sys-net.it/mailman/listinfo/openldap
Re: [OpenLDAP] OpenLDAP + stunnel
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 OpenLDAP@sys-net.it https://www.sys-net.it/mailman/listinfo/openldap
Re: [OpenLDAP] OpenLDAP + stunnel
Michele Codutti wrote: Ho riletto la pagina man di slapd.access ma non mi sembra che si possa usare le netmask con sockurl. Sbaglio? Infatti, pensavo a peername. 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. esatto. 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? Quello che chiami vincolo in realta' corrisponde al fatto che il daemon, in avvio, si mette in ascolto su quelle interfacce. Se non esistono, non puo' farlo. 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 OpenLDAP@sys-net.it https://www.sys-net.it/mailman/listinfo/openldap
Re: [OpenLDAP] OpenLDAP + stunnel
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 OpenLDAP@sys-net.it https://www.sys-net.it/mailman/listinfo/openldap
[OpenLDAP] OpenLDAP + stunnel
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? Grazie ___ OpenLDAP mailing list OpenLDAP@sys-net.it https://www.sys-net.it/mailman/listinfo/openldap
