389 directory server dael maselli. 2 funzionalita principali replica multi-master fino a 4 nodi...
TRANSCRIPT
389 Directory Server
Dael Maselli
2
Funzionalita’ principali
Replica Multi-Master fino a 4 nodi Connessione e autenticazione sicura (SSLv3,
TLSv1 e SASL) Codice sviluppato da 10 anni
389ds discende direttamente da RedHat DS, che a sua volta viene da Netscape DS, il quale e’ stato sviluppato insieme Sun One DS (iPlanet)
Documentazione molto completa E’ possibile fare riferimento a RedHat DS:
http://www.redhat.com/docs/manuals/dir-server/
3
Funzionalita’ principali
Supporto per LDAPv3 Schema update, configurazione e Access
Control Information (ACIs) on-line Console grafica per la gestione della
configurazione
4
Architettura
389 Directory Server e’ composto dai seguenti componenti
Un server front-end, responsabile delle comunicazioni di rete
Plug-in per funzionalita’ del server come permessi di accesso e replica Plug-in di back-end del database dove risiedono i dati
del server Un directory tree privato contenente informazioni
per il server (configurazione)
5
Basic Directory Tree
cn=config Subtree contenente la configurazione di base di 389ds
o=NetscapeRoot Subtree contentente le configurazioni di altri server
come l’Administration Server o=userRoot
Subtree utente, nel nostro caso si chiamera’: dc=infn, dc=it
6
Database back-end (1)
Il database back-end e’ il plugin che gestisce tutto lo storage utente
I dati vengono archiviati tramite BerkeleyDB La configurazione base e gli schema risiedono
invece in file di testo LDIF caricati allo start-up: “cn=config”: /etc/dirsrv/slapd-[instance]/config/dse.ldif
Schema: /etc/dirsrv/slapd-[instance]/config/schema/*.ldif
7
Database back-end (2)
Ad ogni ramo della directory puo' essere associato un DB
Per semplicita' si puo' pensare in modo analogo al mount di un filesystem in un albero di directory
Dal "mount point" in giu' le informazioni risiedono su DB diverso dal precedente
8
Access control
Il controllo degli accessi viene gestito attraverso le ACI (Access Control Information)
L’ACI e’ un attributo amministrativo inseribile in una qualsiasi entry del DS
Le ACI vengono ereditate dagli eventuali figli della entry in cui e’ inserita
9
Elementi dell’ACI Target
Rappresenta l’oggetto dell’ACI: entry e attributi Subject / Bind Rule
Rappresenta il soggetto (chi, da dove, come, quando) che accede al target
Type of Access / Permission E’ l’elenco delle azioni permesse o negate al Subject sul Target
aci: ( target="ldap:///infnPersonUUID=a1ddcca3-37d3-4149-819d-ad1e37165547,dc=infn, dc=it“ )
( targetattr=loginShell )( version 3.0;acl “sample"; allow (write,delete) userdn="ldap:///self"; and (dns="*.infn.it") and (dayofweek = "Sun")
and (timeofday >= "900“ and timeofday < "1100") )
10
Wildcard e Filtri nelle ACI
Nel Target e nel Subject (dn, ip, dns) e’ possibile inserire delle wildcard
es: (target="ldap:///infnPersonUUID=*,dc=infn,dc=it")
E’ possibile limitare il Target attraverso dei filtri controllando il contenuto degli attributi
es: (targetfilter=(telephonenumber=06*))
In questo modo l'ACI definira' l'accesso solo verso le entry che hanno un objectClass che termina con "user"
11
Ordine di valutazione delle ACI
Non esiste un ordine gerarchico nella valutazione delle ACI
Le ACI applicabili ad una Entry vengono valutate complessivamente
I Deny hanno priorita’ sugli Allow I permessi di Allow sono dati dall’unione dei vari
Allow applicabili Se non c’e’ alcun match ogni operazione viene
negata
12
Replica
Le repliche vengono effettuate a livello di Database
Il traffico LDAP per le repliche puo' essere cifrato tramite SSL
Autenticazione tra i nodi coinvolti tramite:PasswordSSL PKI
13
Replica Master-Slave
Il supplier e' il nodo che fornisce i dati (master) Il consumer e' invece quello che li riceve (slave) In un supplier deve essere configurato un
replication agreement per ogni consumer E' il processo che si occupa di inviare gli
aggiornamenti
Un consumer puo' a sua volta reinviare ogni update ricevuto ad un altro consumer, in tal caso il nodo viene chiamato hub
14
Replica Multi-Master
Nella replica multi-master e’ possibile scrivere contemporaneamente su piu’ nodiOgni entry ha un attributo di timestamp
dell’ultima modificaEventuali conflitti verranno risolti
automaticamente (the last wins)
In una replica Multi Master ogni nodo e' contemporaneamente supplier e consumer
15
GSSAPI, SASL & Kerberos5
389ds supporta GSSAPI tramite mapping SASL per l’autenticazione tramite ticket Kerberos5
E possibile configurare delle regular expression per il matching del Principal negli attributi:
dn: cn=krb5,cn=mapping,cn=sasl,cn=configobjectClass: topobjectClass: nsSaslMappingcn: krb5nsSaslMapRegexString: \(.*\)nsSaslMapBaseDNTemplate: ou=People, dc=infn, dc=itnsSaslMapFilterTemplate: (infnAccountKerberosPrincipal=\1)
16
Plug-in di autenticazione
E’ possibile inoltrare le richieste di Bind (username&password) di 389ds ad un altro metodo di autenticazione
Tramite plug-in nativi 389dsPam passthru
Oppure scrivendo dei plug-in customNe e' stato scritto uno da Fulvio per
l'autenticazione user/pass Kerberos5
17
389 Management Console E' lo strumento grafico principale di 389ds Da questo e' possibile gestire:
Directory Access Control Information (ACI) Configurazione
Plug-in Replica Back-up ...
...
18
389 Management Console
19
389 Management Console
20
389 Management Console
21
Dael Maselli
e-mail: [email protected]
F I N E
Altro materiale ed esecitazione:
http://wiki.infn.it/cn/ccr/aai/howto/389ds-1.x-install