[OpenLDAP] Replicazione Syncrepl con deltasync e TLS

[Michele Codutti]

Salve a tutti, sto implementando un sevizio LDAP ridondante tramite
l'utilizzo di OpenLDAP in configurazione syncrepl. I client del sistema
si collegano sulle interfacce pubbliche dei server mentre il flusso di
replicazione e di chaining passa attraverso una rete privata che
interconnette i server. Desiderando imporre la cifratura del traffico
ldap ho imposto la direttiva:
security ssf=128
Questo però ha implicato la configurazione di TLS anche per syncrepl ed
i meccanismi di chaining.
Ho provato a studiare una soluzione tramite le ACL con l'utilizzo di ssf
ma non mi sembra che possano aiutarmi.
Ora: mi piacerebbe imporre la cifratura TLS solo sulle interfacce
esterne e non su quelle interne utilizzate per il syncrepl ed il
chaining. Ho un vincolo: non posso utilizzare LDAPS e quindi la porta
636 (e trasmissioni non cifrate ovviamente), solo TLS sulla 389.
Non esiste una variante della direttiva security che imponga una
cifratura solo su determinati IP/interfacce?


___
OpenLDAP mailing list
OpenLDAP@sys-net.it
https://www.sys-net.it/mailman/listinfo/openldap

[OpenLDAP] Ringraziamenti e informazioni su seminari/corsi

[Michele Codutti]

Volevo ringraziare Pierangelo per l'aiuto risolutivo al mio problema
relativo alle interfacce pubbliche/private e le politiche TLS ad esse
associate. Al più presto aprirò un bug con la feature request.
Nel frattempo vi ricontatto per avere informazioni relativamente a corsi
e seminari su OpenLDAP in Italia. Ce ne saranno nell'immediato futuro???

Grazie a tutti.
Michele





___
OpenLDAP mailing list
OpenLDAP@sys-net.it
https://www.sys-net.it/mailman/listinfo/openldap

Re: [OpenLDAP] Ringraziamenti e informazioni su seminari/corsi

[Michele Codutti]

Perfetto. Il programma del corso su OpenLDAP e simile a quello
illustrato nel documento relativo al corso del 5/6 aprile 2005?
Altrimenti è possibile avere un quadro più chiaro del corso attuale?

Il giorno mar, 02/10/2007 alle 14.23 +0200, Luca Scamoni ha scritto:
> Michele Codutti wrote:
> > Volevo ringraziare Pierangelo per l'aiuto risolutivo al mio problema
> > relativo alle interfacce pubbliche/private e le politiche TLS ad esse
> > associate. Al più presto aprirò un bug con la feature request.
> > Nel frattempo vi ricontatto per avere informazioni relativamente a corsi
> > e seminari su OpenLDAP in Italia. Ce ne saranno nell'immediato futuro???
> >
> > Grazie a tutti.
> > Michele
> >   
> certamente. come SysNet teniamo regolarmente corsi di OpenLDAP.
> all'URL
> http://www.sys-net.it/index.php?status=notizie&id=25
> e' possibile scaricare il calendario corsi
> ovviamente e' possibile organizzare anche corsi su richiesta in date 
> differenti
> 
> 
> 
> Ing. Luca Scamoni
> Responsabile Ricerca e Sviluppo
> 
> SysNet s.r.l.
> via Dossi, 8 - 27100 Pavia - ITALIA
> http://www.sys-net.it
> ---
> Office:  +39 0382 573859 (137)
> Mobile:  +39 347 1014425
> Email:   [EMAIL PROTECTED]
> ---
> 
> 
> 





___
OpenLDAP mailing list
OpenLDAP@sys-net.it
https://www.sys-net.it/mailman/listinfo/openldap

[OpenLDAP] Anomalia con TLS.

[Michele Codutti]

Ciao a tutti, è da qualche giorno che è in fase di testing avanzato la
struttura di directory che abbiamo implementato con OpenLDAP 2.3 e
Debian etch (4.0r1). Oggi ho riscontrato un problema strano: I client
che si connettono su cui sono installati le versioni di ldapsearch
forniti con la Etch (OpenLDAP 2.3) non hanno problemi con la verifica
dei certificati tramite la certification authority mentre quelli che
utilizzano la versione precedente della Debian (e di conseguenza la
versione 2.2 di OpenLDAP) non riescono a verificare il certificato
tramite le CA. Premesso che ho ricontrollato che i certificati siano nel
posto giusto e che siano quelli giusti non riesco proprio a spiegarmi
questa cosa. Qualcuno ha avuto esperienze simili?





___
OpenLDAP mailing list
OpenLDAP@sys-net.it
https://www.sys-net.it/mailman/listinfo/openldap

Re: [OpenLDAP] Anomalia con TLS.

[Michele Codutti]

Ma è quello che ho fatto anch'io su entrambe le tipologie di client ma
si comportano in maniera differente ... :\
Che cosa può essere?

