Re: [OpenLDAP] AD schema

[Pierangelo Masarati]

Vittore Zen wrote:


Ora sono alle prese con il diabolico schema microsoft.
In particolare con:

map attribute   sAMAccountName uid


In realta' credo che tu debba usare

map attribute   uid sAMAccountName

ovvero esponi "uid" e lo trasformi in "sAMAccountName" per quanto 
riguarda l'interazione che il proxy ha con AD.  In questo caso non 
occorre che l'attributo sia noto al proxy (al massimo ti becchi qualche 
warning).



che genera un bel: destination attributeType 'sAMAccountName' is not
defined in schema

Ho provato a includere i vari microsoft.schema ma non vengono
caricati a causa di AttributeType not found: "instanceType"


Non esiste nessun microsoft.schema; una volta c'era in giro un file del 
genere, che pero' slapd non ha mai potuto caricare.  Per quanto ricordo, 
era una specie di roadmap verso le cose che sarebbero state necessarie 
per interagire con AD, ma dal momento che la maggior parte violano le 
specifiche di LDAP nessuno se ne e' mai curato...



Come faccio per avere uno schema MS che funzioni? (penso che sia utile
anche per rispondere alla domanda di openVPN postata poco prima)


Ti scarichi lo schema da AD (devi leggere la subschemaSubentry) e poi a 
mano ricostruisci quello che ti serve.  Non credo che ci sia altro modo, 
a meno che qualcun altro lo abbia gia' fatto e voglia condividerlo.


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 ProxyLDAP e OpenVPN

[Pierangelo Masarati]

Marco Ristaino wrote:

Buongiorno a tutti,
ho configurato un ldap proxy per raccogliere tutte le richieste ldap e
inviarle al Domain Controller
la configurazione è la seguente:

configurazione slapd.conf su proxyldap

databaseldap
suffix  "dc=domain,dc=com"
lastmod off
loglevelany
uri "ldap://serverDC/";

idassert-bind   bindmethod=simple
binddn="[EMAIL PROTECTED]"
credentials=lapassword
mode=self
idassert-authzFrom  dn.regex:.*

se da un pc della rete faccio un ldapsearch funziona tutto benissimo!

Ho deciso di implementare la sicurezza di openvpn con l'autenticazione
sul dominio AD tramite il plugin authldap-openvpn.
Ho configurato il plugin per fare le richieste su proxyldap.

configurazione di openvpn/auth/ldap.conf


# LDAP server URL
URL ldap://proxyldap






BaseDN  "cn=Users,dc=domain,dc=com"

# User Search Filter
#SearchFilter   "(&(uid=%u)(accountStatus=active))"
SearchFilter"(&(samaccountname=%u)(objectclass=*))"

Funziona alle volte si alle volte no, ma sono riusciro ad
identificarle... mi spiego meglio.

Caso in cui non funziona:
restart del daemon ldap su proxyldap
invio credenziali di autenticazione da parte del terminatore OpenVPN a proxyldap
l'autenticazione fallisce
Ho dato un'occhiata al traffico di rete tra il terminatore vpn e il
proxyldap catturando il traffico con tcpdump
ho visto che il proxy ldap passa i filtri corretti e cioè Filter:
(&(samaccountname=username)(objectclass=*)) mentre il proxy le manda
al Domain Controller così: Filter:
(&(!(objectClass=*))(objectClass=*))
e di conseguenza la ricerca fallisce.

Caso in cui funziona:
restart del daemon ldap su proxyldap
==> ldapsearch da un pc della rete <==
invio credenziali di autenticazione da parte del terminatore OpenVPN a proxyldap
l'autenticazione ha esito positivo
Verificato il traffico di rete e il filtro viene ricevuto e inviato
correttamente e cioè Filter:
(&(samaccountname=username)(objectclass=*)).

riassumendo, se prima di far fare un'autenticazione al terminatore vpn
verso proxyldap eseguo un ldapsearch da un'altro pc sempre su
proxyldap il tutto funziona e continua a funzionare correttamente fino
al restart del servizio ldap.

Per escludere un malfunzionamento del plugin di openvpn ho impostato
direttamente il Domain Controller come server ldap e funziona tutto
correttamente.

Qualcuno sa aiutarmi? ho sbagliato la configurazione di slapd.conf?


Probabilmente il problema e' che il proxy non ha definito l'attributo 
"samaccountname" nello schema.  Il proxy e' abbastanza "furbo" da 
riconoscere gli attributi ritornati da una ricerca e tenerne traccia 
nello schema, quindi se tu fai una ldapsearch che ritorna alcuni valori 
di "samaccountname", questo attributo (il tipo, non i valori) viene 
memorizzato come "proxied", e da li' in avanti viene tollerato dal 
frontend, per esempio, nei DN e nei filtri delle richieste.  Se pero' 
parti a freddo con un proxy che non ha ancora imparato da una richiesta, 
e nel filtro e' presente questo attributo, il filtro viene valutato come 
invalido.  A questo punto ti scontri con le specifiche LDAP per le quali 
se il filtro e' invalido l'operazione ritorna LDAP_SUCCESS senza alcun 
risultato.  Prova a scaricarti lo schema da AD, a riscrivere le 
informazioni di questo attributo nella sintassi compatibile con 
slapd.conf di OpenLDAP e verifica se il problema scompare.


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] Attributo "delete" e crash slapd

[Pierangelo Masarati]

Alessandro De Zorzi wrote:

Pierangelo Masarati wrote:

Mi sembra che il problema non sia presente nel 2.4.9 (ma non conosco i
dettagli dell'operazione che hai eseguito).  Puoi verificare?  Il
problema e' legato al fatto che la routine di indicizzazione
dell'attributo (e' indicizzato, vero?) viene chiamata passandogli
un'array di valori vuota, il che e' (dovrebbe essere) impossibile, da
cui l'asserzione.  Siccome dalla 2.4.7 alla 2.4.9 ci sono state un
certo numero di modifiche (almeno 60 bugfixes, a occhio), puo' darsi
che la cosa sia stata nel frattempo corretta.

grazie della preziosa risposta, confermo che vi sono degli indici anche
se non conosco nel dettaglio quali


OK.  Comunque, anche in presenza di indici non sono riuscito a causare 
il problema con software recente, quindi sembra che sia gia' stato 
risolto.  In ogni caso, solo tu puoi verificare se con una versione piu' 
recente del software il problema sia effettivamente scomparso.



inoltre volevo correggere nella mia mail precedente intendevo
"sconsigliato" dove ho scritto "consigliato"


Credo che fosse chiaro dal contesto :)


ovvero è nostra intenzione cambiare il nome all'attributo "delete" per
evitare qualsiasi problema ;-)


:)

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] Attributo "delete" e crash slapd

[Pierangelo Masarati]

Innanzitutto ci sono una serie di problemi nell'uso di "delete" come 
nome di attributo, perche' "delete" e' una parola chiave di LDIF; c'e' 
un baco aperto al riguardo: <http://www.openldap.org/its?findid=4639> 
(e' anche chiuso perche' riguarda slurpd e quindi "wontfix").


Alessandro De Zorzi wrote:

Tempo fa avevo segnalato che in uno schema utilizzavo
un simpatico attributo dal nome di "delete"

attributetype ( 1.3.6.1.4.1.22339.1.1.13 NAME 'delete'
DESC 'A boolean telling whether this item is marked for deletion'
EQUALITY booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )

questo era stato consigliato ma non avendo mai dato problemi non è stato
cambiato
ora in una situazione con replica Syncrepl e OpenLDAP 2.4.7 ho
verificato che creando
una Entry e aggiornando sul master l'oggetto prima che questo sia
replicato ldap va in crash
questo è il dump ottenuto lanciando slapd -d1

