Francesco Malvezzi ha scritto:
In pratica i database ldap Studenti, UtentiLocali ed Utenti fisicamente
risiedono o risiederanno( per Utenti) sul server di Caltanissetta, il
primo e l'ultimo sono frutto di una sincronizzazione.
PA1(Studenti)--syncreply-->server CL
serverCL con database locale UtentiLocali
PA2(Utenti da implementare)--syncreply-->server CL
Se hai gli ou distinti, quindi questo e' gia' a posto: se ordini i
database cosi':
#questo e' PA1
database hdb
suffix "ou=students,dc=unipa,dc=it"
subordinate
syncrepl [...]
#questo e' PA2
database hdb
suffix "ou=people,dc=unipa,dc=it"
subordinate
syncrepl [...]
Nel mio caso
database hdb
suffix "ou=Studenti,dc=unipa,dc=it"
subordinate
syncrepl [..
#questo e' serverCL
database hdb
suffix "dc=unipa,dc=it"
ovviamente gli users del serveCL avranno ou=users,dc=unipa,dc=it.
Avrai anche l'albero ou=computers in serverCL (per samba) e questo puo'
gia' dare servizi come PDC samba.
Quindi se ho capito (l'ho fatto un po' in automatico) sul server di CL
ho messo come suffix
suffix "dc=unipa,dc=it"
ma attraverso l'utility smbldap-tools nella configurazione
(smbldap.conf) inserisco come riferimento
usersdn="ou=Utenti,${suffix}"
computersdn="ou=Computers,${suffix}"
e funziona alla grande!
- Trapani: per vari motivi, tranne per il database UtentiLocali, i
dati non dovrebbero risiedere localmente qundi sono proxati
PA1(Studenti)--proxati-->server TP
serverTP con database locale UtentiLocali
PA2(Utenti da implementare)--proxati-->server TP
nessuno dei due server da me gestiti farà da producer ad altri server
Prima di provare slapo-meta proverei due backend ldap, sempre in glue.
Ho paura pero' che mentre con samba (che usa sempre lo stesso principal)
non dovrebbe essere difficile scrivere le regole di idassert-bind, sara'
piu' difficile permettere che un client ldap arbitrario (ad es apache
mod_ldap_authnz) autentichi come si deve gli utenti, cioe' fare in modo
che il server di TP trasferisca una bind autenticata con le credenziali
dell'utente alla proxy (PA).
Anche qui ho fatto l'ipotesi che gli alberi siano separati per i vari db.
Ciao,
Francesco
A me serve l'autenticazione esclusivamente di samba, ma come mi insegni
gli sviluppi poi sono imprevisti. Comunque mi fermerei a samba.
Piuttosto come lo implementeresti, tipo
ho trovato quest'esempio che ho modificato sulla mia esigenza
uri "ldap://PA1/ou=Studenti <ldap://192.168.1.10/dc=target>dc=unipa,dc=it"
*idassert-bind* *bindmethod*=simple
*binddn*="cn=Proxy,ou=Admin,dc=remote,dc=example,dc=com"
Questo fa riferimento ad una entryche dovrebbe esserci sul database remoto
necessario ed effettuare l'autenticazione del server CL?
*authcID*=proxy
*credentials*=proxy
*authzID*="dn:cn=Sandbox,dc=local,dc=example,dc=com"
*authz*=native
PS: queste soluzioni non sono senza problemi: su un albero in syncrepl
non c'e' possibilita' di scrittura per cui se riesci a permettere ai
tuoi utenti samba di cambiarsi la passwd con CTRL-ALT_CANC su windows
per favore dimmi come hai fatto che mi interessa.
No, ci ho provato anche io e secondo me è corretto che non si possa
cambiare la password dato che è una replicazione di un database e in
questo caso si creerebbe una situazione di "inconsistenza" fra database
master e database sincronizzato (slave). Io il problema non me lo sono
posto perché gli utenti attraverso una procedura sul sito universitario
si possono cambiare la password, ma sul database principale e quindi
propagarla su a quello secondario.
Ciao
Luigi
------------------------------------------------------------------------
_______________________________________________
OpenLDAP mailing list
OpenLDAP@mail.sys-net.it
https://www.sys-net.it/mailman/listinfo/openldap
--
_______________________________________________________________________
Augello Luigi
Amministratore di Sistema Poli didattici di Agrigento,
Caltanissetta e Trapani
Università degli Studi di Palermo
tel 093420928
VoIP 09123865802
_______________________________________________
OpenLDAP mailing list
OpenLDAP@mail.sys-net.it
https://www.sys-net.it/mailman/listinfo/openldap
