389 Directory Server Dael Maselli

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/

Funzionalita’ principali Supporto per LDAPv3 Schema update, configurazione e Access Control Information (ACIs) on-line Console grafica per la gestione della configurazione

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)

Basic Directory Tree cn=config o=NetscapeRoot o=userRoot 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

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

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

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

Elementi dell’ACI Target Subject / Bind Rule 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") )

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"

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

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: Password SSL PKI

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

contemporaneamente supplier e consumer Replica Multi-Master Nella replica multi-master e’ possibile scrivere contemporaneamente su piu’ nodi Ogni entry ha un attributo di timestamp dell’ultima modifica Eventuali conflitti verranno risolti automaticamente (the last wins) In una replica Multi Master ogni nodo e' contemporaneamente supplier e consumer

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=config objectClass: top objectClass: nsSaslMapping cn: krb5 nsSaslMapRegexString: \(.*\) nsSaslMapBaseDNTemplate: ou=People, dc=infn, dc=it nsSaslMapFilterTemplate: (infnAccountKerberosPrincipal=\1)

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 389ds Pam passthru Oppure scrivendo dei plug-in custom Ne e' stato scritto uno da Fulvio per l'autenticazione user/pass Kerberos5

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

389 Management Console

389 Management Console

389 Management Console

Altro materiale ed esecitazione: F I N E Altro materiale ed esecitazione: http://wiki.infn.it/cn/ccr/aai/howto/389ds-1.x-install Dael Maselli e-mail: Dael.Maselli@LNF.INFN.IT