oc_check_allowed type "mailAutoreply"
oc_check_allowed type "delete"
oc_check_allowed type "vacationActive"
oc_check_allowed type "forwardActive"
oc_check_allowed type "amavisBypassVirusChecks"
oc_check_allowed type "amavisBypassSpamChecks"
oc_check_allowed type "amavisSpamKillLevel"
oc_check_allowed type "amavisSpamTag2Level"
oc_check_allowed type "amavisSpamTagLevel"
oc_check_allowed type "creationDate"
oc_check_allowed type "lastChange"
oc_check_allowed type "entryCSN"
oc_check_allowed type "modifiersName"
oc_check_allowed type "modifyTimestamp"
=> key_change(DELETE,1cb3)
<= key_change 0
slapd:
/home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openldap2.3-2.4.7/servers/slapd/schema_init.c:366:
octetStringIndexer: Assertion `i > 0' failed.
Abortito

Ovviamente quello che mi chiedo è se può dipendere dall'attributo
incriminato o se è un altro il motivo
(ad esempio la pacchettizzazione debian, poiché la linea
/home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openldap2.3-2.4.7/servers/slapd/schema_init.c:366:
mi è un po' sospetta...).


Mi sembra che il problema non sia presente nel 2.4.9 (ma non conosco i 
dettagli dell'operazione che hai eseguito).  Puoi verificare?  Il 
problema e' legato al fatto che la routine di indicizzazione 
dell'attributo (e' indicizzato, vero?) viene chiamata passandogli 
un'array di valori vuota, il che e' (dovrebbe essere) impossibile, da 
cui l'asserzione.  Siccome dalla 2.4.7 alla 2.4.9 ci sono state un certo 
numero di modifiche (almeno 60 bugfixes, a occhio), puo' darsi che la 
cosa sia stata nel frattempo corretta.


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] meta-back: dove sbaglio?

[Pierangelo Masarati]

Vittore Zen wrote:

Scusate l'insistenza ma non riesco a capire dove sbaglio. Mi sono
letto il man riferito ad idassert-bind e riletto il slapd-meta(5)

Ricapitolo TUTTI i passi:

1. creato un account su AD (ldap-proxy) con diritti amministrativi (è
la copia dell'utente Administrator del dominio AD)
2. Se digito (quindi interrogando direttamente ldap di MS AD):
ldapsearch -h srv1.domA.mydom.it -x -D
"cn=ldap-proxy,cn=Users,dc=domA,dc=mydom,dc=it" -w SECRET-pass  -b
"dc=domA,dc=mydom,dc=it" -LLL

ottengo correttamente il browsing del dominio AD

3. installato openLDAP
4. configurato come segue slapd.conf

database meta
suffix   dc=domA,dc=mydom,dc=it
uri  ldap://srv1.domA.mydom.it/dc=srv1,dc=domA,dc=mydom,dc=it
idassert-bind  bindmethod=simple
   binddn="cn=ldap-proxy,cn=Users,dc=srv1,dc=domA,dc=mydom,dc=it"
   credentials="SECRET-pass"


Il binddn indicato qui e' diverso da quello che usi con ldapsearch.



Se digito:
 ldapsearch -h localhost -x -D
"cn=ldap-proxy,cn=Users,dc=domA,dc=mydom,dc=it" -w SECRET-pass  -b
"dc=domA,dc=mydom,dc=it" -LLL
Ottengo:

ldap_bind: Invalid credentials (49)


Il debug di slapd -d 4 è il seguente:

connection_get(9)
=> ldap_bv2dn(cn=ldap-proxy,cn=Users,dc=domA,dc=mydom,dc=it,0)
<= ldap_bv2dn(cn=ldap-proxy,cn=Users,dc=domA,dc=mydom,dc=it)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(cn=ldap-proxy,cn=Users,dc=domA,dc=mydom,dc=it)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(cn=ldap-proxy,cn=users,dc=domA,dc=mydom,dc=it)=0
conn=0 op=0 meta_back_bind: dn="cn=ldap-proxy,cn=Users,dc=domA,dc=mydom,dc=it".
conn=0 op=0 meta_back_bind: no target for dn
"cn=ldap-proxy,cn=Users,dc=domA,dc=mydom,dc=it" (32. No suitable
candidate target found).
send_ldap_result: err=49 matched="" text=""
connection_get(9)


Il problema e' chiaramente indicato nel log: la tua configurazione non 
e' in grado di trovare un target adatto al DN 
"cn=ldap-proxy,cn=Users,dc=domA,dc=mydom,dc=it", perche' l'unico target 
definito ha come suffisso "dc=srv1,dc=domA,dc=mydom,dc=it" (la perte DN 
dell'URI), e il DN "cn=ldap-proxy,cn=Users,dc=domA,dc=mydom,dc=it" non 
sta sotto questo suffisso, mentre sta sotto il suffix del proxy.  Quindi 
questo DN appartiene al naming context del proxy, ma e' sconosciuto, e 
la risposta corretta in questo caso e' "credenziali invalide".


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] meta-back: dove sbaglio?

[Pierangelo Masarati]

Vittore Zen wrote:

Giusto.
Dovrei usare pseudorootdn e pseudorootpw?

Oppure è meglio passare le credenziali della richiesta?


Devi usare idassert-bind.

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] meta-back: dove sbaglio?

[Pierangelo Masarati]

Vittore Zen wrote:

2008/5/13 Pierangelo Masarati <[EMAIL PROTECTED]>:

Vittore Zen wrote:


sto tentando di configurare meta-back per far vedere un dominio MS Active
directory.


Quale versione di slapd?




OpenLDAP: slapd 2.3.39





Questo è il file slapd.conf:

database meta
suffix   dc=domA,dc=mydom,dc=it
uri  
ldap://srv1.domA.mydom.it/dc=srv1,dc=domA,dc=mydom,dc=it<http://srv1.doma.mydom.it/dc=srv1,dc=domA,dc=mydom,dc=it>


Questo URI mi sembra quanto meno un po' fantasioso: che c'entra la parte 
 ?


Ehm copia e incolla :-(

uri  ldap://srv1.domA.mydom.it/dc=srv1,dc=domA,dc=mydom,dc=it






binddn   cn=ldap-proxy,cn=Users,dc=srv1,dc=domA,dc=mydom,dc=it
bindpw   SECRET-pass



ldap-proxy è un utente con diritti di fare il browsing di AD

Se bypasso il proxy e do:

ldapsearch -h srv1.domA.mydom.it -x -D
"cn=ldap-proxy,cn=Users,dc=domA,dc=mydom,dc=it" -w SECRET-pass  -b
"dc=domA,dc=mydom,dc=it" -LLL


ottengo esattamente quello che voglio (cioè LDAP di AD).

:-(


Attenzione: binddn e bindpw non vengono usati come credenziali per ogni 
operazione.  Questo e' spiegato chiaramente nella man page.  Sono 
parametri (obsoleti) usati internamente per autenticarsi al fine di 
valutare informazioni per le ACL.  Quello che tu fai con la 
configurazione attuale e' una richiesta anonima.  Questo potrebbe 
spiegare la failure.


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] meta-back: dove sbaglio?

[Pierangelo Masarati]

Vittore Zen wrote:

sto tentando di configurare meta-back per far vedere un dominio MS Active
directory.


Quale versione di slapd?


Questo è il file slapd.conf:

database meta
suffix   dc=domA,dc=mydom,dc=it
uri  
ldap://srv1.domA.mydom.it/dc=srv1,dc=domA,dc=mydom,dc=it<http://srv1.doma.mydom.it/dc=srv1,dc=domA,dc=mydom,dc=it>


Questo URI mi sembra quanto meno un po' fantasioso: che c'entra la parte 
 ?



binddn   cn=ldap-proxy,cn=Users,dc=srv1,dc=domA,dc=mydom,dc=it
bindpw   SECRET-pass


Occhio che binddn/bindpw probabilmente non fanno quello che ti aspetti.


lastmod  off


Questo parametro non e' necessario, in quanto lastmod e' off di default


Quando faccio:

ldapsearch -H ldap://localhost -x  -b "dc=domA,dc=mydom,dc=it" -LLL

Ottengo:

No such object (32)
Matched DN: dc=domA,dc=mydom,dc=it


Questo è il debug di slapd:



slap_listener(ldap:///)

connection_get(11): got connid=7
connection_read(11): checking for input on id=7
ber_get_next
ber_get_next: tag 0x30 len 12 contents:
do_bind
ber_get_next
ber_scanf fmt ({imt) ber:
ber_scanf fmt (m}) ber:

dnPrettyNormal: <>

<<< dnPrettyNormal: <>, <>
do_bind: version=3 dn="" method=128
send_ldap_result: conn=7 op=0 p=3
send_ldap_response: msgid=1 tag=97 err=0
ber_flush: 14 bytes to sd 11
do_bind: v3 anonymous bind
connection_get(11): got connid=7
connection_read(11): checking for input on id=7
ber_get_next
ber_get_next: tag 0x30 len 67 contents:
do_search
ber_scanf fmt ({mb) ber:

dnPrettyNormal: 

<<< dnPrettyNormal: , 
ber_scanf fmt (m) ber:
ber_scanf fmt ({M}}) ber:
==> limits_get: conn=7 op=1 dn="[anonymous]"
conn=7 op=1: meta_back_getconn[0]
conn=7 op=1 meta_back_getconn: candidates=1 conn=-3 fetched
conn=7 op=1 >>> meta_back_search_start[0]
conn=7 op=1 >>> meta_search_dobind_init[0]
conn=7 op=1 <<< meta_search_dobind_init[0]=1
ldap_search_ext
put_filter: "(objectClass=*)"
put_filter: simple
put_simple_filter: "objectClass=*"
ldap_send_initial_request
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({) ber:
ber_flush: 79 bytes to sd 12
conn=7 op=1 <<< meta_back_search_start[0]=1
conn=7 op=1 meta_back_search: ncandidates=1 cnd="*"
ldap_result ld 0x8241040 msgid 7
ldap_chkResponseList ld 0x8241040 msgid 7 all 2
ldap_chkResponseList returns ld 0x8241040 NULL
wait4msg ld 0x8241040 msgid 7 (timeout 0 usec)
wait4msg continue ld 0x8241040 msgid 7 all 2
** ld 0x8241040 Connections:
* host: srv1.domA.mydom.it <http://srv1.doma.mydom.it/>  port: 389
(default)
  refcnt: 2  status: Connected
  last used: Mon May 12 09:57:48 2008

** ld 0x8241040 Outstanding Requests:
 * msgid 7,  origid 7, status InProgress
   outstanding referrals 0, parent count 0
** ld 0x8241040 Response Queue:
   Empty
ldap_chkResponseList ld 0x8241040 msgid 7 all 2
ldap_chkResponseList returns ld 0x8241040 NULL
ldap_int_select
read1msg: ld 0x8241040 msgid 7 all 2
ber_get_next
ber_get_next: tag 0x30 len 164 contents:
read1msg: ld 0x8241040 msgid 7 message type search-result
ber_scanf fmt ({eaa) ber:
read1msg: ld 0x8241040 0 new referrals
read1msg:  mark request completed, ld 0x8241040 msgid 7
request done: ld 0x8241040 msgid 7
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 7, msgid 7)
ldap_free_connection 0 1
ldap_free_connection: refcnt 1
ldap_parse_result
ber_scanf fmt ({iaa) ber:
ber_scanf fmt (}) ber:
ldap_err2string
conn=7 op=1 meta_back_search[0] match="DC=domA,DC=mydom,DC=it" err=32 (No
such object).


Questo messaggio sembra indicare che "DC=domA,DC=mydom,DC=it" non esiste 
sull'AD a cui viene inoltrata la richiesta.  Hai provato ad eseguire 
l'operazione a mano con ldapsearch, bypassando il proxy?  Che cosa ne 
risulta?



ldap_msgfree

dnPretty: 

<<< dnPretty: 
send_ldap_result: conn=7 op=1 p=3
send_ldap_response: msgid=2 tag=101 err=32
ber_get_next
ber_flush: 44 bytes to sd 11
connection_get(11): got connid=7
connection_read(11): checking for input on id=7
ber_get_next
ber_get_next: tag 0x30 len 5 contents:
do_unbind
ber_get_next
connection_closing: readying conn=7 sd=11 for close
connection_resched: attempting closing conn=7 sd=11
connection_close: conn=7 sd=11
=>meta_back_conn_destroy: fetching conn=7 DN=""


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] slapd & pam or password back-end

[Pierangelo Masarati]

Giuseppe "Gippa" Paterno' wrote:

Ciao a tutti! Sempre inerente al tema che vi ho sottoposto qualche
giorno fa, volevo capire con voi se:
1) esisteva un password back-end di tipo PAM (cioe' usa PAM per la sola
autenticazione)


Ovvero, usare PAM per l'autenticazione e per il resto un database locale 
tipo back-bdb?  La soluzione normale consiste nell'usare un database 
normale, tipo back-bdb, in cui le password abbiano il valore


userPassword: {SASL}userid

dove userid e' l'id dello user che verrebbe passato a PAM.  A questo 
punto, si configura slapd per usare SASL (credo che il file sia 
/usr/lib/sasl2/Slapd.conf, ma non sono sicuro se Slapd.conf abbia la 
maiuscola o meno) per puntare a PAM usando saslauthd (un po' barocco, ma 
e' la cosa piu' pulita).



2) Nel caso non esista, se era possibile creare uno script (python,
perl) per gestire solo l'autenticazione


Un'alternativa, piu' che uno script e' un overlay che intercetti solo 
l'autenticazione, ovvero l'operazione di bind (nel momento in cui si non 
sia prevista la possibilita' di cambiare la password via LDAP, 
altrimenti le cose sono un filino piu' complesse).  Qualcosa del genere 
credo che sia gia' stato postato sulla lista LDAP, e comunque e' 
abbastanza semplice da fare.  Si potrebbe fare anche in PERL se fosse 
disponibile il generico overlay PERL (di cui si e' parlato ma che non 
credo che esista).


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] Continuo ricerca ... (era openldap e AD)

[Pierangelo Masarati]

Giuseppe "Gippa" Paterno' wrote:


L'uso di slapo-rwm assieme a slapo-translucent potrebbe essere
"instabile", specialmente in OpenLDAP 2.3.

Me ne sono accorto ... :-D Ogni due query, mi veniva fuori un bel segfault.
Vi faccio sapere con la 2.4 come va 


Nel 2.3 non c'e' speranza: l'unica soluzione sarebbe importare slapo-rwm 
da 2.4 a 2.3, ma non e' possibile perche' ci sono troppe differenze 
nelle strutture dati interne e nell'API di slapd.


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] Continuo ricerca ... (era openldap e AD)

[Pierangelo Masarati]

Giuseppe "Gippa" Paterno' wrote:
Prima che mi risponda qualcuno, sto tentando di usare l'overlay 
translucent... non so se e' la strada giusta.


Potrebbe.  In OpenLDAP 2.3, l'overlay translucent consente di avere, per 
entries remote (su AD, nel tuo caso) un po' di attributi aggiuntivi 
(ovvero non gia' presenti in remoto) messi nel database locale.  Questi 
attributi vengono aggiunti alle entry che ti sono ritornate da una 
richiesta dirottata sul server remoto.  Questo significa che attributi 
locali nel filtro non vengono usati nella ricerca.


In OpenLDAP 2.4 questa limitazione e' stata rimossa, previa 
configurazione di quali attributi devono essere considerati locali e/o 
remoti nel filtro.



Ho un AD a casa e una VM con OpenLDAP 2.3.39 ricompilato.
Sono riuscito a fare queries sul mio active directory, ma sembra che 
"translucent" non digerisca le modifiche:


 

ldapmodify -h 172.16.168.129 -x -W -D 
"cn=Administrator,cn=Users,dc=garl,dc=it"

Enter LDAP Password:
dn: cn=Mario Rossi,cn=Users,dc=garl,dc=it
changetype: add
add: homeDirectory
homeDirectory: /home/mrossi

adding new entry "cn=Mario Rossi,cn=Users,dc=garl,dc=it"
ldap_add: Undefined attribute type (17)
   additional info: add: attribute type undefined
 


Questo credo che non c'entri niente con slapo-translucent; probabilmente 
l'attributo "homeDirectory" non e' definito.  Hai incluso "nis.schema"?


In realta' ho anche fatto un slapadd con le modifiche che mi servivano, 
e mi fa il merge delle informazioni...

pero' non posso farlo ogni volta a mano da slapadd 
Questo il mio slapd.conf:

 


include/usr/local/ldap/etc/openldap/schema/core.schema
include/usr/local/ldap/etc/openldap/schema/cosine.schema
include/usr/local/ldap/etc/openldap/schema/inetorgperson.schema
include/usr/local/ldap/etc/openldap/schema/nis.schema

databaseldbm
suffix"dc=garl,dc=it"
rootdn"cn=Administrator,cn=Users,dc=garl,dc=it"
rootpwadministrator

overlay translucent
uri"ldap://10.10.10.10/";
idassert-bind bindmethod=simple 
binddn="CN=proxyuser,CN=Users,DC=garl,DC=it" credentials="proxyuser"

lastmodoff
overlay rwm


L'uso di slapo-rwm assieme a slapo-translucent potrebbe essere 
"instabile", specialmente in OpenLDAP 2.3.  Ti consiglio caldamente di 
provare OpenLDAP 2.4, nel quale slapo-rwm e' stato ampiamente riscritto.


Cosi' a caldo non ti so dire se la cosa e' risolutiva, ma potrebbe 
essere un problema.



rwm-map objectclass * *
rwm-map attribute cn cn
rwm-map attribute sn sn
rwm-mapattribute samaccountname uid
#rwm-mapattribute *
directory/usr/local/ldap/var/openldap-data
indexobjectClasseq
 


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] superuser per piu' di un database.

[Pierangelo Masarati]

Mauro Sanna wrote:


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.


Vengono usati per inizializzare il database secondo la configurazione 
che Debian ritiene standard.



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.


Per scrivere in un database devi avere il permesso di farlo.  Lo puoi 
fare in molti modi:


- usando slapadd (a server fermo): in questo caso sei autorizzato dal 
filesystem, nel momento in cui hai permesso di scrittura sui files.  Non 
so come funzioni Debian di default, ma occhio alla file ownership se fai 
slapadd come root e poi esegui slapd con un altro utente;


- abilitando il rootdn;

- se vuoi restare fedele a Debian, abilitando il rootdn solo per il 
tempo necessario a creare l'utente amministratore, avendo cura di dare a 
tale utente privilegi illimitati tramite le ACL (copia dal database 
creato automaticamente da Debian), e poi commentando il rootdn;


- se ti va bene che l'amministratore dei due database sia lo stesso , 
pui semplicemente defire le ACL del nuovo database in modo che 
l'amministratore del primo database abbia privilegi illimitati anche sul 
secondo database.


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

[Pierangelo Masarati]

Enrico Albertini wrote:

Salve, sono Enrico Albertini.

Scrivo per chiedere aiuto. Il mio problema riguarda l'iserimento di una 
entry nella mia directory ldap. Devo realizzare un'interfaccia web in 
php che permetta di inserire un nuovo utente nella directory.


Gli schemi inportati nel file slapd.conf sono:

# Schema and objectClass definitions
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/samba.schema
include /etc/ldap/schema/krb5-kdc.schema



mentre il codice php che genera l'entry e la inserisce nella directory è:

$ldapConn = @ldap_connect( $LDAPServerName );

if( $ldapConn ) {
 @ldap_set_option( $ldapConn, LDAP_OPT_PROTOCOL_VERSION, 3 );
   @ldap_set_option( $ldapConn, LDAP_OPT_REFERRALS, 0 );
   $r = @ldap_bind( $ldapConn, $LDAPWriterDN, $LDAPWriterPassword );

   // Set up LDAP attributes
   $values["objectClass"] = "top";
   $values["objectClass"] = "person";
   $values["objectClass"] = "organizationalPerson";
   $values["objectClass"] = "inetOrgPerson";
   $values["objectClass"] = "posixAccount";
   $values["objectClass"] = "krb5Principal";
   $values["objectClass"] = "shadowAccount";


A occhio, senza essere un esperto di PHP, stai assegnando a 
$values["objectClass"], ovvero allo stesso elemento dell'array values 
valori diversi, ma alla fine l'ultimo e' l'unico che rimane.  Siccome 
"shadowAccount" non e' objectClass strutturale, ecco l'errore.




   $values["uid"] = $username;
   $values["cn"] = $realname . " " . $realsurname;
   $values["givenName"] = $realname;
   $values["sn"] = $realsurname;
   $values["mail"] = $mail;
   $values["shadowLastChange"] = (int)(time() / 86400);
   $values["shadowMax"] = 9;
   $values["shadowWarning"] = 7;
   $values["krb5PrincipalName"] = $username . "@DOMINIO.IT";
   $values["loginShell"] = "/bin/false";
   $values["uidNumber"] = 1001;
   $values["gidNumber"] = 1001;
   $values["homeDirectory"] = "/home/" . $username ;
   $values["gecos"] = $realname . " " . $realsurname;
   $values["userPassword"] = $password;


   $userDN = $LDAPSearchAttribute . "=" . $username . "," . 
$LDAPWriteLocation;


   $r = @ldap_add( $ldapConn, $userDN, $values );
 if ( $r ) {
  $UserIsRegister = true;
   } else {
  $UserIsRegister = false;
   }

   @ldap_close( $ldapConn );
}



L'inserimento non funziona, riporto la parte interessata del file di log:

Mar 25 18:53:41 server5 slapd[4181]: conn=72 fd=15 ACCEPT from 
IP=***.***.***.***:45428 (IP=***.***.***.***:389)
Mar 25 18:53:41 server5 slapd[4181]: conn=72 op=0 BIND 
dn="cn=admin,dc=dominio,dc=it" method=128
Mar 25 18:53:41 server5 slapd[4181]: conn=72 op=0 BIND 
dn="cn=admin,dc=dominio,dc=it" mech=SIMPLE ssf=0

Mar 25 18:53:41 server5 slapd[4181]: conn=72 op=0 RESULT tag=97 err=0 text=
Mar 25 18:53:41 server5 slapd[4181]: conn=72 op=1 ADD 
dn="uid=prova,ou=People,dc=dominio,dc=it"
Mar 25 18:53:41 server5 slapd[4181]: conn=72 op=1 RESULT tag=105 err=65 
text=no structural object class provided

Mar 25 18:53:41 server5 slapd[4181]: conn=72 op=2 UNBIND
Mar 25 18:53:41 server5 slapd[4181]: conn=72 fd=15 closed


Io proprio non sono riuscito a capire dove sbaglio, mi rivolgo a voi 
sperando che mi possiate aiutare dall'alto della vostra esperienza.


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] Richiesta aiuto X.509

[Pierangelo Masarati]

Luca Scamoni wrote:


Secondo me solo certificateListValidate


Giusto.  Come regola di confronto di quella RFC e' implementata solo 
certificateExactMatch, mentre certificatePairExactMatch, 
certificatePairMatch, certificateListExactMatch, certificateListMatch 
sono pending.  Se vuoi farti avanti...


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] Richiesta aiuto X.509

[Pierangelo Masarati]

Luca Scamoni wrote:


Secondo me solo certificateListValidate


Giusto.  E' come regola di confronto di quella RFC e' implementata solo 
certificateExactMatch, mentre certificatePairExactMatch, 
certificatePairMatch, certificateListExactMatch, certificateListMatch 
sono pending.  Se vuoi farti avanti...


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] Re: OpenLDAP proxy

[Pierangelo Masarati]

fabio tonon wrote:

Ciao a tutti, mi spiego meglio
quello che vorrei fare è chiedere alla mia base LDAP un dato (un
sAMAccountName per esempio) che è presente sulla  base dati referenziata
tramite tutte le direttive descritte sotto.

Spero si possa...

2008/3/18, fabio tonon <[EMAIL PROTECTED]>:

Ciao a tutti, ho seguito how to e tutto quello che potevo trovare...ma
niente!
Ho un LDAP del tipo dc=nodomain, dc=local. Voglio che OpenLDAP agisca da
LDAP proxy e per questo ho inserito in slapd.conf:

database ldap
lastmod off
chase-referrals no
suffix "dc=xxx,dc=local"
uri "ldap://192.168.43.2:389/";
idassert-bind
bindmethod=simple
binddn="cn=ciccio,cn=Users,dc=xxx,dc=local"
credentials="lapassword"
mode=anonymous
idassert-authzFrom "dn.regex:.*"

overlay rwm
rwm-map objectclass  account user
rwm-map attributeuid sAMAccountname
rwm-map attributecn  name
rwm-map attributesn  sn
rwm-map attributemailmail
rwm-map attributecompany company
rwm-map attributeentry   entry
rwm-map attribute*


Ma quando faccio una query al dominio locale con un account dell'AD
xxx.local non mi restituisce niente!!!

Cosa sbaglio?? è da 1 settimana che ci lavoro dietro.
Un saluto a tutti!


Non e' molto chiaro che cosa tu intenda fare, ne' quale sia il vero 
problema.  Innanzitutto, sei sicuro che l'operazione che cerchi di fare 
sia possibile?  Hai provato ad eseguirla con ldapsearch?  Nel caso, ti 
ritorna il risultato atteso?  Se si', allora puoi passare a riprodurla 
attraverso il proxy.  Se il problema, come sempre, e' che AD richiede 
l'autenticazione, e tu vuoi bypassarla attraverso il proxy, allora devi 
usare il mode="none", non "anonymous" che fa l'esatto contrario.


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] Richiesta aiuto X.509

[Pierangelo Masarati]

Luca Scamoni wrote:

[EMAIL PROTECTED] wrote:

Salve,
sono uno studente della facolta' di informatica dell'universita' di 
Napoli

Federico II.
Come lavoro di tesi dovrei aggiungere ad ldap il supporto per gli 
attribute

certificate.
Ho pero' un problema, non so come inserire in ldap una nuova sintassi.
Ho installato la versione 2.4.8 di openldap e ho modificato il 
core.schema,
  

Errore! Mai, dico mai, modificare gli schemi standard!
sostituendo le sintassi per i certificati public-key con quelle 
definite da
Zeilenga in rfc4523, ma andando a lanciare slapdtest ho il seguente 
errore:


/opt/openldap/etc/openldap/schema/core.schema: line 283 attributetype:
MatchingRule not found: "certificateListExactMatch"

Qualcuno mi puo' indicare da dove posso partire?
  
Temo che tu debba partire dal codice. Se la matching rule non e' 
codificata devi innanzitutto aggiungere le routine di trattamento nel 
codice di slapd. (schema_init.c)

Spero di non essere uscito troppo dall'ambito della lista.


Se non sbaglio, quelle regole sono gia' implementate in OpenLDAP 2.4.

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 Proxy

[Pierangelo Masarati]

fabio tonon wrote:
> Ciao,
> la mia intenzione è che l'autenticazione riesca su 1 ldap di frontend e che
> questo dietro abbia n ldap (AD) di backend del tutto spaiati tra loro (non
> si conoscono, nè sono trustati...sono indipendenti)...
> 
> Pensavo di aver capito ma...niente non ci riesco. Penso di essere ottuso.
> Potresti gentilmente farmi capire come devo strutturare la cosa?
> 
> 2008/3/15, Pierangelo Masarati <[EMAIL PROTECTED]>:
>> fabio tonon wrote:
>>
>>> grazie per la risposta, 6 stato veramente celere ed esaustivo.
>>
>> Per favore, tieni in copia la lista.

Insisto: PER FAVORE TIENI IN COPIA LA LISTA.

Qual'e' il problema esatto?  Puoi circoscrivere?  Se riesci a fare la
ricerca a mano con ldapsearch verso AD dalla macchina su cui e' attivo
il proxy ci deve riuscire anche il proxy.

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 Proxy

[Pierangelo Masarati]

fabio tonon wrote:

> grazie per la risposta, 6 stato veramente celere ed esaustivo.

Per favore, tieni in copia la lista.

> In poche parole (spero...) io ho un sw antispam che va a bindare un LDAP per
> fare entrare l'utente in una pagina web dove può gestire la quarantena delle
> mail.
> Da lì l'utente può scegliere se rilasciare o cancellare le mail.
> Quindi se non ho capito male:
> Uso il metodo back-ldap quindi:
> -Compilo solo con --enable-ldap e, nel file slapd.conf definisco tutti i db
> remoti con una dicitura del tipo:
> 
> database ldap
> suffix ou=users,dc=esempio,dc=it
> uri ldap://esempio.it

si

> binddn cn=pippo,cn=users,dc=esempio,dc=it
> bindpw password

Queste istruzioni non sono piu' supportate perche' facevano qualcosa di
diverso da quello che probabilmente intendi tu.  Se la tua intenzione e'
fare si' che il proxy si autentichi prima di fare le ricerche occorre
qualcosa di diverso.  Vedi "idassert-bind" in slapd-ldap(5).

> 
> e così per ogni ldap remoto??
> Dalla query deve solo ritornarmi l'indirizzo email corrispondente al
> sAMAccountName immesso

Si.

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 Proxy

[Pierangelo Masarati]

fabio tonon wrote:
> Ciao a tutti.
> 
> Mi chiamo Fabio. E' la prima volta che scrivo..(abbiate pazienza sono un
> very very neofita..).
> Allora ho un dubbio amletico che mi perseguita:
> Ho un applicazione che antispam. Ho diverse fonti LDAP (purtroppo sono tutte
> AD).
> Ecco allora il query filter è il sAMAccountname e il risultato della query
> deve esser il campo mail
> 
> Io pensavo di costruire un albero LDAP con OpenLDAP e far puntare questo a
> diversi alberi AD (su diversi naming context ... ovvero domini differenti
> tutti raggiungibili tramite porta 389).
> 
> Ho letto della possibilità di compilare openldap con le opzioni
> --enable-rewrite e --enable-ldap.
> Non so se mi sono spiegato bene ma la mia domanda è: si può fare?

Si.  In due modi:

1) back-meta: basta che compili con --enable-meta.
2) back-ldap (ed eventualmente "subordinate"): basta che compili con
--enable-ldap

Poi occorre capire bene che cosa ti serve: se il client cerca gia' con
sAMAccountName nel filtro, e se ti va bene che i diversi alberi AD si
presentino con il loro namingContext e tutto cio' che ti serve, al piu',
e' che sia possibile con una sola ricerca trovare un sAMAccountName
indipendentemente da quale AD lo ospita, allora ci vuole qualche
accorgimento in piu'

1) back-meta:

occorre definire come suffix il minimo comun denominatore tra i
namingContext; alla peggio la entry vuota.  Se per esempio hai
"dc=esempio,dc=it" e "dc=prova,dc=it" allora basta

suffix  "dc=it"

se invece hai "dc=esempio,dc=it" e "dc=example,dc=com" allora occorre

suffix  ""

quindi definisci tanti "uri" quanti sono gli AD, ognuno con

uri "ldap://ldap.esempio.it/dc=esempio,dc=it";

uri "ldap://ldap.prova.it/dc=prova,dc=it";

2) back-ldap:

se non ti serve la possibilita' di cercare con una sola operazione in
tutti i database basta che definisci un database ldap per ogni AD.

Se invece ti serve poter cercare tutti i database con una sola
operazione occorre innanzitutto capire qual'e' il minimo comun
denominatore, come prima.  Quindi, occorre definire un database locale
che lo contiene (ad esempio, un back-bdb).  Infine, occorre definire i
database remoti, aggiungendo ad ognuno "subordinate" e per ultimo il
database locale, che va popolato con le entry di ricucitura fino ai
database locali.  Per esempio,

databaseldap
suffix  "dc=esempio,dc=it"
subordinate
uri "ldap://ldap.esempio.it";

databaseldap
suffix  "dc=example,dc=com"
subordinate
uri "ldap://ldap.example.com";

databasebdb
suffix  ""

Il database va quindi popolato con le entries

dn: dc=it
objectClass: domain
dc: it

dn: dc=com
objectClass: domain
dc: com

Se invece dovesse occorrere anche una riscrittura di namingContext o di
attributi allora la cosa si complica un po', e occorre --enable-rewrite.

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] Strano comportamento anonymuos bind

[Pierangelo Masarati]

Stefanelli Mirko wrote:
> Ciao,
> 
> Nel nostro ambiente di esercizio la versione openLdap attualmente installata 
> a la 2.3.39 e S.O. 5.9.
> 
> Durate delle prove di vulnerabiltà abbiamo verificato che alcuni client ldap 
> (ad esempio: Solaris 5.10 e HP 11.11) riescono ad ottente informzioni dal 
> server ldap effettuando ricerche anonime (anonymous bind?), anche se nel file 
> slapd.conf è presente la direttiva:
> 
> disallow bind_anon
> 
> ad esempio:
> 
> ldapsearch -h master -p 389 -b 
> "ou=pocascms,ou=dc_pomezia,dc=,dc=x,dc=Xxxx" 'objectClass=*'
> 
> una query di questo tipo effettuata da un sistema linux (Fedora 8) 
> restiruisce la seguente risposta:
> 
> ldap_bind: Inappropriate authentication (48)
> additional info: anonymous bind disallowed
> 
> Mentre eseguendola da uno dei sistemi Solaris 5.10 e/o HP 11.11 sono visibili 
> tutti gli attributi presente sotto il ramo.

Da slapd.conf(5) di OpenLDAP 2.3:

   disallow 
  Specify a set of features (separated by white space) to
  disallow (default none).  bind_anon disables acceptance of
  anonymous bind requests.  Note that this setting does not
  prohibit anonymous directory access (See "require authc").

Questo significa che bind_anon non consente il bind anonimo, ovvero
l'operazione di bind con credenziali vuote.  LDAPv3 vuole che la prima
operazione sia una bind, anche anonima, infatti il client OpenLDAP e'
educato e lo fa, da cui il comportamento che noti.  Invece il client
Solaris, che evidentemente non e' LDAPv3 compliant, se non specifichi le
credenziali non fa la bind, e quindi passa.  Devi usare "require authc"
per ottenere l'effetto desiderato.

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] Lista utenti per server proxy

[Pierangelo Masarati]

Per favore, mantieni la lista in CC

Teddy Bonanno wrote:
> Le informazioni richieste dal server proxy, per la connessione e la
> configurazione con il server LDAP sono: Base DN, LDAP Type, IP, Port,
> un gruppo, User per il bind e la relativa pass.
> 
> E poi l'username e la password dei vari utenti, che verranno
> richieste dalle varie applicazioni che necessatano un'
> autenticazione.
> 
> In funzione di queste richieste, e aggiungendo che voglio fare una
> cosa molto semplice (senza ampliarla), mi consigli di lasciarlo così
> o di passare a 'inetOrgPerson' con aggiunto 'posixAccount' ?

Da RFC 4524:

3.1.  account

   The 'account' object class is used to define entries representing
   computer accounts.  The 'uid' attribute SHOULD be used for naming
   entries of this object class.

  ( 0.9.2342.19200300.100.4.5 NAME 'account'
SUP top STRUCTURAL
MUST uid
MAY ( description $ seeAlso $ l $ o $ ou $ host ) )

Se ti sta bene, non c'e' problema.  Questo pero' non risolve il problema
che hai nel creare nuovi account con phpldapadmin; puoi postare i log
del server?

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] Lista utenti per server proxy

[Pierangelo Masarati]

Teddy Bonanno wrote:
> Salve a tutti.
> 
> Le mie intenzioni sono quelle di mantenere la lista utenti del mio
> server-proxy (IPCop), per il login a esso, su un server LDAP.
> 
> Ho già realizzato un server OpenLDAP su un sistema ubuntu,
> trattandosi di una sorta di accaunting, ho realizzato il seguente
> albero.
> 
> 
> dc=esempio, dc=it  ( objectClass: dcObjectobjectClass:
> organizationalUnit   ou: rootobject)
> 
> ou=utenti(objectClass: organizationalUnit)
> 
> uid=  ( objectClass: account  objectClass: posixAccount  objectClass:
> top  objectClass: shadowAccount )
> 
> Per testarne il funzionamento ho utilizzato un client grafico
> phpldapadmin, riesco a leggere l'albero anche da una macchina diversa
> da quella locale, riesco a fare il bind come amministratore, riesco
> ad aggiungere nuove organizationalUnit, ma non riesco ad aggiungere
> nuovi utenti (uid) tranne che con il comando ldapadd e il relativo
> file LDIF. Adesso mi chiedo se è normale o se è un anomalia, se il
> problema è del server o del client grafico ( me ne consigliate un'
> altro ?).

A occhio il problema e' del client, dal momento che con ldapadd
funziona.  Anziche' cambiare client, forse conviene prima capire che
cosa non va, ad esempio guardando i log del server.  Il livello "stats"
dovrebbe gia' consentire di capire qual'e' il problema.

> Prima di tentare la connessione fra il mio server proxy e il server
> LDAP, vorrei sapere se il lavoro svolto fin ora può andar bene,
> 
> quindi se la struttura che ho realizzato è adatta ( contiene le
> informazioni necessarie) per la gestione utenti di un server proxy.

Forse la scelta di 'account' come classe strutturale degli utenti non e'
delle piu' felici, era meglio 'inetOrgPerson' con aggiunto
'posixAccount', a meno che gli attributi previsti da 'account' siano
sufficienti per quello che intendi fare, e non intenda sviluppare
ulteriormente il tuo sistema (tipo usare il Directory Server anche per
altri scopi).

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] anomalia negli schema

[Pierangelo Masarati]

Carlo Truijllo wrote:
> Ciao
> sto lavorando per la migrazione di una directory da iPlanet ad OpenLDAP cosi' 
> sono a stretto contatto con gli schema di entrambe.
> 
> 
> su iPlanet per l'objectClass oncRpc ho 
> MUST : 
>   objectclass
>   cn
>   onrpcnumber
> MAY:
>   description
> 
> 
> mentre sull'installazione di openldap 2.3.35 ho
> 
> MUST: 
>   cn
>   onrpcnumber
>   description
> MAY:
>   description
> 
> 
> Quello che mi lascia perplesso non e' tanto la presenza di objectClass negli 
> attributi MUST di iPlanet ( evidentemente lo vuole specificato cosi' )

"objectClass" e' MUST in "top", e siccome tutte le objectClass
discendono direttamente o indirettamente da "top" mettere "objectClass"
come MUST e' pleonastico e innocuo, in quanto non puo' in alcun modo
alterare la definizione di una classe.

> quanto la doppia presenza di "description" su openldap sia su MUST che su 
> MAY ...
> 
> ho controllato e questa anomalia figura sin dalle versioni di openLDAP del 
> 2002, anno in cui ho avuto il primo impatto col sistema.
> 
> Esiste un reale motivo per tenere questo doppio valore ?

E' sicuramente un errore, ma e' presente anche nell'RFC2307, da cui lo
schema e' tratto "verbatim".  OpenLDAP distribuisce solo schema presente
in standard track documents, e esattamente nella forma specificata, a
meno che non ci siano ragioni tecniche transitorie (tipo funzionalita'
non supportate o errori che impediscono il funzionamento).  Diciamo che
in questo caso l'errore e' veniale, ovvero "description" e' MUST e
basta, in quanto MUST vince su MAY.

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

[Pierangelo Masarati]

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

[Pierangelo Masarati]

Andrea Cirulli wrote:
> Ciao,
> 
> Ho un istanza openldap di questo tipo
> 
> dc=example,dc=com
> -ou=dc_server1
> -ou=dc_server2
> -ou=dc_server3
> -ou=dc_server4
> -ou=informazioni
> -ou=amministratori
> -ou=web
>  |--ou=persone
>  |uid=pippo
>  |uid=pluto
>  |uid=paperino
>  |--ou=gruppi
>  |--ou=database
> 
> Devo definire una acl che permetta agli utenti sotto
> ou=persone,ou=web,ou=example,ou=com di vedere solo le proprie entry. Per
> esempio
> pippo deve essere in grado di leggere solo
> uid=pippo,ou=persone,ou=web,ou=example,ou=com e così per tutti gli utenti
> sotto il ramo ou=persone.
> 
> Dopo un po' di tentativi quello che sono riuscito ad ottenere è solo che gli
> utenti possano vedere tutti gli uid sotto il ramo persone.
> Qualcuno ha qualche suggerimento per una ACL con espressioni regolari che
> permetta di ottenere quanto detto sopra??

access to \
dn.regex="(.+,)?(uid=[^,]+,ou=persone,ou=web,ou=example,ou=com)$"
  by dn.expand="$2" read

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

[Pierangelo Masarati]

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] OpenLDAP + stunnel

[Pierangelo Masarati]

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] Cambio di parametri operativi di slapd tramite cn=config

[Pierangelo Masarati]

Michele Codutti wrote:
>> 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?

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.

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

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.

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] Cambio di parametri operativi di slapd tramite cn=config

[Pierangelo Masarati]

Michele Codutti wrote:
> 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

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.

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

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

[Pierangelo Masarati]

gianluigi.nigro wrote:

> Questo l'ho gia' fatto, forse ho posto male il quesito. Sulla macchina
> linux (che diventa il mio client ldap e sulla quale gli utenti possono o
> meno loggarsi)  come posso impostare il fatto che deve accettare solo
> gli accessi per il tale gruppo?

Che cosa stai usando?  Se non lo spieghi e' difficile aiutarti.  Se usi
pam_ldap, fai puntare l'opzione pam_groupdn (possibilmente che abbia
come classe "groupOfNames") al gruppo che si riferisce alle macchine
corrispondenti a quella che stai configurando, e pam_member_attribute
(possibilmente che valga "member").

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] Errore nella parserizzazione dell'LDIF di un backend shell o perl

[Pierangelo Masarati]

Pierangelo Masarati wrote:
> Leonardo Secci wrote:
>> Provvederò a sottomettere il bug.
> 
> In realta' sembra che il problema sia molto simile a quello di
> <http://www.openldap.org/its/?findid=5308>, in quanto il crash si
> verifica nello stesso punto in str2entry2().  Quel bug non e' ancora
> stato risolto.

Ho appena applicato una modifica
<http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/entry.c.diff?r1=1.166&r2=1.167&hideattic=1&sortbydate=0&f=h>
che fissa il problema.  Credo che possa essere facilmente adattata a 2.3.40.

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] Errore nella parserizzazione dell'LDIF di un backend shell o perl

[Pierangelo Masarati]

Leonardo Secci wrote:
> Provvederò a sottomettere il bug.

In realta' sembra che il problema sia molto simile a quello di
<http://www.openldap.org/its/?findid=5308>, in quanto il crash si
verifica nello stesso punto in str2entry2().  Quel bug non e' ancora
stato risolto.

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] Errore nella parserizzazione dell'LDIF di un backend shell o perl

[Pierangelo Masarati]

Leonardo Secci wrote:
> Provvederò a sottomettere il bug.
> 
> Dovendo implementare un meccanismo che delega l'accesso ad una mailbox a più 
> di una credenziale ero partito dal backend-meta, e tutto era perfetto ad 
> esclusione del fatto che non riesco a riscrivere il valore dell'userPassword, 

Non e' possibile.  In ogni caso, a mio avviso e' preferibile scrivere un
modulo dinamico (un overlay) che faccia esclusivamente quanto necessario
rispetto ad un backend completamente funzionante, piuttosto che usare un
back-

Re: R: R: [OpenLDAP] Syncrepl e BDB *core dump*

[Pierangelo Masarati]

Stefanelli Mirko wrote:
> Ciao,
> 
> ecco il risultato del comando :
> 
> [EMAIL PROTECTED] # gdb /openldap_new/libexec/slapd /tmp/core
> GNU gdb 6.6
> Copyright (C) 2006 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "sparc-sun-solaris2.9"...
> (no debugging symbols found)
> 
> warning: Can't read pathname for load map: I/O error.
> Reading symbols from /usr/local/BerkeleyDB.4.2.52.6p/lib/libdb-4.2.so...(no 
> debugging symbols found)...done.
> Loaded symbols for /usr/local/BerkeleyDB.4.2.52.6p/lib/libdb-4.2.so
> Reading symbols from /usr/lib/libgen.so.1...(no debugging symbols 
> found)...done.
> Loaded symbols for /usr/lib/libgen.so.1
> Reading symbols from /usr/local/ssl/lib/libcrypto.so.0.9.8...(no debugging 
> symbols found)...done.
> Loaded symbols for /usr/local/ssl/lib//libcrypto.so.0.9.8
> Reading symbols from /usr/local/ssl/lib/libssl.so.0.9.8...(no debugging 
> symbols found)...done.
> Loaded symbols for /usr/local/ssl/lib//libssl.so.0.9.8
> Reading symbols from /usr/local/lib/libsasl2.so.2...
> (no debugging symbols found)...done.
> Loaded symbols for /usr/local/lib//libsasl2.so.2
> Reading symbols from /usr/lib/libdl.so.1...(no debugging symbols 
> found)...done.
> Loaded symbols for /usr/lib/libdl.so.1
> Reading symbols from /usr/lib/libnsl.so.1...(no debugging symbols 
> found)...done.
> Loaded symbols for /usr/lib/libnsl.so.1
> Reading symbols from /usr/lib/libresolv.so.2...(no debugging symbols 
> found)...done.
> Loaded symbols for /usr/lib/libresolv.so.2
> Reading symbols from /usr/lib/libsocket.so.1...
> (no debugging symbols found)...done.
> Loaded symbols for /usr/lib/libsocket.so.1
> Reading symbols from /usr/lib/libpthread.so.1...(no debugging symbols 
> found)...done.
> Loaded symbols for /usr/lib/libpthread.so.1
> Reading symbols from /usr/lib/libc.so.1...(no debugging symbols found)...done.
> Loaded symbols for /usr/lib/libc.so.1
> Reading symbols from /usr/local/lib/libgcc_s.so.1...done.
> Loaded symbols for /usr/local/lib//libgcc_s.so.1
> Reading symbols from /usr/lib/libmp.so.2...done.
> Loaded symbols for /usr/lib/libmp.so.2
> Reading symbols from 
> /usr/platform/SUNW,Sun-Fire-V440/lib/libc_psr.so.1...done.
> Loaded symbols for /usr/platform/SUNW,Sun-Fire-V440/lib/libc_psr.so.1
> Reading symbols from /usr/lib/libthread.so.1...done.
> Loaded symbols for /usr/lib/libthread.so.1
> 
> warning: Can't read pathname for load map: I/O error.
> 
> warning: Can't read pathname for load map: I/O error.
> 
> Core was generated by `/openldap_new/libexec/slapd -f 
> /openldap_new/etc/openldap/slapd.conf -h ldap://'.
> Program terminated with signal 11, Segmentation fault.
> #0  0x0003f4f4 in ?? ()
> (gdb) bt full
> #0  0x0003f4f4 in ?? ()
> No symbol table info available.
> #1  0x0003fdf0 in entry_decode ()
> No symbol table info available.
> #2  0x000b6218 in bdb_id2entry ()
> No symbol table info available.
> #3  0x000af720 in bdb_cache_find_id ()
> No symbol table info available.
> #4  0x00095530 in bdb_search ()
> No symbol table info available.
> #5  0x00088e70 in overlay_op_walk ()
> No symbol table info available.
> #6  0x00088fd8 in ?? ()
> No symbol table info available.
> #7  0x00088fd8 in ?? ()
> No symbol table info available.
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb)
> 
> Se sono necessarie altre info o altri comandi da eseguire a disposizione.
> 
> Saluti,
> Mirko. Stefanelli

