389 Directory Server Dael Maselli Funzionalita principali n

  • Slides: 21
Download presentation
389 Directory Server Dael Maselli

389 Directory Server Dael Maselli

Funzionalita’ principali n n n Replica Multi-Master fino a 4 nodi Connessione e autenticazione

Funzionalita’ principali n n n Replica Multi-Master fino a 4 nodi Connessione e autenticazione sicura (SSLv 3, TLSv 1 e SASL) Codice sviluppato da 10 anni ¨ 389 ds discende direttamente da Red. Hat DS, che a sua volta viene da Netscape DS, il quale e’ stato sviluppato insieme Sun One DS (i. Planet) n Documentazione molto completa ¨ E’ n possibile fare riferimento a Red. Hat DS: http: //www. redhat. com/docs/manuals/dir-server/ 2

Funzionalita’ principali Supporto per LDAPv 3 n Schema update, configurazione e Access Control Information

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

Architettura 389 Directory Server e’ composto dai seguenti componenti n Un server front-end, responsabile

Architettura 389 Directory Server e’ composto dai seguenti componenti n Un server front-end, responsabile delle comunicazioni di rete n 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 n Un directory tree privato contenente informazioni per il server (configurazione) 4

Basic Directory Tree n cn=config ¨ Subtree 389 ds n contenente la configurazione di

Basic Directory Tree n cn=config ¨ Subtree 389 ds n contenente la configurazione di base di o=Netscape. Root ¨ Subtree contentente le configurazioni di altri server come l’Administration Server n o=user. Root ¨ Subtree dc=it utente, nel nostro caso si chiamera’: dc=infn, 5

Database back-end (1) n n n Il database back-end e’ il plugin che gestisce

Database back-end (1) n n n Il database back-end e’ il plugin che gestisce tutto lo storage utente I dati vengono archiviati tramite Berkeley. DB 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 6

Database back-end (2) Ad ogni ramo della directory puo' essere associato un DB n

Database back-end (2) Ad ogni ramo della directory puo' essere associato un DB n Per semplicita' si puo' pensare in modo analogo al mount di un filesystem in un albero di directory n Dal "mount point" in giu' le informazioni risiedono su DB diverso dal precedente n 7

Access control Il controllo degli accessi viene gestito attraverso le ACI (Access Control Information)

Access control Il controllo degli accessi viene gestito attraverso le ACI (Access Control Information) n L’ACI e’ un attributo amministrativo inseribile in una qualsiasi entry del DS n Le ACI vengono ereditate dagli eventuali figli della entry in cui e’ inserita n 8

Elementi dell’ACI n Target ¨ n Subject / Bind Rule ¨ n Rappresenta l’oggetto

Elementi dell’ACI n Target ¨ n Subject / Bind Rule ¨ n Rappresenta l’oggetto dell’ACI: entry e attributi 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: ///infn. Person. UUID=a 1 ddcca 3 -37 d 3 -4149 -819 d-ad 1 e 37165547, dc=infn, dc=it“ ) ( targetattr=login. Shell ) ( version 3. 0; acl “sample"; allow (write, delete) userdn="ldap: ///self"; and (dns="*. infn. it") and (dayofweek = "Sun") and (timeofday >= "900“ and timeofday < "1100") ) 9

Wildcard e Filtri nelle ACI n Nel Target e nel Subject (dn, ip, dns)

Wildcard e Filtri nelle ACI n Nel Target e nel Subject (dn, ip, dns) e’ possibile inserire delle wildcard ¨ es: (target="ldap: ///infn. Person. UUID=*, dc=infn, dc=it") n 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 object. Class che termina con "user" 10

Ordine di valutazione delle ACI n n n Non esiste un ordine gerarchico nella

Ordine di valutazione delle ACI n n n 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 11

Replica n n n Le repliche vengono effettuate a livello di Database Il traffico

Replica n n n 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 12

Replica Master-Slave n n n Il supplier e' il nodo che fornisce i dati

Replica Master-Slave n n n 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 n Un consumer puo' a sua volta reinviare ogni update ricevuto ad un altro consumer, in tal caso il nodo viene chiamato hub 13

Replica Multi-Master n Nella replica multi-master e’ possibile scrivere contemporaneamente su piu’ nodi ¨

Replica Multi-Master n 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 14

GSSAPI, SASL & Kerberos 5 389 ds supporta GSSAPI tramite mapping SASL per l’autenticazione

GSSAPI, SASL & Kerberos 5 389 ds supporta GSSAPI tramite mapping SASL per l’autenticazione tramite ticket Kerberos 5 n E possibile configurare delle regular expression per il matching del Principal negli attributi: n dn: cn=krb 5, cn=mapping, cn=sasl, cn=config object. Class: top object. Class: ns. Sasl. Mapping cn: krb 5 ns. Sasl. Map. Regex. String: (. *) ns. Sasl. Map. Base. DNTemplate: ou=People, dc=infn, dc=it ns. Sasl. Map. Filter. Template: (infn. Account. Kerberos. Principal=1) 15

Plug-in di autenticazione E’ possibile inoltrare le richieste di Bind (username&password) di 389 ds

Plug-in di autenticazione E’ possibile inoltrare le richieste di Bind (username&password) di 389 ds ad un altro metodo di autenticazione n Tramite plug-in nativi 389 ds ¨ Pam n passthru Oppure scrivendo dei plug-in custom ¨ Ne e' stato scritto uno da Fulvio per l'autenticazione user/pass Kerberos 5 16

389 Management Console n n E' lo strumento grafico principale di 389 ds Da

389 Management Console n n E' lo strumento grafico principale di 389 ds Da questo e' possibile gestire: ¨ Directory ¨ Access Control Information (ACI) ¨ Configurazione n Plug-in n Replica n Back-up n. . . ¨. . . 17

389 Management Console 18

389 Management Console 18

389 Management Console 19

389 Management Console 19

389 Management Console 20

389 Management Console 20

F I N E Altro materiale ed esecitazione: http: //wiki. infn. it/cn/ccr/aai/howto/3 89 ds-1.

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