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: Dael.Maselli@LNF.INFN.IT

F I N E

Altro materiale ed esecitazione:

http://wiki.infn.it/cn/ccr/aai/howto/389ds-1.x-install