C'e' qualcosa che non va tra build di slapd e gdb.  Non avevo capito che
si trattava di Solaris (purtroppo).  Ricordo (ai tempi) di aver dovuto
(ri-)compilarmi il gdb per ottenere qualcosa di utilizzabile.  Puoi
verificare se la tua compilazione e' a 32 o a 64 bit, e se il gdb e'
consistente?  Se non ricordo male, quando compili con gdb, devi
specificare -m64 per compilare a 64 bit.

Se c'e' qualcuno che ha la compilazione e il debug su Solaris un po'
piu' alla mano, si faccia avanti!

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] quando LDAP usa la codifica base64?

[Pierangelo Masarati]

Alessandro De Zorzi wrote:

>> corretto
> grazie dei chiarimenti, è altrettanto vero che se passo un valore
> già codificato in base64 LDAP lo salva senza problemi vero?

Si.

> il problema in pratica mi deriva dalla funzione md5() di PHP
> che restituisce un numero esadecimale di 32 caratteri...
> e solo dalla versione di php5 è possibile ottenere un binario raw
> 
> per questo "problema di php" ho quindi dovuto prendere l'hash md5
> decodificarlo dall'esadecimale, quindi codificarlo in base64
> aggiungerci un {MD5} davanti e quindi darlo in pasto a LDAP
> e in effetti sembra funzioni, LDAP scrive senza fare ulteriori modifiche...
> 
> mi chiedo ora... c'era il modo di far capire a LDAP che la stringa
> era un numero esadecimale evitandomi questi passaggi?