Il giorno mer, 03/10/2007 alle 16.30 +0200, Marco Gaiarin ha scritto:
> Mandi! Michele Codutti
>   In chel di` si favelave...
> 
> > questa cosa. Qualcuno ha avuto esperienze simili?
> 
> Sinceramente no, con le ldap-utils non ho mai avuto alcun problema...
> ma la configurazione è la 'classica' con certificato della CA copiato in
> ogni client su /etc/ssl/certs e aggiunto in /etc/ldap/ldap.conf,
> esempio:
> 
>   TLS_CACERT  /etc/ssl/certs/LNFFVG.pem
> 





___
OpenLDAP mailing list
OpenLDAP@sys-net.it
https://www.sys-net.it/mailman/listinfo/openldap

[OpenLDAP] Perché il replicatore non si replica?!?!?!

[Michele Codutti]

Salve a tutti durante i primi test sul campo di un sistema OpenLDAP con
replicazione syncprov/syncrepl ho notato una cosa anomala: il dn
corrispondente al replicatore (che d'ora in poi chiamerò
cn=replicator,dc=example,dc=net) non viene replicato sul consumer...
Eppure sul file di configurazione del producer c'è una specifica
direttiva che permette di leggere tutto l'albero cn=log:
access to dn.subtree="cn=log" by
dn.exact="cn=replicator,dc=example,dc=net" read
  by * none
Sono stati rimossi i limiti:
limits dn.exact="cn=replicator,dc=example,dc=net"
size=unlimited
time=unlimited
E nelle ACL ci sono specifiche regole che permettono al DN replicator di
leggere/scrivere (write) tutto l'albero.
Sul file di configurazione del consumer ci sono le stesse ACL.
Come è possibile che possa succedere una cosa del genere?!?!
Sparate pure a caso tanto sono a corto di idee per eventuali controlli.
Grazie.





___
OpenLDAP mailing list
OpenLDAP@sys-net.it
https://www.sys-net.it/mailman/listinfo/openldap

Re: [OpenLDAP] open ldap manualistica

[Michele Codutti]

Una buona base di partenza è l'OpenLDAP Administration Guide che trovi
sul sito di OpenLDAP ma l'ho trovato un po' incompleto su alcuni
argomenti che però sono spiegati molto meglio nella FAQ dello stesso
sito. Io non ho trovato libri aggiornati in libreria.
In bocca al lupo per la tua avventura.

Michele.

Il giorno dom, 14/10/2007 alle 11.36 +0200, sikurezza ha scritto:
> saluti a tutti da un nuovo iscritto. 
> qualcuno conosce per favore dei link a della buona manualistica per open 
> ldap possibilmente in italiano? magari anche il titolo di un libro 
> valido ed esauriente?
> affronto open ldap per la prima volta.
> 
> grazie 
> 
> ___
> OpenLDAP mailing list
> OpenLDAP@sys-net.it
> https://www.sys-net.it/mailman/listinfo/openldap





___
OpenLDAP mailing list
OpenLDAP@sys-net.it
https://www.sys-net.it/mailman/listinfo/openldap

[OpenLDAP] Limitare le ricerche

[Michele Codutti]

Buongiorno a tutti, volevo chiedervi se è possibile limitare tramite
delle ACL i risultati delle ricerche.
Esempio: Vorrei che ai miei client che effettuano una ricerca sul
sottoramo ou=utenti non venissero ritornati tutti i DN presenti ma solo
quelli che hanno un attributo pari ad un certo valore.
Pensate sia possibile?

Grazie,
Michele





___
OpenLDAP mailing list
OpenLDAP@sys-net.it
https://www.sys-net.it/mailman/listinfo/openldap

Re: [OpenLDAP] openldap + kerberos

[Michele Codutti]

Questo è un ottimo documento:
http://gpaterno.free.fr/publications/SingleSignon/index.html


Il giorno mer, 24/10/2007 alle 17.00 +0200, Stefanelli Mirko ha scritto:
> Ciao a tutti,
> 
> mi è stato chiesto di indagare sulla possibiltà di "kerberizzare" i
> servizi ed utilizzare la coppia opneLdap e un server Kerberos
> (possibilmente free) per relaizzare un servizio demo. Chiedo a voi se
> avete documentazione o  link da cui partire per ralizzare la cosa.
> 
> vi ringrazio anticipatamente.
> 
> Saluti
> Mirko Stefanelli
> 
> Gruppo CASC
> Consultant
> c/o Telecom Italia
> Palazzina A - Piano 1° - 340 06 33 560
> S.S.148 Pontina Km. 29,100 - 00040 POMEZIA (RM)
> [EMAIL PROTECTED]
> 
> 
> 
> ___
> OpenLDAP mailing list
> OpenLDAP@sys-net.it
> https://www.sys-net.it/mailman/listinfo/openldap





___
OpenLDAP mailing list
OpenLDAP@sys-net.it
https://www.sys-net.it/mailman/listinfo/openldap

Re: [OpenLDAP] DN e caratteri non ASII

[Michele Codutti]

Non mi è chiaro se i client di OpenLDAP (ldapsearch e ldapmodify) non
convertano i caratteri non-UTF8 a UTF8. Quel "non lo consentono" è
ambiguo.
Domanda sciocca: anche i valori di tutti gli attributi sono codificati
in UTF8, vero?

Grazie.

Il giorno mar, 06/11/2007 alle 16.18 +0100, Pierangelo Masarati ha
scritto:
> [EMAIL PROTECTED] wrote:
> > Ciao a tutti.
> > 
> > Ho il seguente problema:
> > 
> > se provo ad inserire nel DN un carattere speciale ad esempio à o altri
> > caratteri non ASII si genera un errore.
> > 
> > Come posso risolvere il problema senza rinunciare ai caratteri non ASII.
> 
> LDAP usa UTF8 (di cui ASCII e' un subset) come codifica dei caratteri
> nei valori di sintassi directoryString.  Per cui, i caratteri non-ASCII
> vanno codificati in UTF8.  Ad esempio, se prendi "à" in ISO8859-1,
> ovvero "0xe0", e lo converti in UTF8, ottieni "0xc3 0xa0".  LDAP usa
> questa codifica, e accetta valori codificati in questo modo.  Qualsiasi
> valore che usi una codifica diversa viola le specifiche del protocollo,
> e quindi non puo' essere usato.
> 
> Se vuoi interoperare con applicazioni che usano codifiche diverse, ad
> esempio ISO-8859-1, devi convertire i valori in UTF8 prima di scriverli
> su LDAP, e convertirli nell'altra codifica ogni volta che li leggi.
> Questo, ovviamente, non puo' essere fatto direttamente da OpenLDAP, ma
> deve essere fatto dal client.  I client OpenLDAP (ldapsearch, ecc.) non
> lo consentono, a meno di modifiche.  Puo' darsi che altri client lo
> consentano, sta a te verificare.
> 
> 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 mailing list
OpenLDAP@sys-net.it
https://www.sys-net.it/mailman/listinfo/openldap

[OpenLDAP] Account per cercvare gli utenti

[Michele Codutti]

Salve a tutti. In un server OpenLDAP ho archiviato tutti i miei utenti
in modo ramificato per rispettare la loro area funzionale. Ora ho
svariati applicativi che lo utilizzano per l'autenticazione. L'utente
digita il sua username che corrisponde all'attributo uid della sua entry
e la sua password. L'applicativo, ricevute queste informazioni, si
autentica tramite una sua dn ed la sua (dell'applicativo) password e
cerca l'utente con l'uid pari alla username digitata. A questo punto fa
un rebind con la dn risultante dalla ricerca e la password immessa
dall'utente precedentemente.
Fino ad ora avevo lasciato che alcuni IP (relativi alle macchine su cui
giravano gli applicativi) potessero fare bind anonimi ma volendo
stringere la vite ho creato per ogni applicativo un dn ed ho scritto la
seguente ACL:

access to ou=users,dc=test,dc=com attrs=uid
   by dn.children="ou=applications,dc=test,dc=com" search
   ... <--- altre regole che permettono ad altre entry altre azioni
   by * none

Ora se faccio la seguente ricerca:

 ldapsearch -x -LLL -b "ou=users,dc=test,dc=com" -D
"cn=application1,ou=applications,dc=test,dc=com" -W -ZZ -H
ldap://localhost "(uid=*)"

mi aspetto di vedere l'elenco (le dn) di tutti gli utenti della mia
directory ma invece ricevo il seguente errore:
No such object (32)
Matched DN: dc=test,dc=com

Non capisco che cosa sbaglio. Devo rendere leggibili altri attributi?
Grazie a tutti in anticipo.






___
OpenLDAP mailing list
OpenLDAP@sys-net.it
https://www.sys-net.it/mailman/listinfo/openldap

[OpenLDAP] Cambio di parametri operativi di slapd tramite cn=config

[Michele Codutti]

Ciao a tutti, sto usando OpenLDAP nella versione fornita da Debian Etch
(2.3.30) e mi hanno chiesto di indagare quali vantaggi potremmo avere
passando dall'attuale metodo di configurazione tramite slapd.conf a
quello con cn=config.
Ora, il mio obbiettivo è quello di cambiare al volo alcuni parametri
operativi del demone slapd nel caso ci sia un fail-over. Nello specifico
mi piacerebbe cambiare/aggiungere/togliere socket di ascolto per le
connessioni e cambiare il ruolo da producer a consumer e viceversa nella
configurazione di syncrepl con deltasync che abbiamo adottato.
Io ho fatto un po' di ricerca e mi sembra che NON sia possibile
cambiare/aggiungere/togliere al volo socket di ascolto senza riavviare
il demone mentre non sono sicuro che si possa fare il cambio di ruolo
per syncrepl.
Qualcuno può darmi qualche informazione in più?

Grazie mille.
Michele Codutti





___
OpenLDAP mailing list
OpenLDAP@sys-net.it
https://www.sys-net.it/mailman/listinfo/openldap

Re: [OpenLDAP] Cambio di parametri operativi di slapd tramite cn=config

[Michele Codutti]

> E' vero, non si puo', ne' esistono piani per renderlo possibile.  Il
> motivo sostanziale e' che per fare qualcosa del genere, occorrerebbe
> comunque aspettare che tutte le connessioni attive su quelle interfacce
> siano chiuse, o forzarne la chiusura, il che equivale ad aspettare che
> il server sia scarico (e quindi un riavvio non comporta problemi) oppure
> a forzarlo.
Ok, questi problemi però si hanno solo nel caso di rimozione di un
socket ma per aggiungerne uno non ci dovrebbero essere problemi.
Sbaglio?

> > mentre non sono sicuro che si possa fare il cambio di ruolo
> > per syncrepl.
> > Qualcuno può darmi qualche informazione in più?
> 
> Questo in teoria si puo' fare (e' uno dei motivi per i quali back-config
> e' nato).  In pratica, credo che dipenda da quanto incasinata e' la tua
> configurazione, per cui non garantisco al 100% che funzioni in ogni
> circostanza.  E comunque se ci sono problemi e' piu' probabile che
> compaiano con la 2.3.30 che con versioni piu' recenti (al momento:
> 2.3.40/2.4.7).
C'è un vademecum con il passi consigliati da fare? Il caso che mi
preoccupa e sul quale non riesco a trovare una soluzione soddisfacente è
quello in cui ho il producer in fail e voglio trasformare il/un consumer
in producer. Considerando il fatto che se il producer è in fail voglio
solo terminare il servizio. Il vero problema sono i passi (ovvero ldif
da utilizzare con ldapmodify) per trasformare il producer in consumer.

Michele





___
OpenLDAP mailing list
OpenLDAP@sys-net.it
https://www.sys-net.it/mailman/listinfo/openldap

Re: [OpenLDAP] Cambio di parametri operativi di slapd tramite cn=config

[Michele Codutti]

> > Ok, questi problemi però si hanno solo nel caso di rimozione di un
> > socket ma per aggiungerne uno non ci dovrebbero essere problemi.
> > Sbaglio?
> 
> Vero.  A questo punto, l'unica obiezione e' che se usi -u, a server
> attivo non puoi fare bind(2) su porte privilegiate (tipo 389 o 636).
> Per il resto, aprire un nuovo listener "dovrebbe" essere possibile,
> anche se, per come la struttura del listener e' fatta, non si tratta di
> una modifica banale.
Allora è meglio utilizzare une regola iptables di Destinatio NAT del tipo:
iptables -t nat -D PREROUTING -d "$extra_address" -j DNAT --to
"$standard_address"
ed attivare un interfaccia alias (o aggiungere l'indirizzo
all'interfaccia esistente) con l'ip della macchina defunta.
Non pulitissimo ma efficace.

> E' conveniente avere l'overlay syncprov (che caratterizza il producer)
> su tutti i server, anche i consumer.  A questo punto, per promuovere il
> consumer a producer occorre rimuovere la linea "syncrepl"; per degradare
> un producer a consumer occorre aggiungere la linear "syncrepl".  La cosa
> piu' importante e' che tutti i consumer devono comunque essere
> modificati se la loro linea "syncrepl" contiene il producer originale;
> occorre infatti farvi comparire il nuovo producer.  In alternativa, si
> puo' avere una configurazione in cui tutti i server (tranne se stessi),
> indipendentemente dall'essere producer o consumer, sono listati nelle
> linee "syncrepl" nel campo "producer", in modo che se il producer
> corrente cessa di funzionare, provino a contattare il successivo finche'
> uno risponde.  Per un consumer, il fatto di alimentarsi dal producer o
> da un altro consumer in cascata non fa grande differenza, se non che le
> replicazioni in genere subiscono un ritardo aggiuntivo che in genere e'
> trascurabile, e solo in caso di modifiche massive puo' risultare
> apprezzabile.  Ad esempio, se hai "server0", "server1", "server2", e
> normalmente il producer e' "server0", configurerai:
> 
> # server0, producer:
> # syncrepl provider="ldap://server1 ldap://server2";
> overlay syncprov
> 
> # server1, consumer:
> syncrepl provider="ldap://server0 ldap://server2";
> overlay syncprov
> 
> # server2, consumer:
> syncrepl provider="ldap://server0 ldap://server1";
> overlay syncprov
> 
> Se succede un problema a "server0", e vuoi promuovere "server2" a
> producer, avrai:
> 
> # server0, producer declassato a consumer per quando riparte:
> syncrepl provider="ldap://server1 ldap://server2";
> overlay syncprov
> 
> # server1, consumer:
> syncrepl provider="ldap://server0 ldap://server2";
> overlay syncprov
> 
> # server2, consumer promosso a producer:
> # syncrepl provider="ldap://server0 ldap://server1";
> overlay syncprov
> 
> Spero che sia chiaro.
Credo di aver capito, domani provo.
Intanto ti ringrazio infinitamente per la squisita disponibilità.
Michele.





___
OpenLDAP mailing list
OpenLDAP@sys-net.it
https://www.sys-net.it/mailman/listinfo/openldap

[OpenLDAP] OpenLDAP + stunnel

[Michele Codutti]

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 , 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

Re: [OpenLDAP] OpenLDAP + stunnel

[Michele Codutti]

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  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]

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  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

[Michele Codutti]

Ho risolto il mio problema. La regola ACL da impostare per fare in modo
che le connessioni provenienti dall'interfaccia pubblica siano cifrate
mentre quelle dell'interfaccia privata possano non esserlo è la
seguente:
access to *
 by peername.ip=10.0.0.0%255.0.0.0 break
 by peername.ip=0.0.0.0%0.0.0.0 ssf=128 break
 by peername.ip=0.0.0.0%0.0.0.0 stop
 by * break
Dove la rete privata ha la classe di indirizzi 10.0.0.0/8.
La regola deve essere apposta sopra tutte le altre ed il demone può
essere avviato con il parametro "-h ldap:// ldaps://" mettendolo in
ascolto su tutte le interfacce.

Grazie a tutti per l'interessamento e per l'aiuto.
Michele

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.
> 
> > 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  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] ACL espressioni regolari

[Michele Codutti]

Questa ACL non va bene?
access to dn.subtree="ou=persone,ou=web,ou=example,ou=com"
by self read

Il giorno lun, 25/02/2008 alle 09.43 +0100, Pierangelo Masarati ha
scritto:
> 
> access to \
> dn.regex="(.+,)?(uid=[^,]+,ou=persone,ou=web,ou=example,ou=com)$"
>   by dn.expand="$2" read
> 





___
OpenLDAP mailing list
OpenLDAP@sys-net.it
https://www.sys-net.it/mailman/listinfo/openldap

Re: [OpenLDAP] ACL espressioni regolari

[Michele Codutti]

Effettivamente ho supposto che non ci fossero entry figlie.
Grazie della spiegazione, mi ero spaventato a vedere la tua ACL.

Il giorno lun, 25/02/2008 alle 10.06 +0100, Pierangelo Masarati ha
scritto:
> Michele Codutti wrote:
> > Questa ACL non va bene?
> > access to dn.subtree="ou=persone,ou=web,ou=example,ou=com"
> > by self read
> 
> Nel modo da te indicato ogni utente puo' solo accedere alla propria
> entry, ma non ad eventuali entry figlie della propria.  Se non sono
> previste entry figlie, questo modo e' piu' efficiente di quello che
> avevo indicato io, perche' evita regex match ed espansione.
> 
> 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] ACL espressioni regolari

[Michele Codutti]

Cosa intendi per schema? Intendi forse a quali objectClass appartiene
una entry?

Il giorno lun, 25/02/2008 alle 11.04 +0100, Andrea Cirulli ha scritto:
> Grazie a tutti per l'acl che mi avete fornito,
> 
> volevo chiedere un'altra informazione è possibile sempre tramite ACL
> non permettere agli utenti normali di visualizzare lo schema (per
> esempio il software softerra ldap administrator ha una funzionalità
> che permette di vedere lo schema del server ldap).
> 
> Quello che vorrei ottenere è che: solo l'utente root ha il permesso di
> vedere lo schema mentre tutti gli altri utenti no!
> 
> Grazie ancora  a tutti,
> 
> Ciao,
> 
> 2008/2/25 Michele Codutti <[EMAIL PROTECTED]>:
> Effettivamente ho supposto che non ci fossero entry figlie.
> Grazie della spiegazione, mi ero spaventato a vedere la tua
> ACL.
> 
> Il giorno lun, 25/02/2008 alle 10.06 +0100, Pierangelo
> Masarati ha
> scritto:
> 
> > Michele Codutti wrote:
> > > Questa ACL non va bene?
> > > access to dn.subtree="ou=persone,ou=web,ou=example,ou=com"
> > > by self read
> >
> > Nel modo da te indicato ogni utente puo' solo accedere alla
> propria
> > entry, ma non ad eventuali entry figlie della propria.  Se
> non sono
> > previste entry figlie, questo modo e' piu' efficiente di
> quello che
> > avevo indicato io, perche' evita regex match ed espansione.
> >
> > 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
> 
> 
> 
> 
> -- 
> Andrea Cirulli 
> ___
> OpenLDAP mailing list
> OpenLDAP@sys-net.it
> https://www.sys-net.it/mailman/listinfo/openldap





___
OpenLDAP mailing list
OpenLDAP@sys-net.it
https://www.sys-net.it/mailman/listinfo/openldap

Re: [OpenLDAP] ssl su Ldap

[Michele Codutti]

In breve:
1) Si, il protocollo ssl provvede a cifrare il traffico in chiaro.
Quindi nel caso di autenticazione semplice (in cui username e password
passano in chiaro) il traffico viene cifrato e quindi in chiaro non lo è
più.
2) La situazione che prospetti non è reale. Ovvero non è il client che
ha il certificato ma il server. Quindi è il client che verifica
l'identità del server non il contrario.
Una migliore spiegazione del protocollo ssl la trovi sull'ottimo
wikipedia:
http://en.wikipedia.org/wiki/Secure_Sockets_Layer

Il giorno ven, 29/02/2008 alle 10.17 +0100, Elisa Pellegrini ha scritto:
> Salve!
> non mi è molto chiaro il funzionamento di ssl. Da quello che ho capito 
> ssl crea un canale criptato tra un client e un server che vogliono 
> comunicare.
> Nel mio caso è il client Ldap che interroga il server Ldap
> 
> 1. Il client sul canale ssl può inviare al server il suo username e 
> password in chiaro? nel senso che ci pensa il canale a criptarli?
> 2. se il client sta usando un certificato e ssl come fa il server a 
> verificare l'identità del client?
> 
> grazie!!
> 
> 
> 
> 
> ___
> OpenLDAP mailing list
> OpenLDAP@sys-net.it
> https://www.sys-net.it/mailman/listinfo/openldap





___
OpenLDAP mailing list
OpenLDAP@sys-net.it
https://www.sys-net.it/mailman/listinfo/openldap

Re: [OpenLDAP] ssl su Ldap

[Michele Codutti]

Si hai ragione ma da quello che scriveva Elisa Pellegrini non mi
sembrava usasse la strong authentication ma solo la cifratura per la
protezione delle credenziali. Se non è così ho sottovalutato la domanda
e me ne scuso.

Il giorno ven, 29/02/2008 alle 11.18 +0100, Luca Scamoni ha scritto:
> Michele Codutti wrote:
> > In breve:
> > 2) La situazione che prospetti non è reale. Ovvero non è il client che
> > ha il certificato ma il server. Quindi è il client che verifica
> > l'identità del server non il contrario.
> > Una migliore spiegazione del protocollo ssl la trovi sull'ottimo
> > wikipedia:
> > http://en.wikipedia.org/wiki/Secure_Sockets_Layer
> >   
> La situazione e' assolutamente reale e ha a che fare con la strong 
> authentication in cui *anche* il client deve avere un certificato valido 
> (firmato dalla stessa CA del server o da una sua subCA) per potersi 
> autenticare al server. Qui non e' piu' questione di stabilire una 
> connessione cifrata ma di autenticarsi.
> 
> 
> 
> 
> Ing. Luca Scamoni
> Responsabile Ricerca e Sviluppo
> 
> SysNet s.r.l.
> via Dossi, 8 - 27100 Pavia - ITALIA
> http://www.sys-net.it
> ---
> Office:  +39 0382 573859 (137)
> Mobile:  +39 347 1014425
> Email:   [EMAIL PROTECTED]
> ---
> 
> 
> 





___
OpenLDAP mailing list
OpenLDAP@sys-net.it
https://www.sys-net.it/mailman/listinfo/openldap

[OpenLDAP] Logging

[Michele Codutti]

Buongiorno a tutti, sto cercando di fare un tuning del livello di
logging dei server OpenLDAP che gestisco. Attualmente li livello di
logging è impostato a "Stats" ovvero a 256. Questo livello produce
troppe informazioni che di media si traduce in un file di logging di
circa 2 Giga al giorno.
Non è ammissibile impostare un logging nullo ma vorrei abbassare le
informazioni registrate. Mi piacerebbe avere solo le autenticazioni e
gli ip da cui provengono. E' possibile? Dal manuale della versione 2.3
(utilizzo la versione fornita da Debian Etch) non sembra che ci sia un
livello di logging aderente alle mie necessità.
Sbaglio? C'è qualche altro modo per ottenere il risultato che cerco?

Grazie.
Michele





___
OpenLDAP mailing list
OpenLDAP@sys-net.it
https://www.sys-net.it/mailman/listinfo/openldap

[OpenLDAP] Il rootdn scompare dal consumer

[Michele Codutti]

Buongiorno a tutti vi scrivo per tornare a parlare di un fenomeno che
non sono riuscito a risolvere: La replicazione dell'utente replicatore
in una configurazione syncrepl con deltasync.
Ora, ne avevo già discusso qui:
http://www.sys-net.it/pipermail/openldap/2007-October/000750.html
E credevo (sbagliandomi) di aver trovato una soluzione impostando
l'utente replicatore come il rootdn della directory.
Da qualche giorno faccio dei test su questa configurazione scambiando i
ruoli dei due nodi (producer<->consumer) e mi sono accorto che spariva
l'entry relativa al rootdn.
Poi ho fatto un test più semplice ed ho modificato sul producer
l'attributo "description" della entry rootdn e sul consumer è sparita la
entry del rootdn che (speravo) doveva essere replicata.
In una risposta mi avete detto che potrebbe essere un comportamento
normale:
http://www.sys-net.it/pipermail/openldap/2007-October/000750.html
Vorrei, se possibile, avere conferma o smentita di questo fatto.

Vi ringrazio in anticipo per l'attenzione,
Michele Codutti





___
OpenLDAP mailing list
OpenLDAP@sys-net.it
https://www.sys-net.it/mailman/listinfo/openldap

[OpenLDAP] pwdFailureTime

[Michele Codutti]

Ciao a tutti, ho un problema con l'overlay ppolicy. L'ho attivato per
impostare la memorizzazione cifrata dell'attributo userPassword tramite
la direttiva "ppolicy_hash_cleartext". Questo overlay mi sta creando
anche un effetto non previsto e non desiderato. Ogni volta che un utente
sbaglia la password la DN dell'utente stesso viene modificata con
l'aggiunta dell'attributo pwdFailureTime con il timestamp relativo
all'evento, di conseguenza viene modificato l'attributo modifierName con
il dn del rootdn del database.
Questo purtroppo mi crea un po' di problemi vorrei disabilitare questa
funzionalità senza disabilitare la funzione di hash automatico delle
password. Ho letto la pagina man di ppolicy ma non ho trovato una
soluzione. Avete idee o suggerimenti?

Saluti,
Michele Codutti.





___
OpenLDAP mailing list
OpenLDAP@sys-net.it
https://www.sys-net.it/mailman/listinfo/openldap

Re: [OpenLDAP] pwdFailureTime

[Michele Codutti]

Ops l'ho rifatto... ho spedito premendo il tasto rispondi. :P
Ok ho capito cosa intendi. Purtroppo questa soluzione si basa sulla
modifica dei client. Questa cosa non la posso chiedere. Non sono io che
mi occupo dei client (che possono essere anche delle applicazioni web) e
devo dare la garanzia che le password vengano cifrate all'interno del
DIT.

Il giorno lun, 17/03/2008 alle 15.12 +0100, Marco D'Ettorre ha scritto:
> Questa è l'RFC:
> http://www.faqs.org/rfcs/rfc3062.html.
> 
> Tra i client forniti con OpenLDAP ce ne è uno che la implementa. Per 
> informazioni:
> man ldappasswd
> 
> Ciao
> M.
> 
> PS: ricorda di mettere sempre in copia la lista.
> 
> 
> Michele Codutti wrote:
> > Ehm ... no. Extended operation dici. Ora provo ad informarmi. Se hai
> > qualche buon link da suggerirmi posta pure.
> >
> > Il giorno lun, 17/03/2008 alle 14.59 +0100, Marco D'Ettorre ha scritto:
> >   
> >> Ciao,
> >> il modo migliore per scrivere le password in chiaro e lasciare al 
> >> server il compito di cifrarle è quello di utilizzare l'extended 
> >> operation di cambio password.
> >> Hai già valutato questa ipotesi prima di scegliere di usare questa 
> >> opzione del ppolicy?
> >>
> >>
> >>
> >> Michele Codutti wrote:
> >> 
> >>> Ciao a tutti, ho un problema con l'overlay ppolicy. L'ho attivato per
> >>> impostare la memorizzazione cifrata dell'attributo userPassword tramite
> >>> la direttiva "ppolicy_hash_cleartext". Questo overlay mi sta creando
> >>> anche un effetto non previsto e non desiderato. Ogni volta che un utente
> >>> sbaglia la password la DN dell'utente stesso viene modificata con
> >>> l'aggiunta dell'attributo pwdFailureTime con il timestamp relativo
> >>> all'evento, di conseguenza viene modificato l'attributo modifierName con
> >>> il dn del rootdn del database.
> >>> Questo purtroppo mi crea un po' di problemi vorrei disabilitare questa
> >>> funzionalità senza disabilitare la funzione di hash automatico delle
> >>> password. Ho letto la pagina man di ppolicy ma non ho trovato una
> >>> soluzione. Avete idee o suggerimenti?
> >>>
> >>> Saluti,
> >>> Michele Codutti.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>   
> >>> 
> >>>
> >>> ___
> >>> OpenLDAP mailing list
> >>> OpenLDAP@sys-net.it
> >>> https://www.sys-net.it/mailman/listinfo/openldap
> >>>   
> >>>   
> >>
> >>
> >> Ing. Marco D'Ettorre
> >> Consultant
> >>
> >> SysNet s.r.l.
> >> via Dossi, 8 - 27100 Pavia - ITALIA
> >> http://www.sys-net.it
> >> ---
> >> Office:  +39 0382 573859 (102)
> >> Mobile:  +39 348 1510674
> >> Email:   [EMAIL PROTECTED]
> >> ---
> >>
> >>
> >>
> >> 
> >
> >
> >
> >   
> 
> 
> 
> 
> Ing. Marco D'Ettorre
> Consultant
> 
> SysNet s.r.l.
> via Dossi, 8 - 27100 Pavia - ITALIA
> http://www.sys-net.it
> ---
> Office:  +39 0382 573859 (102)
> Mobile:  +39 348 1510674
> Email:   [EMAIL PROTECTED]
> ---
> 
> 
> 





___
OpenLDAP mailing list
OpenLDAP@sys-net.it
https://www.sys-net.it/mailman/listinfo/openldap

Re: [OpenLDAP] pwdFailureTime

[Michele Codutti]

Il giorno lun, 17/03/2008 alle 16.07 +0100, Luca Scamoni ha scritto:
> Tieni in CC la lista!
Si hai ragione mi spiace.

> Michele Codutti wrote:
> > Grazie per l'interessamento. La cosa è problematica poiché abbiamo più
> > utenti che modificano l'albero a diversi livelli di privilegi.
> > Ovvero: il rootdn modifica tutto il DIT alcune entri solo certi
> > sottorami ed altri solo alcuni attributi di dentry appartenenti ad
> > alcuni sottorami. Quindi il marasma si viene a creare quando si deve
> > capire se la modifica è stata fatta dall'utente proprietario della entry
> > o da un operatore. Non ci interessa se un utente sbaglia la password,
> > piuttosto ci interessa capire se se l'è cambiata e poi non riesce ad
> > autenticarsi.
> >   
> Che versione di OL stai usando?
> Ho fatto qualche test e il comportamento di ppolicy (almeno in HEAD) e' 
> corretto. Se l'utente sbaglia la password viene aggiunto il 
> pwdFailureTime ma non viene modificato il modifiersName.
> 
La versione di OL che uso è la 2.3.30 installata dalla Debian Etch
aggiornata.
Comunque ho verificato nuovamente il comportamento e ti confermo che
quando l'utente sbaglia la password viene aggiunto l'attributo
pwdFailureTime e viene modificato il modifiersName con il rootdn.





___
OpenLDAP mailing list
OpenLDAP@sys-net.it
https://www.sys-net.it/mailman/listinfo/openldap

Re: [OpenLDAP] URGENTE:replica master-slave

[Michele Codutti]

Potresti far migrare l'ip dello slave verso il master da cui
preleva/riceve le repliche. In questo modo però i client contattano un
server LDAP non più in sola lettura.
Puoi automatizzare il tutto se usi linux con heartbeat:


Il giorno mer, 26/03/2008 alle 19.43 +0100, puestadelsol83 ha scritto:
> Salve,
> ho un dubbio: ho creato 4 server master e uno slave (in sola lettura)per ogni 
> ramo dell'albero Ldap. se però un client chede allo slave di leggere i dati e 
> lo slave non funziona la richiesta viene redirezionata al master o lo slave 
> non può più contattare il master? Un problema di questo tipo come si risolve? 
> grazie!
> 
> 
> 
> 
> ___
> OpenLDAP mailing list
> OpenLDAP@sys-net.it
> https://www.sys-net.it/mailman/listinfo/openldap
> 
> 
> 





___
OpenLDAP mailing list
OpenLDAP@sys-net.it
https://www.sys-net.it/mailman/listinfo/openldap

Re: [OpenLDAP] superuser per piu' di un database.

[Michele Codutti]

Non credo di aver capito bene la domanda. Come hai fatto a configurare
il superuser sul primo dominio?
Hai usato la direttiva:
rootdn cn=admin,dc=dominio1,dc=it
Giusto?
Bene, basta che replichi la direttiva nella parte di configurazione del
secondo database.
Spero di averti fornito delle informazioni utili.

Michele.

Il giorno mer, 16/04/2008 alle 13.57 +0200, Mauro Sanna ha scritto:
> Ho un server ldap su un sistema debian etch.
> Ho configurato due database per gestire due domini.
> Il primo dominio ha come superuser cn=admin,dc=dominio1,dc=it e l'ho
> configurato durante l'installazione del server ldap.
> Accendendo con questo user posso modificare il database.
> Per il secondo database invece non so come fare per inserire un
> superuser poiche' per poterlo fare bisogna esserlo superuser ma non so
> come agginugerlo.
> Non so se sono stato chiaro.
> E' piuttosto urgente.
> Scusate, grazie.
> 
> 
> 
> 
> 
> ___
> OpenLDAP mailing list
> OpenLDAP@sys-net.it
> https://www.sys-net.it/mailman/listinfo/openldap





___
OpenLDAP mailing list
OpenLDAP@sys-net.it
https://www.sys-net.it/mailman/listinfo/openldap

Re: [OpenLDAP] superuser per piu' di un database.

[Michele Codutti]

Il giorno mer, 16/04/2008 alle 16.36 +0200, Mauro Sanna ha scritto:
> Il giorno mer, 16/04/2008 alle 14.22 +0200, Michele Codutti ha scritto:
> > Non credo di aver capito bene la domanda. Come hai fatto a configurare
> > il superuser sul primo dominio?
> > Hai usato la direttiva:
> > rootdn cn=admin,dc=dominio1,dc=it
> > Giusto?
> > Bene, basta che replichi la direttiva nella parte di configurazione del
> > secondo database.
> > Spero di averti fornito delle informazioni utili.
> > 
> 
> Allora sono un po in palla...
> Durante l'installazione di openldap sul mio sistema debian linux, mi
> vengono chieste delle informazioni tra cui la password per il suepruser
> del database.
> Fatto questo mi ritrovo nel database un cn=admin,dc=dominio1,dc=it.
> Con tale user posso gestire il database.
> La direttiva rootdn nel file slapd.conf e' commentata.
> Modificando slapd.conf ho aggiunto un secondo database con suffisso
> dc=dominio2,dc=it.
> Ora mi servirebbe creare anche in questo secondo database lo stesso
> utente admin ma non so come in quanto quello sul primo database era
> stato creato in maniera automatica dalla procedura d'installazione.
Risposta quick & dirty se vuoi avere lo stesso amministratore per
entrambi i database aggiungi la direttiva:
rootdn cn=admin,dc=dominio1,dc=it
nella parte del file di config successiva alla definizione del secondo
DB.





___
OpenLDAP mailing list
OpenLDAP@sys-net.it
https://www.sys-net.it/mailman/listinfo/openldap

[OpenLDAP] Stato di sync di un server consumer

[Michele Codutti]

Buongiorno a tutti, c'è un metodo per determinare lo stato di
sincronizzazione di un server OpenLDAP, configurato come consumer,
rispetto al suo producer?

Grazie,
Michele





___
OpenLDAP mailing list
OpenLDAP@sys-net.it
https://www.sys-net.it/mailman/listinfo/openldap

Re: [OpenLDAP] Stato di sync di un server consumer

[Michele Codutti]

Grazie, sebbene stringato, il tuo aiuto mi ha aiutato a recuperare una
pagina web interessante con la soluzione esplicita al mio problema che
di seguito pubblico a beneficio delle ML:
http://docs.hp.com/en/5991-7504/ar01s08.html

Michele

Il giorno mer, 23/04/2008 alle 12.32 +0200, Luca Scamoni ha scritto:
> guardando il contextCSN
> 
> Michele Codutti wrote:
> > Buongiorno a tutti, c'è un metodo per determinare lo stato di
> > sincronizzazione di un server OpenLDAP, configurato come consumer,
> > rispetto al suo producer?
> >
> > Grazie,
> > Michele
> >
> >
> >
> >
> >
> >   
> > 
> >
> > ___
> > OpenLDAP mailing list
> > OpenLDAP@sys-net.it
> > https://www.sys-net.it/mailman/listinfo/openldap
> >   
> 
> 
> 
> Ing. Luca Scamoni
> Responsabile Ricerca e Sviluppo
> 
> SysNet s.r.l.
> via Dossi, 8 - 27100 Pavia - ITALIA
> http://www.sys-net.it
> ---
> Office:  +39 0382 573859 (137)
> Mobile:  +39 347 1014425
> Email:   [EMAIL PROTECTED]
> ---
> 
> 
> 





___
OpenLDAP mailing list
OpenLDAP@sys-net.it
https://www.sys-net.it/mailman/listinfo/openldap