No.  LDIF usa base64 per codificare valori binari.  Non esistono
codifiche alternative.

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] Errore nella parserizzazione dell'LDIF di un backend shell o perl

[Pierangelo Masarati]

Leonardo Secci wrote:
> Volendo implementare un backend perl o shell mi sono scontrato con un 
> presunto 
> problema di parserizzazione degli LDIF di risposta del backend al server.
> 
> Nello specifico il problema si presenta nel caso in cui l'LDIF di risposta 
> sia 
> composto unicamente dall'atributo dn.
> 
> In questo caso infatti il server esce con:
> UNKNOWN attributeDescription "DN" inserted.
> Segmentation fault
> 
> Per riprodurre lo scenario basta configurare un backend shell:
> 
> database shell
> readonly  on
> suffix  "dc=foo,dc=bar"
> search /tmp/search.sh
> 
> e creare uno script così
> 
> #!/bin/sh
> echo "dn: cn=bob,dc=foo,dc=bar"
> echo ""
> echo "RESULT"
> echo "code: 0"
> 
> Nel caso in cui modifichi lo script aggiungendo ad esempio l'attributo cn: 
> bob 
> ottengo il risultato atteso.
> 
> Mi domando se tale comportamento è dovuto al fatto che ho sbagliato a 
> produrre 
> l'LDIF sul backend oppure è un errore da fissare o già noto sul codice?
> 
> Nota: ho provato anche utilizzando un backend perl e ottengo lo stesso 
> risultato.
> 
> Ho provato soltanto con openldap 2.3.40.

Si tratta chiaramente di un bug, dal momento che tale LDIF e'
perfettamente valido.  Ti ricordo che il back-shell non e' da
considerare un vero backend utilizzabile per alcunche' di serio; una
considerazione simile vale per il back-perl.  In ogni caso, ti consiglio
di sottomettere un bug a OpenLDAP <http://www.openldap.org/its/>.

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: R: [OpenLDAP] Syncrepl e BDB *core dump*

[Pierangelo Masarati]

Stefanelli Mirko wrote:
> Ciao Luca,
> 
> ho installato il gdb, e lanciato il seguente comando: /usr/local/bin/gdbtui 
> -c core.
> 
> Il file core è oltre 100Mb, compresso è circa 18Mb. Comunque il risultato del 
> comando è il seguente:
> 
> ==OUTPUT COMMAND BEGIN=
> GNU gdb 6.6
> Copyright (C) 2006 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "sparc-sun-solaris2.9".
> Core was generated by `/openldap_new/libexec/slapd -f 
> /openldap_new/etc/openldap/slapd.conf -h ldap://'.
> Program terminated with signal 10, Bus error.
> #0  0xfee479d8 in ?? ()
> (gdb)
> ==OUTPUT COMMAND END==
> 
> Non conosco questo strumento di debug, quindi se ci sono altri parametri da 
> passare me li puoi suggerire.

Esegui

$ gdb /path/to/slapd /path/to/core

quindi:

(gdb) bt full

e manda il risultato.  Se il binario e' strippato, conviene che usi il
corrispondente binario generato in compilazione ma non ancora strippato
(fa niente se ti da' warning sul fatto che il binario potrebbe non
corrispondere al core, basta che sia compilato nello stesso modo).

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] quando LDAP usa la codifica base64?

[Pierangelo Masarati]

Luca Scamoni wrote:
> Alessandro De Zorzi wrote:
>> Salve, so che quando trovo in un ldif un "doppio due punti"
>> significa che la stringa è codificata in base64, ma non
>> capisco quando e perché OpenLDAP utilizzi la codifica in base64
>> ad esempio lo fa quando gli passo un hash md5?
>>   
> quando l'attributo contiene un valore che viene codificato UTF-8.
> userPassword fa eccezione (nel senso che e' sempre base64 encoded)

... o quando contiene caratteri "non-printabili" (isprint() come
definita in ctype.h).

>> E' corretto dire che lato applicativo non mi preoccupo
>> di come OpenLDAP scrive i dati?
>>   
> corretto

:)

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] referral is right?

[Pierangelo Masarati]

[EMAIL PROTECTED] wrote:
> Ciao a tutti,
> nel configurare pam_ldap ed nss_ldap (per la sola autenticazione 
> centralizzata) sulle  macchine Linux verso AD, ho rilevato su una di queste 
> che ldap andava in errore:
> 
> ldap_free_connection: actually freed
> su: ../../../libraries/liblber/sockbuf.c:91: ber_sockbuf_ctrl: Assertion `
> ( 
> (sb)  
> 
> ->sb_opts.lbo_valid == 0x3 )' failed.

Questo errore, se non ricordo male, e' la conseguenza del fatto che
nss_ldap usa la libldap in modo non-reentrant, e quindi e' inerentemente
non thread-safe, ma non ci si puo' fare nulla.

> Ho letto su un forum che mettendo il parametro "referrals no" si risolve 
> il problema, infatti  l'errore è sparito e l'autenticazione funziona.
> Ma qualcuno sa dirmi il significato di questo parametro e sopratutto se è 
> cosa buona che sia attivo??

AD ha il vizio di ritornare un sacco di referral (di solito inutili),
che nss_ldap non sa gestire e delega alla libldap, con il risultato che
vedi.  Se effettivamente non occorre inseguire i referral, disabilitarli
e' sicuramente benefico, anche in termini di prestazioni.

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 per autenticarsi su un dominio win

[Pierangelo Masarati]

[EMAIL PROTECTED] wrote:
> ma infatti io uso pam_ldap e nss_ldap, ma allora per questi ultimo dove 
> vado a mettere il parametro bindpw?
> nsswitch.conf accetta questo parametro? poi pensavo che pam_ldap si 
> appoggiasse cmq a ldap.conf..

Al suo ldap.conf, non a quello di OpenLDAP.  Comunque quale file ogni
applicazione usa, e quali direttive sono valide e' documentato nelle
rispettive man pages, come sempre.

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 per autenticarsi su un dominio win

[Pierangelo Masarati]

[EMAIL PROTECTED] wrote:
> facendo delle prove ho capito che l'autenticazione ldap non funziona perchè 
> non riesce a fare il bind dell'utente, infatti con il debug esce:
> 
> read1msg:  V2 referral chased, mark request completed, id = 1
> new result:  res_errno: 49, res_error: <80090308: LdapErr: DSID-0C090334, 
> comment: AcceptSecurityContext error, data 525, vece>, res_matched: <>
> read1msg: ld 0x8cc6400 0 new referrals
> read1msg:  mark request completed, ld 0x8cc6400 msgid 1
> request done: ld 0x8cc6400 msgid 1
> res_errno: 49, res_error: <80090308: LdapErr: DSID-0C090334, comment: 
> AcceptSecurityContext error, data 525, vece>, res_matched: <>
> 
> sembra proprio che non si legga il file .ldaprc che ho creato sotto la 
> home dell'utente:
> URI ldap://test.com/
> HOST 172.16.23.19
> BASE dc=test, dc=com
> BINDDN "[EMAIL PROTECTED]"
> bindpw pwd2006
> 
> se invece eseguo ldapsearch usando gli stessi parametri, la query 
> funziona. 
> non so, forse manca ancora qualcosa..

Come da man page di ldap.conf(5), bindpw ** NON E' ** un parametro
supportato dai client OpenLDAP; e' solo valido per pam_ldap e nss_ldap
(che non hanno nulla a che vedere con OpenLDAP).  Non c'e' modo di far
leggere la password da un file di configurazione dai client OpenLDAP.
Inoltre, il parametro BINDDN non e' valido: "[EMAIL PROTECTED]" non e' un
DN (manca "attr=" prima del valore).

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] Load generator per LDAP

[Pierangelo Masarati]

Giuseppe Paterno' (Gippa) wrote:
> Ciao a tutti! Avrei la necessita' di caricare un OpenLDAP per vedere
> quanto performa su una macchina in fatto di search/sec o modify/sec.
> Avreste qualche tool da suggerire, possibilmente OSS?

Lo strumento raccomandato da molti e' slamd; io di solito uso
direttamente i tools presenti nella suite OpenLDAP (tests/progs/);
quelli nella 2.4 sono relativamente versatili.

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 per autenticarsi su un dominio win

[Pierangelo Masarati]

[EMAIL PROTECTED] wrote:
> Salve a tutti,
> scusate la domanda banale ma avrei bisogno di chiarire alcune cose per far 
> autenticare i server linux tramite l'ldap di un dominio windows.
> A quanto ho letto, la cosa è possibile solo con 2 soluzioni:
> 
> 1) Si modifica lo schema di win per integrare gli attributi unix, tramite 
> i Services for UNIX (usando 2003 R2)
> 
> 2) Installando Samba 
> 
> nel primo caso sarà il dominio Win che si adatta agli attributi di Unix, 
> nel secondo invece è Linux che con Samba si adatta alle specifiche windows.
> 
> che voi sappiate, esiste un 3° modo, ovvero usare OpenLdap su linux in 
> modo che faccia delle query verso l'AD di windows solo per effettuare 
> l'autenticazione??
> Senza quindi dover installare Samba o modificare lo schema di AD ?

Che io sappia, se ti serve solo autenticazione puoi usare pam_ldap; il
modulo PADL consente di mappare le richieste su entry ed attributi
generici, quindi non dovrebbero esserci problemi ad autenticarsi su un
AD mappando la username su sAMAccountName.  Un esempio in tal senso e'
presente nell'ldap.conf che viene distribuito con il modulo pam_ldap.

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: R: R: [OpenLDAP] problemi con syncrepl [risolti :-)]

[Pierangelo Masarati]

Stefanelli Mirko wrote:
> Ciao,
> 
> Grazie ai vostri preziosi suggerimenti sono riuscito a far funzionare
> il syncrepl. Compilando la 2.3.39 stable ed il BerkeleyDB4.2.52 con
> le 6 patch (5 ufficiali e 1 vostra).
> 
> Ho effettuato dei test e tutto funziona alla perfezione, per
> replicare l'intero db (circa 14 entry, dimensione dei file
> id2entry.bdb->205Mb e dn2id.bdb->54Mb) le repliche hanno impiegato
> circa 2 ore.

Quant'e' il valore di set_cachesize in DB_CONFIG?

> Giusto per vostra informazione da un'attenta analisi del file di
> configurazione ho trovato il paramentro *timelimit* settato a 30.

Come "timelimit" nel producer o come opzione "timelimit" di "syncrepl"
nel consumer?

> Per quello che ho capito è il tempo massimo che il server può
> dedicare alla risposta ad una query, adesso che l'ho tolto dal file
> slapd.conf usa il valore di default cioè 3600.

Che e' comunque (1 ora) inferiore alle 2 ore impiegate per replicarsi.

> Vi volevo chiedere solo un suggerimento è meglio avere una sola
> identità utilizzata da tutti i consumer o avere un'identità per ogni
> consumer?

Secondo me e' meglio una per ogni consumer.  Ma non vedo grandi
differenze (o meglio, vantaggi e svantaggi piu' o meno si compensano).

> Ed un'ultima domanda, è previsto nelle prossime versioni l'utilizzo
> delle password cifrate sul consumer?

Mettere le password cifrate nel consumer non ha senso, in quanto
l'autenticazione mediante simple bind richiede la trasmissione della
password in chiaro.  L'unico modo di evitare la scrittura della password
in chiaro nel file di configurazione del consumer consiste nell'usare
un'autenticazione SASL che non richieda password; ad esempio, GSSAPI, o
EXTERNAL via TLS.

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

[Pierangelo Masarati]

> esistono le traduzioni in italiano delle pagine man di openldap?
> in caso positivo, un link alle medesime?
> io non ho trovato nulla.

Non che io sappia (quanto meno non ufficiali).

Approfitto di questo messaggio per ricordare che, ovviamente, volontari
sono (molto) ben accetti.

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] problema con il tunnelling e ldap

[Pierangelo Masarati]

Elisa Pellegrini wrote:
> Salve!
> ho creato un tunnelling tra le mie due macchine in questo modo:
> ssh -L  10123:localhost:389  [EMAIL PROTECTED]
> La cosa sembra funzionare ma quando apro il browser ldap (jxplorer) per
> verificare se effettivamente il tunnelling è stato fatto (mi connetto
> come localhost sulla porta 10123)
> ho un errore del tipo:
> javax.naming.ComunicationException:[server]:[porta][Root exception is
> java.net.ConnectException:Connection refused].
> Il problema è legato a ldap o devo rivedere il tunnelling?
> Il firewall è stato fermato in entrambe le macchine.
> Non so se la domanda è pertinente per quasto forum,comunque..

Connection refused sembra indicare che il server LDAP ha rifiutato la
connessione, ma non ho nessuna informazione sul motivo, ne' una chiara
indicazione che sia stato proprio il server LDAP a rifiutarla.

Se il server accetta le connessioni da localhost e da host remoto senza
tunneling, allora il problema e' del tunneling.

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] Definizione nuove sintax

[Pierangelo Masarati]

[per favore, rispondi sulla lista]

[EMAIL PROTECTED] wrote:
> Grazie delle informazioni,
> io però sono nuovo di ldap e openldap e non ho presente dove devo 
> scrivere il codice per le regole, le validazioni etc.. Per esempio per 
> creare dei nuovi attributi ho usato il core.schema per vedere degli 
> esempi, ma non riesco a trovare degli esempi di creazione di syntax 
> etc..

Come indicato nel messaggio precedente, ci sono esempi nel codice.  Il
piu' completo e attinente e' in servers/slapd/aci.c

Implementare nuove sintassi, comunque, oltre a richiedere un lavoro di
formalizzazione non banale, richiede anche una certa dimestichezza con
il codice.  Come primo suggerimento, direi di verificare che non esista
gia', tra le sintassi implementate, qualcosa di alternativo che possa
servire allo scopo.  Infatti, di solito l'uso di sintassi specifiche e'
indispensabile solo nel caso in cui il server debba fare qualcosa di
specifico con i valori di quell'attributo; ad esempio, il DN per
nominare le entries, o i certificati se usati per l'autenticazione.
Altrimenti, e' meglio usare sintassi molto generiche (tipo
directoryString, che puo' contenere di tutto) e delegare
all'applicazione l'attenersi piu' o meno rigidamente a restrizioni.

Se proprio devi implementare una sintassi speficifica, in caso di
eccessivi mali di testa nel seguire gli esempi, se la cosa ti serve per
lavoro ti consiglio di ingaggiare un esperto.

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] Definizione nuove sintax

[Pierangelo Masarati]

[EMAIL PROTECTED] wrote:
> Ciao a tutti,
> vorrei definire dei nuovi attributi e assegnarli una sintax personale, 
> creata da me. è possibile?

Si.  Vedi "attributetype" in slapd.conf(5).  Ma per definire una
sintassi personalizzata devi anche scrivere il codice che ne implementa
le operazioni (di regola, almeno validazione del dato; di solito anche
"prettificazione", ovvero riduzione a forma standard, qualcosa di meno
che una normalizzazione).  Non c'e' documentazione per questo, conviene
guardare esempi nel codice.  Raccomando, ad esempio, la sintassi delle
ACI, in aci.c; questo e' utile perche' mostra anche la registrazione
dinamica dei dati della sintassi, che quindi puo' essere implementata
come modulo run-time senza modificare il codice di base.  Tieni presente
che, se su quegli attributi vuoi effettuare operazioni di confronto
(filtri, modifica di valori multipli ecc.) dovrai definire anche delle
regole di confronto (matchingRule) appropriate.  Queste, a loro volta,
richiedono di solito almeno il codice relativo alla normalizzazione dei
valori.

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 Problematiche con ACL

[Pierangelo Masarati]

[EMAIL PROTECTED] wrote:
> Prendendo come riferimento la seguente struttura:
> 
> o=ditta,c=it
> |
> °°Rubrica
> ||
> |°cn=admin
> ||
> |°Amministrazione
> |||
> ||°cn=admin
> ||
> |°Vendite
> |||
> ||°cn=admin
> ||
> |°Magazino
> | |
> | °cn=admin
> |
> °Altro
> 
> e di seguto riportato l'ACL inserita in slapd.conf:
> 
> access to dn.subtree="ou=Amministrazione,ou=Rubrica,o=ditta,c=it"
> by dn="cn=admin,ou=Amministrazione,ou=Rubrica,o=ditta,c=it" write
> by dn.subtree="cn=admin,ou=Rubrica,o=ditta,c=it" write
> by dn="cn=admin,ou=elenchinlinea,ou=Rubrica,o=ditta,c=it" write
> by dn="cn=admin,ou=Rubrica,o=ditta,c=it" write
> by dn="cn=anonymous,o=ditta,c=it" read
> by self write
> by anonymous auth
> 
> access to dn.subtree="ou=Vendite,ou=Rubrica,o=ditta,c=it"
> by dn="cn=admin,ou=Vendite,ou=Rubrica,o=ditta,c=it" write
> by dn.subtree="cn=admin,ou=Rubrica,o=ditta,c=it" write
> by dn="cn=admin,ou=elenchinlinea,ou=Rubrica,o=ditta,c=it" write
> by dn="cn=admin,ou=Rubrica,o=ditta,c=it" write
> by dn="cn=anonymous,o=ditta,c=it" read
> by self write
> by anonymous auth
> 
> access to dn.subtree="ou=Magazino,ou=Rubrica,o=ditta,c=it"
> by dn="cn=admin,ou=Magazino,ou=Rubrica,o=ditta,c=it" write
> by dn.subtree="cn=admin,ou=Rubrica,o=ditta,c=it" write
> by dn="cn=admin,ou=elenchinlinea,ou=Rubrica,o=ditta,c=it" write
> by dn="cn=admin,ou=Rubrica,o=ditta,c=it" write
> by dn="cn=anonymous,o=ditta,c=it" read
> by self write
> by anonymous auth
> 
> access to dn.subtree=",ou=Rubrica,o=ditta,c=it"
> by dn.subtree="cn=admin,ou=Rubrica,o=ditta,c=it" write
> by dn="cn=admin,ou=elenchinlinea,ou=Rubrica,o=ditta,c=it" write
> by dn="cn=admin,ou=Rubrica,o=ditta,c=it" write
> by dn="cn=anonymous,o=ditta,c=it" read
> by self write
> by anonymous auth
> 
> e tenuto conto che per ogni cn=admin e' impostata anche una userPassword.
> 
> La domanda e':
> 
> 1) e' possibile inserire un utente cn=admin nel db che abbia i privileggi
>di scrittura nel suo ramo di pertinenza senza dover senpre aggiornare
>le ACL nel file slapd.conf.
> 
> 2) se si prendendo in riferimento la struttura su riportata e' possibile
>fare un esempio.


Si, si:

# accesso ai sotto-rami; in particolare, cn=admin del sotto-ramo
# ha accesso in scrittura
access to dn.regex="(.+,)?ou=([^,]+),ou=Rubrica,o=ditta,c=it"
by dn.expand="cn=admin,$2,ou=Rubrica,o=ditta,c=it" write
by dn.subtree="cn=admin,ou=Rubrica,o=ditta,c=it" write
by dn="cn=admin,ou=elenchinlinea,ou=Rubrica,o=ditta,c=it" write
by dn="cn=anonymous,o=ditta,c=it" read
    by self write
by anonymous auth

# accesso a tutto il resto che non e' intercettato dalla regola
# sopra; in particolare, ci sono glu stessi "by" tranne il cn=admin
# del sotto-ramo.
access to dn.subtree="ou=Rubrica,o=ditta,c=it"
by dn.subtree="cn=admin,ou=Rubrica,o=ditta,c=it" write
by dn="cn=admin,ou=elenchinlinea,ou=Rubrica,o=ditta,c=it" write
by dn="cn=anonymous,o=ditta,c=it" read
by self write
by anonymous auth

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] Problema con dimensione attributi

[Pierangelo Masarati]

[EMAIL PROTECTED] wrote:
> Ciao a tutti,
> ho un problema con il settaggio della dimensione degli attributi, la 
> seguente riga non mi funziona:
> 
> # codiceFiscale
> attributetype ( 2.5.4.58 NAME 'codiceFiscale'
>   DESC 'RFC2256: ldap user codice fiscale'
>   SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{16} )
> 
> la dimensione (16) non viene settata!
> qualcuno ha qualche idea?

Quella dimensione e' solo "consigliata" (da RFC4512) e le
implementazioni sono libere di ignorarla.  Di fatto, non serve a nulla.

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] problem with Ldap & sympa

[Pierangelo Masarati]

Elisa Pellegrini wrote:
> Salve!
> Hon configurato sympa in modo che vada ad inserire tra i membri della
> lista gli utenti dell'albero ldap.
> Il problema è che Sympa riconosce gli utenti ma questi poi non riescono
> ad autenticarsi perchè la loro password è errata. Sympa interroga l'ldap
> server sulla porta 636 .
> Il problema non so se è legato a sympa o ldaps server, cosi volevo
> sapere se possono essere settate il ldap particolari aci che boccano
> l'autenticazione.

Di default OpenLDAP non compila il supporto per le ACI, il cui uso e'
scoraggiato, e comunque non setta nessuna ACI di default.  Se ti
riferisci alle ACL, invece, se non definisci nessuna regola OpenLDAP
consente lettura a tutto (inclusa la password) da parte di tutti; nel
momento in cui definisci delle ACL, il default (ovvero il comportamento
nel caso nessuna regola sia verificata) consiste nel negare l'accesso a
chiunque.  Per informazioni, man slapd.access(5).  Per vedere se il
problema e' legato al server, puoi guardare i log con un livello
adeguato.  Ad esempio, se ti preoccupano le ACL, conviene usare i
livelli "stats" e "acl".  Per informazioni, man slapd.conf(5) e man
slapd(8).

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] Domande varie su LDAP: password, log e slapcat

[Pierangelo Masarati]

Paolo Pisati wrote:
>>> 3) e' possibile conoscere da LDAP gli accessi degli utenti alle varie
>>> macchine ed alcune operazioni (ad esempio i comandi sudo) da essi
>>>eseguiti? ad esempio e' possibile ottenere un log di queste
>>> operazioni?
>>> 
>>
>> Non e' chiara la domanda; se qualche applicazione si occupa di scriverlo
>> nel database, allora basta una ldapsearch(1).  Altrimenti non capisco
>> che cosa LDAP abbia a che fare con il logging di altri comandi.
>>   
> uhm, in effetti mi sarebbe piaciuto poter "centralizzare" i log, cioe'
> distinguere le
> ricerche sulla directory LDAP in base alla loro provenienza:
> 
> dal comando sudo, dal client pam/sshd, etetc
> 
> ma capisco che la cosa non e' fattibile.

Non e' che non sia fattibile in assoluto, solo non dipende dal server ma
dal client farsi riconoscere.  Ad esempio, se per ogni client crei
un'utenza di servizio, ad esempio "cn=sudo admin,...", "cn=pam
admin,..." ecc., e fai usare questa utenza da ogni applicazione per
autenticarsi prima di svolgere un'operazione (ad esempio, di solito pam
cerca il DN dell'utente in base alla uid per poi fare una simple bind o
comunque verificare in qualche modo la password; potresti far
autenticare pam con l'utenza "cn=pam admin,..." prima di svolgere la
ricerca).  In ogni caso, il log finirebbero in un file unico, che pero'
potresti parsare con uno script per estrarre le informazioni che ti
servono; oppure potresti usare lo slapo-accesslog per far mettere i log
in un database, che poi potresti interrogare via LDAP usando l'attributo
reqAuthzID per discriminare le operazioni in base all'applicazione.

La vera soluzione "elegante" LDAP, che pero' richiede la modifica dei
client, consiste nell'usare il controllo definito nella
, che e' supportata da OpenLDAP 2.4.  In questo
caso, il client definisce una stringa che il server poi mostra nei log
come prefisso a tutti i log legati a quella operazione.

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] Domande varie su LDAP: password, log e slapcat

[Pierangelo Masarati]

Paolo Pisati wrote:
> Salve ragazzi,
> 
> ho una installazione di LDAP che vorrei migliorare sotto alcuni punti di
> vista, ed in particolare:
> 
> 1) vorrei che gli utenti presenti nella directory LDAP, possano
> cambiarsi da soli la propria password, ma non riesco a capire come usare
> (se e' il tool corretto) ldappasswd:
> 
> [EMAIL PROTECTED]:~ >ldappasswd -W -S
> New password:  # nuova pwd
> Re-enter new password:# nuova pwd - di
> nuovo
> Enter LDAP Password: # e qui??!?!
> vecchia pwd presente su LDAP?
> ldap_bind: Invalid credentials (49)
> [EMAIL PROTECTED]:~ >

ldappasswd(1) e' un client come gli altri.  Come tutti i client, prima
di fare un'operazione (in particolare, di scrittura) deve autenticarsi.
 Quindi la password passata da -W e' quella con cui il client si
autentica.  Invece quella passata con -S e' quella da cambiare.  Ma a
chi?  Se non specifichi l'identita' di cui vuoi cambiare la password, di
default la cambia all'identita' con la quale si e' autenticato.  Ma tu
non stai passando nessuna identita' all'autenticazione, quindi
onestamente non so quale identita' il client stia provando a cambiare.
In ogni caso, se passi tutti gli argomenti giusti, come specificato in
man ldappasswd, il client fa quello che deve.

> 
> 2) voloendo fare il backup notturno della mia directory, pensavo di
> convertire tutto in LDIF via slapcat e archiviare tale file, ma:
> 
> [EMAIL PROTECTED]:~ >ldapsearch
> # extended LDIF
> #
> # LDAPv3
> # base <> with scope subtree
> # filter: (objectclass=*)
> # requesting: ALL
> #
> [snip]
> # search result
> search: 2
> result: 0 Success
> 
> # numResponses: 18
> # numEntries: 17
> 
> questo dimostra che LDAP funziona, pero' quando provo ad eseguire
> slapcat ottengo:
> 
> [EMAIL PROTECTED]:~ >slapcat
> bdb_db_open: alock package is unstable
> backend_startup_one: bi_db_open failed! (-1)
> slap_startup failed
> 
> ed in effetti il mio LDAP usa bdb:
> 
> [EMAIL PROTECTED]:~ >cat /usr/local/etc/openldap/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
> 
> databasebdb
> suffix  "dc=tomato,dc=org"
> rootdn  "cn=Manager,dc=tomato,dc=org"
> rootpw  {SSHA}XXX
> directory   /var/db/openldap-data
> index   objectClass eq
> index   uid pres,eq,sub
> 
> TLSCACertificateFile /usr/local/etc/openldap/ldap_cert/cacert.pem
> TLSCertificateFile /usr/local/etc/openldap/ldap_cert/ldapcert.pem
> TLSCertificateKeyFile /usr/local/etc/openldap/ldap_cert/ldapkey.pem
> 
> access to * by self write by * read

Questo messggio e' molto generico; con quale utenza esegui il comando?
Sei sicuro che slapd.conf e la directory con il database siano leggibili
da quell'utenza?  slapcat apre direttamente i files, quindi il fatto che
il servizio sia attivo o meno non fa nessuna differenza.

> 3) e' possibile conoscere da LDAP gli accessi degli utenti alle varie
> macchine ed alcune operazioni (ad esempio i comandi sudo) da essi
>eseguiti? ad esempio e' possibile ottenere un log di queste operazioni?

Non e' chiara la domanda; se qualche applicazione si occupa di scriverlo
nel database, allora basta una ldapsearch(1).  Altrimenti non capisco
che cosa LDAP abbia a che fare con il logging di altri comandi.

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: R: [OpenLDAP] problemi con syncrepl

[Pierangelo Masarati]

Stefanelli Mirko wrote:

> Ho effettuato il seguente test, con il provider up&running (ore 18:00 del 
> 14/11/2007) ho attivato il consumer senza DB (ore 18:05 del 14/11/2007). 
> Questa mattina (ore 10:00) ho effettuato il seguente test, ho lanciato un 
> ldapsearch dalla root con filtro objectClass=* e scope sub sul provider il 
> risultato è:
> 
> # numResponses: 132369
> # numEntries: 132368
> 
> la stessa ldapsearch l'ho eseguita sul consumer ed il risultato è:
> 
> # numResponses: 25001
> # numEntries: 25000
> 
> Come puoi notare in circa 14 ore il syncrepl ha ricostruito meno di 1/5 del 
> db.

Tieni presente che con OpenLDAP 2.3 un caricamento totale via ldapadd
richiede poco piu' del tempo richiesto da slapadd (due-tre, massimo 10
volte tanto).  Quanto hai impiegato con slapadd?

Inoltre, mi sembra che un numero cosi' rotondo possa collegarsi al
raggiungimento di un limite sul numero di entries (default: 500;
ripetuto 50 volte da' il numero di entries attualmente nel tuo db).
Occorre dare all'identita' usata dal consumer per la sincronizzazione il
permesso di scaricare un numero arbitrario di entries.  Per fare questo,
sul producer devi mettere

limits dn="" size=unlimited

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

[Pierangelo Masarati]

[EMAIL PROTECTED] wrote:
> Salve,
> avrei bisogno di alcuni chiaramenti riguardo la gestione degli alias in 
> openLDAP.
> Vi riporto di seguito l'object class definito nello schema file ed il DIT 
> utilizzato.
> 
> SCHEMA
> ( 1.3.6.1.4.1.139.44.11.7  NAME  'myaliasObject'
>   DESC  objectclass for all alias objects
>   SUPalias
>   MAY(cn)
> )
> 
> 
> DIT
>  dn: c=myCountry
>  c: myCountry
>  objectclass: country
> 
>  dn: ou=Area1, c=myCountry
>  ou: Area1
>  aliasedObjectName: o=Area2, c=myCountry
>  objectclass: alias
>  objectclass: myaliasObject
>  cn: Italia
>  cn: Francia
>  cn: Belgio
> 
>  dn: ou=Area2, c=myCountry
>  ou: Area2
>  objectclass:organization
>  cn: Inghilterra
>  cn: Spagna
>  cn: Ucraina
> 
> _
> 
>   c = myCountry
>  /   |
>   ou = Area1   -> ou = Area2
> |cn=Italia  |cn: Inghilterra
> |cn: Francia  |cn: Spagna
> |cn: Belgio|cn: Ucraina
> 
> 
> Effettuando una ricerca con baseDN=ou=Area1, c=myCountry, mi aspetto di 
> ottenere come result entry l'elenco degli attributi sia di Area1 che di Area2.
> Ho provato ad effettuare la ricerca utilizzando i diversi valori di 
> Dereferencing senza mai ottenere il risultato sperato.
> Nelle diverse prove ottengo o i soli attributi di Area1 (compreso 
> l'aliasedObjectName non dereferenziato) oppure i soli attributi di Area2.
> 
> E' giusta l'interpretazione che sto dando al funzionamento dell'alias oppure 
> ... ???


... oppure.  L'alias, in LDAP (non solo in OpenLDAP) e' l'equivalente
del link simbolico nel filesystem di UNIX.  Ovvero, un nome (un DN)
alternativo a quello della entry effettiva.  Il suo scopo consiste nel
definire, ad esempio, ruoli: se

cn=Pierangelo Masarati,dc=sys-net,dc=it

temporaneamente riveste il ruolo, che so, di amministratore della posta,
allora creo un alias che collega il DN

cn=Mail Admin,dc=sys-net,dc=it

a quello dell'utente.

Quello che vuoi tu e' un merge dinamico tra due entries.  Per quello
scopo puoi usare l'overlay slapo-dynlist(5), ammesso che sia possibile
definire adeguatamente l'URL che scatena la ricerca.  Quell'overlay, se
la entry "alias" contiene una parte dei dati, piu' l'objectClass che
scatena l'espansione, piu' gli URL che eseguono l'espansione dei membri
della lista, e se quella entry da sola e' selezionata da una ricerca,
allora, prima di essere ritornata, viene espansa aggiungendo i valori
degli attributi trovati dalle sotto-ricerche.

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] DN e caratteri non ASII

[Pierangelo Masarati]

> Non mi è chiaro se i client di OpenLDAP (ldapsearch e ldapmodify) non
> convertano i caratteri non-UTF8 a UTF8. Quel "non lo consentono" è
> ambiguo.

Significa "non sono in grado di".  Occorre pre-processare i dati da
passare alle richieste (ad esempio il DN delle entries in ldapadd,
ldapmodify, ldapdelete, ma anche la base usata in ldapsearch ecc.), e
post-processare i dati ritornati dal server (ad esempio i DN delle entries
ritornate da ldapsearch, ma anche il "matched" che puo' essere ritornato
da qualsiasi operazione).  Questo si puo' fare con vari linguaggi di
scripting, o semplicemente da linea di comando con strumenti come
iconv(1).

> Domanda sciocca: anche i valori di tutti gli attributi sono codificati
> in UTF8, vero?

I valori degli attributi con sintassi directoryString.  I valori di
attributi con altre sintassi sono codificati secondo la loro sintassi.

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] DN e caratteri non ASII

[Pierangelo Masarati]

[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

Re: [OpenLDAP] ldapsearch -x

[Pierangelo Masarati]

Luca Scamoni wrote:
> puestadelsol83 wrote:
>> Salve!
>> Il mio albero Ldap è strutturato in questo modo:
>> dc=in,dc=it   (radice)
>> ou=f,dc=in,dc=it (ramo) con utenti Sam, TOm, Frank
>> ou=t,dc=in,dc=it (ramo) con utenti Bob, Carl, Sara
>> (Per ogni utente ho specificato degli indirizzi mail)
>> Inoltre all'interno di ou=f,dc=in,dc=it ho creato un gruppo statico
>> con dn: cn=marketing,ou=f,dc=in,dc=it costituito dagli utenti Sam e Bob
>>
>> come imposto l' ldapsearch -x in modo da visualizzare solo gli gli
>> indirizzi mail degli utenti che appartengono al gruppo cn=marketing?
>> Grazie!
>>   
> Non lo imposti. ldap non supporta query relazionali (tipo join).
> Se vuoi, puoi definire per ciascun utente un attributo con il dn del
> gruppo e usare come filtro qualcosa tipo (attributo=dn del gruppo)

Quanto dice Luca e' corretto; in alternativa, con OpenLDAP 2.4, puoi
usare l'overlay slapo-memberof che mantiene, in ogni membro di gruppo,
un attributo (default: memberOf) con il DN dei gruppi di cui fa parte;
in questo modo, la tua query sarebbe:

ldapsearch -x '(memberOf=cn=marketing,ou=f,dc=in,dc=it)' mail

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: R: [OpenLDAP] Ldap e ppolicy

[Pierangelo Masarati]

Stefanelli Mirko wrote:


Se posso portarti via altri due minuti, affinché i moduli pam
utilizzino il ppolicy per recuperare le info relative allo stato
dell'utente è necessario modificare e ricompilare i moduli pam?


Che io sappia, la versione piu' recente di pam_ldap (184) supporta la 
passowrd policy implementata da slapo-ppolicy(5), come pure altre 
proprietarie.  Se l'hai compilato con gli header di una versione di 
OpenLDAP abbastanza recente, e' gia' presente, e credo che venga usato 
di default, o comunque se metti "pam_lookup_policy yes".



Non so se ti posso scrivere direttamente o devo comunque passare per
la mailinglist e probabilmente tale richiesta e' OT.


Si, scrivi anche alla lista.  Non e' necessariamente OT, perche' i 
moduli PAM devono parlare con il server OpenLDAP, e slapo-ppolicy(5) e' 
un pezzo di OpenLDAP.


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] Ldap e ppolicy

[Pierangelo Masarati]

Stefanelli Mirko wrote:



Salve a tutti,

 

Da poco tempo lavoro con openLdap, adesso ci è stato richiesto di 
integrare alcune policy per rendere il sistema più sicuro. Il modulo 
slapo-ppolicy permette alcune personalizzazioni sulle autenticazione al 
server Ldap. In particolare dopo tre tentativi di autenticazione (bind) 
fornendo una password sbagliata il modulo ppolicy mette tale account in 
modalità loked. Dal man del modulo slapo-ppolicy il codice di ritorno di 
questo stato dovrebbe evidenziare che l’utente è bloccato (per un tempo 
definito da file di configurazione) con il messaggio “Account Locked”, 
effettivamente il modulo funziona cioè dopo tre tentativi non permette 
l’accesso anche fornendo la password giusta. Ma il codice di ritorno 
dell’operazione è sempre 48 (LDAP_INVALID_CREDENTIALS), mentre mi 
aspettavo un diverso codice. Qualcuno ha qualche idea o qualche link a 
cui fare riferimento?


Leggi bene: il modulo, come da draft-behera-ldap-password-policy, usa il 
relativo controllo per ritornare informazioni relative alla policy. 
Quindi il comportamento del server e' inalterato a meno che il client 
non metta nella richiesta il controllo 1.3.6.1.4.1.42.2.27.8.5.1; in 
tale caso, il messaggio di risposta puo' contenere un controllo 
1.3.6.1.4.1.42.2.27.8.5.1, il cui valore contiene a sua volta 
informazioni relative alla policy.  Quindi, per sfruttare tali 
informazioni, occorre che il client sia in grado di aggiungere tale 
controllo alla richiesta, e di interpretare la relativa risposta.


I client distribuiti con OpenLDAP lo fanno in modo consistente a partire 
da 2.3.38, aggiungendo il parametro -e ppolicy.


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] Query e ACL...

[Pierangelo Masarati]

>> Mandi! Marco D'Ettorre

set="([uid=]+[cn=ced,ou=Group,dc=sv,dc=lnf,dc=it]/memberUid+[,ou=People,dc=sv,dc=lnf,dc=it])
>> & user" write

le quantita' tra parentesi quadre devono avere il case corrispondente al
valore normalizzato per la regola di uguaglianza dell'attributo a cui si
riferiscono.  Fatta breve, devi usare [ou=people,dc=sv,dc=lnf,dc=it]
anziche' [ou=People,dc=sv,dc=lnf,dc=it], perche' il successivo confronto
verra' fatto con "user", che invece e' normalizzato.  Questo e' spiegato
in <http://www.openldap.org/faq/data/cache/1133.html> proprio nell'esempio
che si riferisce all'operatore '+'.  Il valore risultante dalla
composizione non puo' essere normalizzato da slapd perche' i set non sono
fortemente tipizzati, in quanto possono contenere valori arbitrari. 
Questa e' un po' la forza e la debolezza dei set.

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] Query e ACL...

[Pierangelo Masarati]

> Mandi! Marco D'Ettorre

> la mia ACL è:
>
>  access to dn.children="ou=People,dc=sv,dc=lnf,dc=it"
> attrs=entry,@inetLocalMailRecipient,physicalDeliveryOfficeName,telephoneNumber,mail,description
> by
> set="([uid=]+[cn=ced,ou=Group,dc=sv,dc=lnf,dc=it]/memberUid+[,ou=People,dc=sv,dc=lnf,dc=it])
> & user" write
> by * break
>
> mentre se metto:
>
>  access to dn.children="ou=People,dc=sv,dc=lnf,dc=it"
> attrs=entry,@inetLocalMailRecipient,physicalDeliveryOfficeName,telephoneNumber,mail
> by dn.exact="uid=gaio,ou=People,dc=sv,dc=lnf,dc=it" write
> by * break
>
> funziona perfettamente.

Domanda stupida: che cosa contiene
"[cn=ced,ou=Group,dc=sv,dc=lnf,dc=it]/memberUid" ?

Sei sicuro di autenticarti come "uid=gaio,ou=People,dc=sv,dc=lnf,dc=it" ?

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] Replicazione Syncrepl con deltasync e TLS

[Pierangelo Masarati]

Per favore, rispondi alla lista.

Michele Codutti wrote:

Ho provato ad introdurre la regola ACL che mi hai suggerito all'interno
della mia configurazione con nessun risultato. Probabilmente non ho
capito bene il tuo consiglio.
Quello che non mi torna è che mi parli di duplicare le regole ACL con la
regola che hai scritto, significa che dovrei metterla in testa/coda ad
ogni regola che ho già?



A causa dell'ora tarda e del rincoglionimento globale, il mio commento 
era incompleto.


La regola, per essere precisi, dovrebbe essere:

access to *
by sockurl="ldap://public.net"; ssf=128 break
by sockurl="ldap://public.net"; stop
by * break

Per come e' scritta, va messa per prima; in caso di match, valgono i 
"break" e quindi si passa alla valutazione delle regole successive senza 
che vengano definiti privilegi di sorta (non c'e' nessun campo  
nelle regole, solo , come illustrato in slapd.access(5)).


Il valore di "sockurl" deve essere la stringa esatta con cui viene 
definita tramite parametro -h l'interfaccia di slapd che deve avere 
ssf=128; quindi, se lanci


$ slapd -h "ldap://public1.net ldap://public2.net:9011";

devi scrivere

access to *
by sockurl="ldap://public1.net"; ssf=128 break
by sockurl="ldap://public1.net"; stop
by sockurl="ldap://public2.net:9011"; ssf=128 break
by sockurl="ldap://public2.net:9011"; stop
by * break

E, ovviamente, devi togliere ssf=128 da "security".

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

Re: [OpenLDAP] Replicazione Syncrepl con deltasync e TLS

[Pierangelo Masarati]

Michele Codutti wrote:
> 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?

Che io sappia, no.  Probabilmente l'unica soluzione consiste nel
duplicare le tue ACL in modo tale da imporre l'uso di ssf=128 solo
quando "sockurl" corrisponde ad una delle interfacce per le quali lo
richiedi.

Qualcosa del tipo

access to *
by sockurl="ldap://public.net"; ssf=128 break
by sockurl="ldap://public.net";
by * break

dovrebbe impedire qualsiasi accesso alle connessioni su
"ldap://public.net"; che non abbiano ssf pari ad almeno 128, per le quali
la valutazione si ferma li', mentre le connessioni con ssf pari a 128 o
superiore, e quelle sulle altre interfacce non acquisiscono alcun
privilegio ma continuano alle regole successive.

Tutto sommato, la feature che richiedi potrebbe avere senso, quindi ti
consiglio di suggerirne l'introduzione attraverso l'ITS
.

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

Re: [OpenLDAP] Query e ACL...

[Pierangelo Masarati]

Marco Gaiarin wrote:
> Mandi! Marco D'Ettorre
>   In chel di` si favelave...
> 
>> http://www.openldap.org/doc/admin23/slapdconfig.html#Access%20Control
> 
> L'avevo visto ma non mi aveva detto nulla.
> 
>> man slapd.access
> 
> Oh, hai la soluzione sotto il naso e non lo sai, scusate, questa mi era
> proprio sfuggita.
> 
> Solo che ancora qualcosa non mi quadra. Non ho provato, ma a naso io
> dovrei scrivere:
> 
>   by group/posixGroup/memberUid.exact=ced,ou=Group,dc=sv,dc=lnf,dc=it
> 
> Solo che questa cosa a me torna solo 'gaio', 'walter', ... e credo che
> sia necessario da questo costruire una dn.
> 
> Aia. Vedo:
> 
>   http://www.openldap.org/lists/openldap-software/200411/msg00439.html
> 
> dimmi che dal 2004 qualcosa è cambiato... ;-(((

Non e' cambiato niente perche' non c'e' niente da cambiare: il gruppo
POSIX e' una cosa che riguarda il sistema operativo, mentre LDAP conosce
solo il gruppo LDAP, ovvero il groupOfNames o la sua variante tarocca
groupOfUniqueNames (da evitare).  Il groupOfNames e' il gruppo LDAP per
eccellenza in quanto contiene i membri sotto forma di DN, ovvero l'unico
nome LDAP delle entries, mentre il gruppo POSIX contiene i memberUid,
cioe' degli identificativi che per LDAP non hanno nessun significato.
E' pur vero che se nel tuo albero censisci gli utenti di un solo dominio
POSIX (cosa che non esiste, ma facciamo finta di si'), allora e'
probabile che tu possa definire una corrispondenza univoca memberUid =>
DN (magari non il contrario, DN => memberUid, ma questo e' quesi
irrilevante).  Allora, se vuoi farti del male e usare i gruppi POSIX per
le regole di accesso, puoi usare i set (non documentati in
slapd.access(5), ma nelle FAQ:
<http://www.openldap.org/faq/data/cache/1133.html>; occhio che ancora
nella 2.3.38 c'e' un baco, fisato nella 2.3.39), oppure provare il
modulo ultra-sperimentale contrib/slapd-modules/acl/posixgroup.c

Nel caso dei set, in pratica devi usare il memberUid per costruire il DN
con cui fare i confronti (piuttosto inefficiente); per esempio, la
regola che confronta l'identita' del client con i membri di un gruppo
POSIX il cui DN sia "cn=POSIX,cn=Groups", assumendo che i DN degli
utenti si costruiscano con "uid=" + memberUid + ",cn=Users", e':

access to *
by set="([uid=]+[cn=POSIX,cn=Groups]/memberUid+[,cn=Users]) & user"
read

In oni caso, tieni presente che usare i gruppi POSIX per l'accesso LDAP
e' in generale la risposta sbagliata ad una domanda mal posta.

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] Verifica indici...

[Pierangelo Masarati]

Marco Gaiarin wrote:

Mandi! Luca Scamoni
  In chel di` si favelave...


Devi eliminarlo. I parametri dbconfig in slapd.conf servono *SOLO* se non
hai un DB_CONFIG (per crearlo). Dopodiche' tutte le modifiche che fai in
slapd.conf a questi parametri non servono assolutamente a nulla.


Ecco, ora devo chiedere scusa a tutti, questo mi era proprio sfuggito:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=442191

Ah, no: non mi era sfuggito: è di ieri!!! Mi hanno fregato sul tempo.
;)


E' di ieri perche' e' stato "sparato" dopo la discussione sulla man page 
poco chiara di ieri: <http://www.openldap.org/its/?findid=5134>.


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] Verifica indici...

[Pierangelo Masarati]

Marco Gaiarin wrote:

> Credo di aver capito; sarebbe bello sapere se, visto che sono presenti
> entrambi, quali vengono poi alla fine considerati se differenti...
> bah, quisquilie! ;)

La cosa funziona cosi':

- se DB_CONFIG non e' presente nella cartella del database e i dbconfig
sono presenti nello slapd.conf, il DB_CONFIG equivalente viene generato
e usato;

- se DB_CONFIG e' presente nella cartella del database e i dbconfig sono
presenti nello slapd.conf, questi ultimi vengono bellamente ignorati

- diversa e' la cosa infine se i dbconfig vengono definiti mediante
back-config, ovvero modificando il database cn=config mediante
operazioni LDAP: in questo caso, le modifiche hanno effetto immediato,
risultando in un recover del database.

> Da tutto questo ambaradan mi pare che si faccia comunque riferimento a
> tre 'classi' di parametri:
> 
> 1) cache size

Fondamentale: se il tuo db ha meno di 100/1000 entries, puoi fare a meno
del DB_CONFIG e basta; altrimenti almeno la cache e' fondamentale per
avere prestazioni decenti

> 2) lock, che come segnala debian, possono essere un grosso problema se
>  finiscono

Ma in pratica e' raro che finiscano, a meno che tu non faccia tonnellate
di operazioni, e soprattutto modifiche, concorrenti

> 3) logfile, che sono sicuramente un punto di fine tuning importante, ma
> che nel caso 'normale' (openldap come backend account e password) credo
> incida pochisismo (si legge tanto, ci si scrive mai).

Vedi sopra.  Ma (almeno secondo noi) e' piu' probabile che uno debba
toccare i log, ad esempio mandandoli su un altro disco, che il numero di
lock.

> Ovvero mi sembra che debian non abbia fatto scelte tragicamente
> sbagliate, ponendo la cache a 2MB (ci stanno comodamente dentro qualche
> centinaio di account) e alzando il numero dei lock per precauzione.
> Poi ha sicuramente presunto l'uso di openldap come database (passatemi
> il termine improprio) write once/read many, e quindi non ha trattato di
> logfile.

Solo che 2MB di cache va bene forse per chi su LDAP mette un centinaio
di utenti e non li cambia mai.  In questo caso, non si capisce perche'
sia necessario toccare il numero di lock (forse non serve neppure
modificare la cache...)

> Sinceramente mi pare una scelta condivisibile e abbastanza
> conservativa, se qualcuno ha database enormi e/o esigenze speciali
> solitamente sa gia come e quanta documentazone leggersi. ;)
> Senza contare che poi ha fornito specifici README e puntatori a
> documentazione ufficiale nel README.Debian che qualsiasi sysadmin
> Debian sa che *deve* leggere.
> 
> E questo non per voler prendere le difese per principio di Debian o
> altre distribuzioni, ma credo che sia impossibile per una distribuzione
> fornire una configurazione di openldap per tutte le situazioni, è
> sicuramente meglio fornire una configurazione decente per il caso
> 'normale' e puntatori a buona documentazione per il resto.

Sono d'accordo sul fatto che una distribuzione faccia bene a fornire
default propri tarati sul presunto default della sua utenza, mentre
OpenLDAP fa bene a non farlo perche' non ha una utenza tipo e quindi
rischia di essere fuorviante.

>> Veramente il calcolo si fa con db_stat -m; la dimensione della cache,
>> brutalmente, va confrontata con la dimensione dei fils del DB.  Se riesci
>> a metterli tutti in cache sei a posto.  Se non ci riesci, o non ti
>> conviene, puoi guardare a quante richieste non sono state soddisfatte
>> dalla cache.  In base alla percentuale, vedi se ti conviene aumentare o
>> meno.
> 
> Il secondo documento che ho citato diceva sostanzialmente (se ho capito
> bene) occorre perlomeno avere abbastanza memoria per contenere tutti i
> nodi interni di tutti i database se si vuole evitare il trashing; la
> cosa è assolutamente plausibile, se non è così il backend è costretto a
> swappare dentro/fuori la cache il database financo in fase di ricerca...

Si, ma il punto critico e' che se anche allochi cache sufficiente per
contenere tutti i files degli indici (e se ti scappa la mano con gli
indici possono essere grandi), poi non sai che cosa Berkeley
effettivamente metta nella cache...

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] Verifica indici...

[Pierangelo Masarati]

 of hash buckets used for page location.
20M Total number of times hash chains searched for a page.
3   The longest hash chain searched for a page.
21M Total number of hash buckets examined for page location.
44M The number of hash bucket locks granted without waiting.
3   The number of hash bucket locks granted after waiting.
2   The maximum number of times any hash bucket lock was waited for.
2526654 The number of region locks granted without waiting.
6035The number of region locks granted after waiting.
844513  The number of page allocations.
1553466 The number of hash buckets examined during allocations
10123   The max number of hash buckets examined for an allocation
769529  The number of pages examined during allocations
4728The max number of pages examined for an allocation
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Pool File: entryCSN.bdb
4096Page size.
0   Requested pages mapped into the process' address space.
46  Requested pages found in the cache (66%).
24  Requested pages not found in the cache.
0   Pages created in the cache.
24  Pages read into the cache.
8   Pages written from the cache to the backing file.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Pool File: dn2id.bdb
4096Page size.
0   Requested pages mapped into the process' address space.
8334140 Requested pages found in the cache (99%).
90655   Requested pages not found in the cache.
0   Pages created in the cache.
90655   Pages read into the cache.
14  Pages written from the cache to the backing file.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Pool File: id2entry.bdb
16384   Page size.
0   Requested pages mapped into the process' address space.
10M Requested pages found in the cache (93%).
753723  Requested pages not found in the cache.
0   Pages created in the cache.
753728  Pages read into the cache.
13  Pages written from the cache to the backing file.

Come vedi, la cache e' di 1 GB, mentre le dimensioni dei files sono

ls -l db/
-rw-r--r--  1 ldapbe ldap   4096 Sep 13 11:13 alock
-rw---  1 ldapbe ldap  12288 Sep  4 15:26
certificateRevocationList.bdb
-rw---  1 ldapbe ldap  237015040 Sep 13 10:35 cn.bdb
-rw---  1 ldapbe ldap  16384 Sep 13 09:30 __db.001
-rw---  1 ldapbe ldap 1073741824 Sep 13 09:30 __db.002
-rw---  1 ldapbe ldap2359296 Sep 13 09:30 __db.003
-rw---  1 ldapbe ldap 450560 Sep 13 09:30 __db.004
-rw---  1 ldapbe ldap  24576 Sep 13 09:30 __db.005
-rw-r--r--  1 ldapbe ldap168 Sep  4 15:27 DB_CONFIG
-rw---  1 ldapbe ldap  125644800 Sep 13 11:13 dn2id.bdb
-rw---  1 ldapbe ldap4464640 Sep 13 11:13 entryCSN.bdb
-rw---  1 ldapbe ldap8204288 Sep 13 10:35 entryUUID.bdb
-rw---  1 ldapbe ldap 1912897536 Sep 13 11:13 id2entry.bdb
-rw---  1 ldapbe ldap3362816 Sep 13 10:35 objectClass.bdb
-rw---  1 ldapbe ldap 167936 Sep  4 15:26 ou.bdb

Quindi la cache ideale sarebbe di piu' di 3 GB, ma gia' cosi' arriviamo ad
una percentuale di hit del 96% e quindi basta.

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] client e server certificati

[Pierangelo Masarati]

> seguendo le varie prodecure
> ./CA -newca
> ./CA -newreq
> ./CA -signreq
> ho creato il certificato per il server ldap
> Nel file di configurazione /etc/ldap.conf ho settato i parametri per dire
> al client dove si trova il certificato del server
> tls_certdir /etc/certs

/etc/ldap.conf di solito non e' il file di configurazione usato dalla
libldap di OpenLDAP

tls_certdir non e' un parametro valido per l'ldap.conf(5) di OpenLDAP

> Ma ora x la gestione dell'autenticazione di un utente ldap che vuole
> collegarsi al server ldap devo ripetere la stessa procedura per il client
> o è già tutto a posto settando i parametri del file /etc/ldap.conf

Che cos'ha a che fare il tls con la "gestione dell'autenticazione"?  Hai
intenzione di usare SASL EXTERNAL basato sui certificati usati per il TLS?

> Inolte i parametri tls_cert e tls_key specificano il certificato e la
> chiave che usa il client:questi non hanno niente a che fare con newkey.pem
> e newcert.pem generati in precedenza per il server?

Se ti riferisci al file ldap.conf(5) usato dalla libldap di OpenLDAP,
Tls_cert & tls_key non possono stare nel file ldap.conf(5), perche' sono
opzioni che hanno senso solo per uno specifico utente o una specifica
applicazione in ogni caso devono stare nel file ldaprc di quell'utente.

Comunque, dato che stai parlando di configurazione del client, ovviamente
i certificati del server non hanno assolutamente nulla a che vedere. 
Ricordo inoltre che, ai fini della verifica, i certificati sia del server
che del client non possono contenere nomi qualunque di fantasia, ma
dovrebbero contenere come nome il FQDN del server a cui si applicano.  O,
almeno, lo devono contenere nel campo subjectAltName, altrimenti la
verifica fallisce.

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] Elenchi in linea LDAP.

[Pierangelo Masarati]

> Salve a tutti,
> Ho configurato un server LDAP per condividere la rubrica
> a tutti gli utenti della mia LAN.
> LDAP gira perfettamente compro ancjhe
> il tool phpldapadmin
> Ho il problema con i clients: con Outlook
> Express funziona bene, con Mozzilla Thunderbid benissomo, con Outlook
> 2000 e Outlook 2003 NON ne vuole sapere, ossia non si connette al srv
> LDAP.
> Qualcumo gentilmente mi può dare una dritta

Il fatto che funzioni perfettamente con gli altri client sembra indicare
che non ci sia nessun problema con il software OpenLDAP.  Quindi, a meno
che tra chi ci legge non ci sia qualcuno che conosce la soluzione, credo
che sia opportuno rivolgersi direttamente al supporto di quel prodotto,
oppure ad un forum dedicato a quel prodotto.

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] Verifica indici...

[Pierangelo Masarati]

Marco Gaiarin wrote:
> Ho un problema di performance con la suite web phpgroupware, e
> contattando gli autori questi mi dicono:
> 
>> it could be the bottelneck. LDAP Is like another DB Engine, if you don't
>> build indexes, you will drop performances ... take a look in the
>> slapd.conf man pages, look for loglevel option, there's a level which
>> trace index misses -> add them to your slapd.conf, rebuilt them using
>> slapindex (IIRC), and you should be ok.

Comunque, indici a parte, il fatto che ci siano problemi di prestazioni
con OpenLDAP 2.3 mi puzza molto di malconfigurazione in generale.  Se un
database e' grande abbastanza da dare prestazioni scarse senza indici
allora e' grande abbastanza da dare prestazioni ridicole senza un
DB_CONFIG decente, una cachesize decente, una idlcachesize decente...

Quindi in ogni caso e' meglio fare un po' di tuning.  Se le cose ancora
vanno male, prova a postare una sequenza delle operazioni che il
software esegue, magari e' mal disegnato l'algoritmo di ricerca.  Se ne
vedono di ogni tipo...

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] Verifica indici...

[Pierangelo Masarati]

Marco Gaiarin wrote:

> A me dava:
> 
>   Sep 12 15:21:55 invernomuto slapd[8811]: <= bdb_equality_candidates: 
> (phpgwGroupID) index_param failed (18) 
> 
> ma il significato direi che è quello.

Si, in effetti fino alla versione scorsa c'era un test malformato per
cui anziche' accorgersi che l'attributo non era indicizzato veniva prima
lanciato il messaggio di errore generico, mi ero scordato (ITS#5037,
rilasciato in 2.3.38).  Comunque il significato e' esattamente lo stesso.

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] Verifica indici...

[Pierangelo Masarati]

Marco Gaiarin wrote:

Ho un problema di performance con la suite web phpgroupware, e
contattando gli autori questi mi dicono:


it could be the bottelneck. LDAP Is like another DB Engine, if you don't
build indexes, you will drop performances ... take a look in the
slapd.conf man pages, look for loglevel option, there's a level which
trace index misses -> add them to your slapd.conf, rebuilt them using
slapindex (IIRC), and you should be ok.


ma verificando nella manpage di slapd.conf mi sembra che, almeno per la
2.3 che uso:

  4096   (0x1000 cache) caching (unused)
  8192   (0x2000 index) data indexing (unused)

e da alcune prove che ho fatto sembra esattamente così.

Posso fare con la 2.3 quello che dicono, o una cosa simile? Grazie.


La 2.3 logga **sempre** (purche' il log sia attivo) quando un attributo 
usato in un filtro non e' indicizzato, con un messaggio tipo


<= bdb_equality_candidates: (uid) not indexed

Non e' un granche' ma dovrebbe bastare a capire quale attributo e quale 
indice sono in causa.


La 2.4, invece, ha anche una feature carina (al momento sperimentale): 
nel back-monitor del back-bdb/hdb sono elencati anche gli attributi 
usati in filtri senza essere indicizzati, con il tipo di indice mancante 
e quante volte e' stato usato:


> ldapsearch -x -H ldap://:9011 \
-b 'cn=Database 1,cn=Databases,cn=Monitor' olmBDBNotIndexed
dn: cn=Database 1,cn=Databases,cn=Monitor
olmBDBNotIndexed: modifyTimestamp#equality=1
olmBDBNotIndexed: telephoneNumber#present=1#approx=1#substr=1

proprio per consentire di valutare se indicizzare o meno.  Dato che 
l'indicizzazione puo' avvenire senza fermare il server, se confiurata 
usando il back-config, questa feature in futuro potrebbe essere 
sfruttata per rendere il database self-tuning, basta decidere in base a 
quale criterio un indice deve essere automaticamente creato in base all'uso.


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] Problemi con l'autenticazione

[Pierangelo Masarati]

[EMAIL PROTECTED] wrote:
> Ho messo su un server LDAP per l'autenticazione centralizzata in una
> piccola rete linux (distribuzione Ubuntu) L'autenticazione funziona
> correttamente utilizzando il componente client dal server stesso, ma
> non dai client locali nei quali si riesce ad entrare solo con le
> password locali...
> 
> Ho modificato slapd.conf fino a permettere:
> 
> access to * by "cn=admin,dc=aula51" write by self write by anonymous
> read
> 
> Infatti una volta loggati anche dai client si riesce a leggere tutto
> il db con ldapsearch -x (senza alcuna password)
> 
> Qualcuno ha idea di come risolvere questo problema?
> 
> Grazie dell'aiuto

Il fatto che i tool ldap (immagino OpenLDAP, come ldapsearch(1) & c.)
funzionino sia dal server che dai client mi fa pensare che non ci sia
nessun problema nella configurazione di OpenLDAP (slapd, in
slapd.conf(5) e client, in ldap.conf(5)).

Il fatto che non funzioni l'autenticazione via LDAP (mi sembra di capire
che il problema sia questo) dovrebbe essere legato ad una
malconfigurazione di pam_ldap ed eventualmente nss_ldap.  Non so se
qualcuno ti puo' aiutare su questa lista, visto che questo software
riguarda solo incidentalmente OpenLDAP; tra l'altro non fornisci
praticamente informazioni utili a tracciare il problema.

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] Entry multiple base64

[Pierangelo Masarati]

Alessandro De Zorzi wrote:
> Salve, facendo un dump di un oggetto che
> ha degli attributi multipli ho notato
> che alcuni di questi sono scritti in base64
> 
> [1]
> maildrop:: YWZzZA0=
> maildrop:: YXNkZg0=
> maildrop: [EMAIL PROTECTED]
> 
> [2]
> maildrop:: ZHVlQGFkcy5zZA0=
> maildrop: [EMAIL PROTECTED]
> 
> [3]
> maildrop: [EMAIL PROTECTED]
> maildrop: [EMAIL PROTECTED]
> 
> ho verificato che in effetti se aggiungo i valori uno per volta
> li ottengo come nel caso [3] mentre se li aggiungo tramite un array
> ottengo il risultato del caso [1] e [2]
> 
> il fatto è che interagisco con LDAP tramite la funzione ldap_mod_add()
> è chiaro che il problema è lato PHP ma volevo sapere con che logica
> OpenLDAP decide di scrivere in base64 per poi trovare una soluzione
> a monte poiché con l'analoga funzione ldap_mod_del() non riesco
> a cancellare alcuni valori quando sono nei casi [1] e [2]

Credo che il problema sia alla fonte.  Per esempio:

echo -n "YWZzZA0=" | base64 -d | od -c
000   a   f   s   d  \r
005

Quindi e' rimasto un '\r' alla fine del valore (copia e incolla da
Windows?).  OpenLDAP mostra in base64 i valori non stampabili, quindi i
valori che !isascii(3) e !isprint(3) (e '\r' non lo e').

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

[Pierangelo Masarati]

Alessandro De Zorzi wrote:

Pierangelo Masarati wrote:

Inoltre, OpenLDAP supporta SASL EXTERNAL basato su TLS, per il quale
la verifica dei certificati corrisponde ad autenticazione e
l'identita' del client viene vista come il DN del certificato
(opzionalmente rimappato con le regole authz-regexp).  In questo caso,
un certificato self-signed, in genere comunque da evitare, non e'
proprio possibile.



purtroppo non sono in grado di seguire questa analisi così approfondita :-P


In realta' e' incredibilmente semplice, una volta che la configurazione 
TLS e' a posto.



rimanendo sui principi generali che condivido (evitare certificati
self-sign)
mi piacerebbe sapere se nella configurazione descritta OpenLDAP verifica un
certificato firmato da CaCert.org se il certificato Root di CaCert.org è già
disponibile sul sistema


OpenLDAP non fa distinzione di razza, sesso o colore delle CA con cui lo 
configuri :).  Scherzi a parte, io finora ho solo provato con 
certificati generati dalla "mia" CA (CA.sh e simili), e con un solo CA 
certificate in TLSCACertificateFile (slapd.conf(5)) e TLS_CACERT 
(ldap.conf(5)).  Comunque non ci dovrebbero essere problemi.


A (s)proposito, mentre fino a OpenLDAP 2.3 la manipolazione dei 
certificati era delegata a OpenSSL, in OpenLDAP 2.4 viene in parte 
spostata all'interno di slapd (verifica sintattica, estrazione di 
informazioni ecc.), in quanto 2.4 supporta anche GNUtls.  Si parla di un 
obbiettivo remoto in cui tutto SSL sara' gestito nativamente all'interno 
di slapd.


Solo che "ogni tanto" salta fuori ancora qualche bachetto (tipo che non 
accettava i certificati SSLv1, oppure quelli con serial number > 2^31-1, 
che e' l'intero piu' grande LDAP ma non X.509; fissati da poco).  Se 
qualcuno ha voglia di giocare con OpenLDAP 2.4.5 appena uscita, magari 
con certificati strani, ci fa un favore.


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

[Pierangelo Masarati]

Alessandro De Zorzi wrote:


per LDAP penso sia sufficiente avere un canale di comunicazione
criptato, quindi un certificato self-sign con CA fittizzia



Se ti accontenti di un canale crittato si', ma non ti protegge da 
"man-in-the-middle".  Per usare un certificato self-signed il client 
deve essere configurato con "TLS_REQCERT never" (vedi ldap.conf(5); NON 
E' IL DEFAULT), e il server con "TLSVerifyClient never" (questo invece 
e' il default).


Inoltre, OpenLDAP supporta SASL EXTERNAL basato su TLS, per il quale la 
verifica dei certificati corrisponde ad autenticazione e l'identita' del 
client viene vista come il DN del certificato (opzionalmente rimappato 
con le regole authz-regexp).  In questo caso, un certificato 
self-signed, in genere comunque da evitare, non e' proprio possibile.


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

[Pierangelo Masarati]

Marco Gaiarin wrote:


Di questa cosa ne avevamo parlato prima dell'estate, debian è il bene,
non fallisce mai... ;)))


In questo caso, che cosa sia il bene lo decido io ;-o

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] Migrazione della replica...

[Pierangelo Masarati]

Marco Gaiarin wrote:


...ahem, intendevo dire se occorre mettere manco anche allo slapd.conf
del master,


:)


ma mi hai risposto comunque visto che il link che citi
suggerisce:

overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100

Quindi si, occorre modificare anche la configurazione del master. ;)


E' un'altra differenza trai 2.2 e 2.3: prima il provider era annegato 
nel server, mentre ora e' un overlay che occorre istanziare apposta.  I 
due parametri che hai aggiunto sono opzionali, servono per migliorare le 
prestazioni passando da state-based (il defalt) a log-based (dettaglio 
implementativo).


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

[Pierangelo Masarati]

Cristian Manfredini wrote:
> Salve a tutti,
> ho bisogno di una dritta per risolvere il seguente errore bloccante
> che riscontro dopo essere passato alla versione 2.3 su debian etch.

Che corrisponde a quale versione OpenLDAP?

> Ogni 5/6 giorni il servizio schianta con il seguente messaggio:

...

> il file log.13 risulta con diritti root:root (invece che
> openldap:openldap) e il server non riparte fintato che non cancello
> tutti i log.xxx della cartella.

Innanzitutto una domanda: Debian lancia ancora il db_recover ad ogni
avvio?  Nella versione 2.3 non e' piu' necessario (non lo e' mai stato,
ma la gente e' sempre troppo prudente quando non serve), anzi dannoso.
Nel caso, toglilo.

Poi: per caso, lancia un db_checkpoint da crontab come utente root?  Nel
caso, toglio e usa la direttiva "checkpoint" nella stanza del database.

Inoltre mi sembra di ricordare, ma non sono sicuro, che ci fosse un
problema da qualche parte (non riesco a trovare i riferimenti) per cui
alcuni accessi a files del DB da parte di un tool ne cambiavano
ownership/permissions, e che e' stato fissato.  A meno che tu non stia
usando una versione **molto** recente (2.3.37 o 2.3.38) ti consiglio di
aggiornare e provare.

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] Migrazione della replica...

[Pierangelo Masarati]

Marco Gaiarin wrote:

Sto usando debian sarge e openldap 2.2, configurato con la replica
'vecchia maniera':

# Sul master
#
replica uri=ldaps://trinity.sv.lnf.it
binddn="cn=replica,dc=sv,dc=lnf,dc=it"
bindmethod=simple
credentials=nonvtelado

# Sullo slave
#
updatedn "cn=replica,dc=sv,dc=lnf,dc=it"
updateref ldaps://ldap.sv.lnf.it

ora ovviamente vorrei passare a syncrepl in fase di aggornamento ad
etch (openldap 2.3).

Mi basta rivedere la faccenda alla luce di:

http://www.openldap.org/faq/data/cache/1117.html


+ o -; ci sono alcune inesattezze dovute all'evoluzione di syncrepl; ad 
esempio, la prima che mi salta all'occhio: "updatedn" non e' piu' 
necessario nella direttiva syncrepl.


Suggerisco vivamente di fare riferimento alla guida 
(<http://www.openldap.org/doc/admin23/>, in particolare 
<http://www.openldap.org/doc/admin23/syncrepl.html>), che e' stata di 
molto migliorata (e lo sara' parecchio di piu' con 2.4, c'e' una persona 
che si occupa "a tempo pieno" dell'aggiornamento dei documenti).




? In particolare, la configurazione con syncrepl è 'slave only', ho
capito bene?


Con 2.3 si.  Con 2.4 potra' essere anche configurato mirror-mode (ovvero 
tipo multimaster), anche se ho ancora qualche riserva (nel senso che 
probabilmente ci sono ancora dei bug da risolvere).


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] supporto operazione estesa

[Pierangelo Masarati]

> Per configurarlo in modo che supporti l'operazione estesa cosa devo
> fare?modificare dei file di configurazione?se si quali e come?

Configurare il TLS lato server, come descritto in
<http://www.openldap.org/doc/admin23/tls.html>.  Se il TLS non e'
configurato, slapd non puo' supportare StartTLS.

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] messaggio d'errore

[Pierangelo Masarati]

puestadelsol83 wrote:

Con ldappasswd sto cercando di modificare la password di un utente ldap.
Ottengo invece il seguente messaggio d'errore:

ldap_start_tls: Protocol error(2)
additional info:unsupported extended operation

cosa devo fare per risolvere il problema?


Utilizare un server che supporti l'operazione estesa 
1.3.6.1.4.1.1466.20037 (StartTLS, RFC 4511)


> Da cosa dipende?

Dal fatto che il server non e' in grado di, o non e' configurato per, 
supportare quell'operazione estesa.


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: crittazione del traffico via SSL/TLS

[Pierangelo Masarati]

> *Function* pla_error
> 
> Array
> (
>[0] => Could not connect to "ldaps://ferret.tomato.lan" on port "636"
> )
> 
>  *File* /usr/local/www/phpldapadmin/htdocs/login.php (125)
> *Function* connect
> 
> Array
> (
>[0] => 1
>[1] => user
>[2] => 1
> )
> 
> 
> 
> 
> slapd log:
> 
> conn=14 fd=11 ACCEPT from IP=192.168.1.19:59245 (IP=0.0.0.0:636)
> TLS: can't accept.
> TLS: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca
> s3_pkt.c:1053
> conn=14 fd=11 closed (TLS negotiation failure)

Ma phpldapadmin tenta la connessione per conto suo, non passa da PAM;
quindi occorre capire come occorre configurare la relativa
configurazione di libldap lato client.  In ogni caso, non mi sembra che
siano problemi OpenLDAP, ma semmai di come viene usato.  Se utilizzassi
la libldap di mozilla, o qualsiasi altra API, avresti problemi analoghi
(o meglio, la soluzione consisterebbe comunque nel cercare di capire
come questi prodotti devono essere configurati per operare correttamente).

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: crittazione del traffico via SSL/TLS

[Pierangelo Masarati]

> Pierangelo Masarati wrote:


> /usr/local/etc/openldap/ldap.conf:
>
> base dc=test,dc=org
> uri ldaps://ferret.tomato.lan:636
> bind_policy soft

^^^ Questa direttiva non e' riconosciuta da OpenLDAP, meglio toglierla

>
> TLS_REQCERT never


> TLS_CERT /usr/local/etc/openldap/ldap.client.pem
> TLS_KEY /usr/local/etc/openldap/ldap.client.key.pem

^^^ queste due direttive sono ignorate, in quanto sono "user only" (come
indicato in ldap.conf(5) di OpenLDAP), mentre questo e' il file di
sistema.  Non ha senso mettere una chiave privata in un file che e'
leggibile globalmente.  La chiave privata puo' solo essere definita nel
file specifico di un utente (o di un'applicazione, come nel pam_ldap).

> TLS_CACERT /usr/local/etc/openldap/cacert.pem
> #TLS_CIPHER_SUITE HIGH:MEDIUM:+SSLv2
>
> [EMAIL PROTECTED]:~ >ps -auxww | grep slapd
> ldap  17893  0.0  1.4 45940 35800  p4  S+4:30PM   0:00.78
> usr/local/libexec/slapd -h ldapi://%2fvar%2frun%2fopenldap%2fldapi/
> ldap:/// ldaps:/// -s-1 -d256 -u ldap -g ldap
> [EMAIL PROTECTED]:~ >ldapsearch -b "dc=test,dc=org"

Ti faccio notare che l'esecuzione di questo comando, data la
configurazione che hai mostrato, non prevede nessuna validazione, da parte
del server, del certificato del client (in quanto, avendo messp
TLS_CERT/TLS_KEY nell'ldap.conf di sistema, e' come non averli messi
affatto; d'altra parte, il server e' stato configurato per non verificare
il certificato del client.

Allo stesso modo, il client non verifica il certificato del server (anche
se potrebbe, e dovrebbe!) in quanto TLS_REQCERT e' "never".


> Da questo deduco che:
> -ldaps/certificati funzionano
> -il server e' configurato correttamnente per ricevere
>  richieste da eventuali client
>
> Ora pero' il mio problema si e' spostato sui client (ad esempio pam/nss)
> i quali non ne vogliono
> sapere di funzionare su ldaps:
>
> /usr/local/etc/ldap.conf - /usr/local/etc/nss_ldap.conf:
>
> base dc=test,dc=org
> #uri ldaps://ferret.tomato.lan:636
> uri ldap://ferret.tomato.lan
> bind_policy soft
>
> sudoers_base ou=SUDOers,dc=test,dc=org
> pam_groupdn cn=smtp_box,ou=groups,dc=test,dc=org
> pam_member_attribute memberUid

Questo attributo e' invalido; ho verificato la documentazione del pam_ldap
e in effetti e' ambigua, ma ti assicuro (dalla lettura del codice) che il
confronto per l'appartenenza ai gruppi avviene tra i valori di
pam_member_attribute e il DN della entry dello user, mentre memberUid e'
un numero, non un DN, quindi la richiesta fallisce sicuramente.

>
> tls_checkpeer no
> tls_cacertfile /usr/local/etc/openldap/cacert.pem
> tls_cert /usr/local/etc/openldap/ldap.client.pem
> tls_key /usr/local/etc/openldap/ldap.client.key.pem

In questo caso, si tratta del file di un'applicazione e non di quello di
sistema; credo di capire che l'applicazione, quindi, essendo configurata
con tls_cert, tls_key, in ogni caso manda il proprio certificato al
server, anche se questo poi e' configurato per non verificarla...

>
> utilizzando la 389 ssh funziona correttamnente e mi posso collegare con
> utente testuser e/o utilizzando l'utente definito sulla mia macchina in
> /etc/passwd.
> Al contrario, se decommento la riga "#uri ldaps://ferret.tomato.lan:636"
> nel file sopra citato, ssh smette di funzionare in tutti i sensi:
>
> [EMAIL PROTECTED]:~ >ssh [EMAIL PROTECTED]
> Connection closed by 127.0.0.1
> [EMAIL PROTECTED]:~ >
>
> slapd log:
>
> conn=41 fd=14 ACCEPT from IP=192.168.1.19:58542 (IP=0.0.0.0:636)
> TLS: can't accept.
> conn=41 fd=14 closed (TLS negotiation failure)
>
> medesima cosa accade se configuro phpldapadmin per usare ldaps al posto
> di ldap:
>
> phpldapadmin:
>
> *Could not connect to "ldaps://ferret.tomato.lan" on port "636"*
>
> *Backtrace*
>   *PHP Version*   5.2.3
>   *PLA Version*   1.0.2
>   *PHP SAPI*  apache2handler
>   *Web Server*Apache/2.2.4 (FreeBSD) DAV/2 PHP/5.2.3 with
> Suhosin-Patch mod_ssl/2.2.4 OpenSSL/0.9.8e
>
>   *File*  /usr/local/www/phpldapadmin/lib/server_functions.php (353)
> *Function*pla_error
>
> Array
> (
> [0] => Could not connect to "ldaps://ferret.tomato.lan" on port "636"
> )
>
>
>   *File*  /usr/local/www/phpldapadmin/htdocs/login.php (125)
> *Function*connect
>
> Array
> (
> [0] => 1
> [1] => user
> [2] => 1
> )
>
>
>
> log slapd:
>
> conn=47 fd=14 ACCEPT from IP=192.168.1.19:63045 (IP=0.0.0.0:636)
> TLS: can't accept.
> TLS: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert

Re: [OpenLDAP] openldap e apache

[Pierangelo Masarati]

puestadelsol83 wrote:
> Volevo chiede se per il servizio di Ldap è necessario installare apache.

Non mi sembra che Apache, o altro http server, sia mai menzionato nella
documentazione di OpenLDAP.  Non capisco proprio come ti sia potuta
venire un'idea del genere.  La lista del software terzo richiesto e' in
<http://www.openldap.org/doc/admin23/install.html#Prerequisite%20software>.

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: crittazione del traffico via SSL/TLS

[Pierangelo Masarati]

ERT...
>>
> 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(0003)
>>> 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
OpenLDAP@sys-net.it
https://www.sys-net.it/mailman/listinfo/openldap

Re: [OpenLDAP] OpenLDAP: crittazione del traffico via SSL/TLS

[Pierangelo Masarati]

930  0.0  1.4 45948 35416  ??  Is   11:40AM   0:01.03
> /usr/local/libexec/slapd -h ldapi://%2fvar%2frun%2fopenldap%2fldapi/
> ldap:/// ldaps:/// -s-1 -u ldap -g ldap
>
> Lo step successivo consisnte nell'"autenticare" alcuni client (sshd nel
> mio caso) attraverso ldap: allo stato attuale questo mi riesce ma solo
> utilizzando
> traffico in chiaro, e con l'attivazione di SSL/TSL spero di chiudere
> quest'ultima falla cosi' da poter mandare in produzione la mia prima
> installazione LDAP :)
>
> bye,
> P.
>
> [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, ...).

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] ldappasswd messaggio d'errore

[Pierangelo Masarati]

Per favore, posta le risposte alla lista.  La politica aziendale impone 
che risposte personali siano date solo ai clienti.


puestadelsol83 wrote:

Ma questo vuol dire che ho devo richiedere un certificato?


Si, oppure che te lo generi con una tua CA (ad esempio con openssl)

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] ldappasswd messaggio d'errore

[Pierangelo Masarati]

puestadelsol83 wrote:

Come mi avete suggerito ho usato il comando passwd per cambiare la password di 
un utente.
Però ottengo il seguente messaggio d'errore:

Result:Confidentiality required (13)
Additional info: Operation requires a secure connection.

IL messaggio è relativo credo x la mancanza di una connessione sicura ssl ma 
non ho idea di come risolvere questo problema.


Puoi:

1) disabilitare la richiesta di connessione sicura per le modifiche 
(sconsigliato, ma di default non e' richiesto; vedi slapd.conf(5) 
"require" e "security").


2) usare TLS
Per istruzioni lato client, man ldap.conf(5) TLS OPTIONS e 
<http://www.openldap.org/doc/admin23/tls.html>.


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] /etc/ldap.conf

[Pierangelo Masarati]

puestadelsol83 wrote:

Per impostare i parametri x gestire la password di un utente devono essere 
modificati alcuni parametri di questo file?
Se si quali?


nessuno.

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