Introduzione ai Directory Services & LDAP (02/06/2017)
Nel corso dell’ultimo decennio le directory LDAP sono diventate il centro nervoso delle
infrastrutture informatiche ai fini di fornire spazi di nomi, localizzazione, gestione, sicurezza e
numerosi altri servizi che tradizionalmente vengono forniti dai sistemi operativi.
Cos’è una Directory
Anche se non ce ne rendiamo conto tutti abbiamo familiarità con vari servizi di directory.
Costituiscono esempi di directory della vita di tutti i giorni (offline directories) gli elenchi telefonici
(pagine bianche e gialle), guide TV, cataloghi per gli acquisti, …
E’ chiaro che le directory aiutano a reperire informazioni, descrivendo ed organizzando le stesse in
modo da renderle facilmente reperibili.
Le directory del mondo computazionale, ovvero le online directories, differiscono dalle offline
principalmente per i seguenti motivi:
sono dinamiche
sono flessibili
possono essere rese sicure
possono essere personalizzate
A loro volta le online directories possono essere suddivise nelle seguenti categorie:
Application specific directories: sono in bundle o integrate nell’ applicativo (Lotus Notes
Name&Address book, Exchange (versioni pre-2000) directory
Network Operating System (NOS) based directories: Novell e-Directory, Microsoft
Active Directory, SUN NIS/NIS+
Purpose specific directories: definite per uno scopo specifico e non estensibili come l’
Internet Domain Name System (DNS)
General purpose, standard based directories: implementate per soddisfare le esigenze di
varie applicazioni e servizi (LDAP e X.500 directories)
Le directories sono dinamiche
Le directory offline sono relativamente statiche: l’elenco telefonico ad esempio viene rivisitato su
base annuale, le guide TV su base settimanale, …
Al contrario le online directories sono mantenute molto più aggiornate con criteri decisi dai relativi
amministratori. Spesso sono considerate come migliori le directories che possiedono
autoritativamente l’informazione più recente, in modo che le modifiche siano rese immediatamente
disponibili all’utenza.
Il vantaggio degli aggiornamenti delle directory online consente di introdurre applicazioni che non
trovano analogia nelle directories offline. Ad esempio una directory che contiene informazioni
aggiornate sui dipendenti di una azienda potrebbe essere consultata in tempo reale da lettori di
badge che autorizzino l’accesso ad edifici e stanze dell’azienda stessa; nel caso di trasferimenti le
informazioni aggiornate nella directory possono esse consultate per dirottare automaticamente
telefonate, fax, …
Un altro vantaggio delle directories online consiste nel distribuire e delegare le responsabilità di
aggiornamento/modifica delle informazioni: quanto più vicina è l’informazione alla sua sorgente
tanto più accurata e tempestiva sarà l’aggiornamento dell’informazione.
Le directories sono flessibili
Flessibilità dei contenuti
Al contrario delle directories offline quelle online sono estensibili senza dover essere ripianificate o
ridistribuite. L’aggiunta di nuovi tipi di informazioni infatti viene riflessa automaticamente ed
immediatamente dato che i client non posseggono una copia della directory stessa ma interrogano
direttamente quella online. Rispetto alle directories offline inoltre l’estensibilità dei contenuti ha
costi trascurabili (spazio su disco maggiore).
Flessibilità organizzativa
L’elenco telefonico tradizionale contiene nomi, numeri telefonici ed indirizzi organizzati in modo
da facilitare le ricerche per nome. Cercare un nome per indirizzo o numero di telefono è operazione
quasi impossibile. Emerge quindi che nelle directory di tipo offline l’organizzazione dei contenuti è
limitata sia a causa del supporto utilizzato (es. cartaceo) che dalle capacità dell’utilizzatore (senza
formazione adeguata).
Al contrario le directory online supportano simultaneamente molteplici tipi di organizzazione dei
dati. Ad esempio un elenco telefonico online potrebbe essere consultato e cercato per qualsiasi tipo
di campo o attributo. Le directory online inoltre consentono tipi avanzati di ricerca impossibili in
altri tipi di directory (ad esempio le ricerche di tipo “like”, substring, …)
Le directories possono essere sicure
Le directory offline sono spesso prive di alcun tipo di sicurezza. Un elenco telefonico cartaceo ad
esempio è pubblico e tutte le informazioni in esso contenute sono immediatamente disponibili. La
causa principale dell’insicurezza delle directories offline è il metodo con cui sono distribuite
(ovvero distribuzione su vasta scala a disposizione di tutti); non c’è modo inoltre di identificare chi
consulta la directory e di limitare le informazioni accessibili.
Le directories online sono in grado di risolvere questi problemi. Esse consentono di controllare
l’accesso alle informazioni identificando l’utilizzatore attraverso processi di autenticazione.
L’autenticazione affiancata dalle Access Control Lists (ACL), indirizzo IP del client, data/ora, …
determina il tipo di autorizzazione del client ad accedere a quali informazioni della directory.
Le directories possono essere personalizzate
Le guide TV sono generalmente differenti su base regionale/nazionale. Sarebbe bello proporre delle
guide che consentano delle “viste” personalizzate in base alle preferenze dell’utente finale,
preferenze che però non devono essere note a terzi. Le directories online consentono di soddisfare
entrambe i requisiti: tramite un processo di profilazione dell’utenza (protetta ai fini della privacy
con opportune ACL) vengono archiviate le personalizzazioni su base utente che consentiranno di
ottenere delle query che soddisfano il cliente finale. Allo stesso modo un negozio virtuale potrebbe
proporre al proprio cliente, in base alle sue preferenze, una lista di prodotti in promozione
totalmente personalizzata.
Directories e Database
Le differenze tra un database e una directory (general purpose) cadono nelle seguenti categorie:
Rapporto operazioni Read/Write
Estensibilità
Distribuzione
Replicazione
Performance
Standard supportati
Transazioni e “Join”
Rapporto operazioni R/W
Una delle caratteristiche principali di una directory è data dal fatto che le operazioni di lettura e
ricerca sono di gran lunga superiori a quelle di scrittura o modifica. Questo non sempre è vero per i
database. In database per la registrazione di auditing/logging le operazioni di lettura sono rare e
vengono fatte solo quando si verificano determinate condizioni (ad esempio per fornire dei report
mensili).
Generalmente una directory è letta 1000/10000 volte più che scritta o modificata. Tale rapporto è
giustificato dalla natura delle informazioni solitamente inserite in una directory: si pensi ad esempio
a quante volte cambia un numero di telefono rispetto al numero di telefonate ricevute, o quante sono
le mail ricevute rispetto ad un cambio di indirizzo.
Questi parametri sono fondamentali per il design della directory. La massima attenzione andrà
all’ottimizzazione per ottenere il massimo delle performance nelle operazioni di lettura, mentre la
modalità delle operazioni di scrittura dovrà essere pianificata tenendo conto delle implicazioni sulle
procedure di replicazione.
Estensibilità
Generalmente le directories sono estensibili con maggior facilità rispetto ai database. Con il termine
directory schema ci si riferisce al tipo di informazioni che possono essere archiviate in una
directory e alle regole che queste devono osservare.
Le directory non sono mai limitate ad uno schema fisso, ma esso può essere esteso per soddisfare le
esigenze di utenti e applicazioni. Ogni directory parte da un insieme predefinito di tipi di
informazioni che possono essere archiviate, ma ogni realtà spesso sente l’esigenza di definire dei
nuovi attributi.
AL contrario raramente un database consente di inserire nuovi tipi di dati con nuova semantica.
Distribuzione
Per distribuzione dei dati s’intende porre le informazioni in server diversi connessi in rete.
Raramente accade di splittare database su più server, sia perché il livello di distribuzione è poco
scalabile (qualche sito), sia perché le operazioni di query che interessano più siti sono poco
performanti. Al contrario il concetto di distribuzione è fondamentale per la pianificazione delle
directories. I principali motivi di distribuzione sono di autority/amministrazione oppure di carattere
logistico (per uffici, sedi geografiche, …).
Oltre a questi motivi spesso una directory viene distribuita su vari server per motivi di performance
(carico delle query distribuite su vari server) e per motivi di ridondanza delle informazioni (la
rottura di un server non comporta la caduta del servizio, o solo di parte di esso).
Replicazione
La replicazione è il processo con cui si mantengono copie multiple dei dati in punti fisicamente
differenti. I motivi per cui viene replicata una directory ( o un database) sono per migliorare
l’affidabilità, la disponibilità, la prossimità (dei dati rispetto ai client) e le performance (maggiore
throughput, scalabilità orizzontale).
Anche i database supportano la replicazione, tipicamente per un numero ridotto di repliche; al
contrario le directory supportano varie repliche. Nel caso dei database il problema principale è la
consistenza dei dati tra le repliche, problema che non consente una grossa scalabilità (limitato
numero di hops) né l’utilizzo di link deboli o intermittenti.
Performance
La performance dei database viene generalmente misurata in numero di transazioni per secondo. Lo
stesso avviene per le directory generalmente misurata in numero di query per secondo. Le
transazioni di un database sono di solito operazioni più complesse di una query, inoltre le
performance di scrittura (update) sono meno critiche per una directory rispetto ad un database.
Mentre i database vengono pianificati a servizio di un numero limitato di applicazioni le directory
stanno diventando il centro nervoso delle infrastrutture informatiche utilizzato da un numero sempre
crescente di applicazioni sia a livello aziendale che a livello molto più esteso (attraverso Internet).
Le performance di una directory quindi devono essere capaci di soddisfare il tipo ed il numero di
query a cui dovrà rispondere.
Standard ed interoperabilità
Nel mondo dei database ci sono molti pseudostandard, a partire dal modello relazionale Structured
Query Language (SQL). Questi pseudostandard consentono di migrare facilmente da un sistema
database ad un altro, i concetti appresi su un database consento spesso di apprendere con facilità
quelli di altri vendor, ma questi standard non forniscono una vera interoperabilità. Al contrario del
mondo delle directories, dato che le applicazioni di qualsiasi vendor devono essere in grado di
accedere all informazioni, il problema dell’interoperabilità attraverso degli standard è critico.
Il Lightweight Directory Access Protocol (LDAP) fornisce i modelli e i protocolli utilizzati dalle
directories attuali. Grazie ad LDAP vengono disacoppiati le directories dai client.
Transazioni e Join
Le directory consentono transazioni relativamente facili, singole operazioni su singole entry; al
contrario i database consentono complesse transazioni che possono interessare svariati record
compiendo serie di operazioni. I database supportano inoltre il rollback delle transazioni ai fini di
ripristinare lo stato originale dei dati nel caso in cui si verifichino degli errori nella serie di
operazioni effettuate dalla transazione stessa. Solo alcuni software directory service supportano, per
mezzo di estensioni proprietarie di LDAP, il concetto di transazione database-style.
I database relazionali supportano inoltre i join, tipi di query che prelevano dati da sorgenti multiple
in una risultante basandosi su chiavi comuni. La maggior parte delle directory non supporta affatto
il join.
Applicazioni delle directories
Ricerca di informazioni
Come è stato già menzionato una delle applicazioni più diffuse delle directories sono le ricerche di
informazioni. L’esempio classico è costituito dai phone book; molto diffusi anche su internet
(Switchboard, Yahoo People Search, Bigfoot, …) hanno molte analogie con le rubriche cartacee ma
con importanti differenze nelle modalità di ricerca, nella flessibilità della navigazione delle
informazioni.
Gestione centralizzata di oggetti e configurazioni
In ambienti distribuiti le directories forniscono una gestione centralizzata di oggetti. La categoria
più frequente di questi oggetti è costituita da utenti e gruppi, forse il servizio di gestione più
importante fornito da una directory.
Sino a qualche anno fa ogni applicazione ed ogni servizio avevano la propria directory di gestione
utenti. La situazione può essere conveniente sino a quando è sentita l’esigenza di utilizzare una sola
di queste applicazioni, diventando ingestibile al crescere delle directories.
La scomodità di dover gestire molteplici directories non è solamente più costosa dal punto
amministrativo ma anche scomoda per l’utente finale che si vede costretto a ricordare password
diverse per servizi diversi (generalmente directory services proprietari non sono facilmente
sincronizzabili). Al contrario, nel caso di una directory centralizzata, gli amministratori modificano
le informazioni (es. creazione utenti) in un unico punto ed ogni applicazione nuova o esistente
utilizzerà la directory stessa al posto di quelle proprietarie.
Un'altra importante area in cui la directory risolve problemi di gestione è l’archiviazione delle
configurazioni delle applicazioni. Storicamente la configurazione delle applicazioni viene archiviata
localmente in file o altri componenti specifici dei sistemi operativi (ad esempio il registro di sistema
per Microsoft Windows). Se questa soluzione è vantaggiosa e comoda per alcuni applicativi non lo
è affatto per le network-applications, specie se implementate su vasta scala.
Si consideri ad esempio i server Web. Una grande organizzazione potrebbe avere centinaia di server
web, tutti con un set di configurazioni comuni. In condizioni di gestione non centralizzata ogni
modifica comporta la revisione della configurazione di centinaia di server diversi. Archiviando la
configurazione in una directory centralizzata invece si ottiene una configurazione unica, condivisa e
accessibile da rete. Lo stesso vale per la profilazione degli utenti: informazioni come la home
directory, i parametri di configurazione degli applicativi, … per forza di cose devono essere
archiviate in un deposito centralizzato, specie se gli utenti sono roaming (cambiano spesso
postazione di lavoro).
Sicurezza
Un’altra applicazione interessante delle directories è relativa alla sicurezza, in particolare come
supporto ai sistemi a chiave pubblica (PKI). La directory può essere infatti utilizzata sia per
l’archiviazione dei certificati digitali che per la gestione dei ciclo di vita dei certificati (pubblicando
ad esempio le CRL ovvero le liste di revoca dei certificati). Nelle applicazioni che utilizzano i
certificati (ai fini dell’autenticazione, le operazioni di firma e crittografia, …) è fondamentale un
metodo di localizzazione dei certificati degli utenti con cui si interagisce. Ai fini di queste
applicazioni il certificato digitale diventa semplicemente un attributo aggiuntivo dell’oggetto utente
all’interno della directory. In questo modo il certificato può essere reperito allo stesso modo di
informazioni come il numero di telefono o l’indirizzo email.
Storia e origini di LDAP
X.500
Non è possibile discutere delle origini di LDAP senza parlare di X.500, standard nato dagli sforzi di
CCITT e ISO nel 1988. Esso possedeva numerose qualità:
era stato il primo vero general purpose directory system, estensibile ai fini di servire il
maggior numero di applicazioni
disponeva di un ricco insieme di operazioni di ricerca
era stato sviluppato in modo da favorire implementazioni notevolmente distribuite
era open standard non controllato da alcun vendor né legato ad alcun sistema operativo,
applicativo o teconologia di networking
In pratica X.500 non ebbe il successo previsto. Le prime implementazioni infatti ebbero problemi di
scalabilità, la complessità degli standard e della sua implementazione resero difficile
l’interoperabilità di directory X.500 diverse, l’insuccesso del modello di rete OSI su cui erano
basate le prime implementazioni (adattate in seguito a TCP/IP) assieme alla difficoltà della suite dei
suoi protocolli di accesso (DAP, DSP, DOP, DISP) spinsero i membri del OSI-DS Working Group
assieme all’IETF allo sviluppo di un protocollo di accesso più semplice LighterDAP ovvero LDAP.
Le prime specifiche di LDAP vennero pubblicate nella RFC 1487 del luglio 1993. La prima
implementazione diffusa ampiamente fu LDAPv2 pubblicata nella RFC 1777.
Gli sviluppatori LDAP semplificarono il pesante X.500 DAP Protocol nelle seguenti aree:
Funzionalità: semplificazione del protocollo rispetto a DAP con l’eliminazione di operazioni
ridondanti o scarsamente usate del protocollo di origine
Rappresentazione dei dati: la maggior parte degli elementi viene rappresentata come
semplici stringhe di testo (wrappate all’interno di messaggi con codifica binaria per una maggiore
efficienza)
Codifica: viene utilizzato un sottoinsieme delle regole di codifica di X.500, semplificandone
notevolmente l’implementazione
Trasporto: LDAP “gira” su TCP che rispetto al poco diffuso OSI ha una implementazione
notevolmente semplificata e performante
Nel 1997 LDAP è entrato nella fase più matura della sua evoluzione con il rilascio della versione 3
(LDAPv3) che migliora LDAPv2 nelle seguenti aree:
Internazionalizzazione: utilizzo del character set UTF-8, codifica dell’universale Unicode
Referrals: meccanismo standard per fornire puntatori ad altri server che consente di
implementare LDAP in una modalità bottom-up sullo stile dei server WWW
Security: il supporto per SASL e TLS viene aggiunto per migliorare il livelli di sicurezza
Estensibilità: LDAPv3 può essere esteso per supportare nuove operazioni o controlli
In questi anni tutti i maggiori vendor di sistemi operativi e servizi di rete anno adottato lo standard
LDAPv3 abbandonando definitivamente le directories proprietarie: Netscape Directory Server, Sun
ONE Directory Server, Microsoft Active Directory, IBM Directory Server, Novell eDirectory,
Oracle Internet Directory, OpenLDAP slapd server.
Introduzione a LDAP
Con il termine LDAP ci si riferisce alle seguenti cose:
Lightweight Directory Access Protocol, un protocollo standard, estensibile, utilizzato per
accedere a directory services
Un set di modelli che forniscono una quida all’uso delle directory: information model che
descrive cosa si può inserire in una directory; naming model che descrive come organizzare
i dati nella directory; functional model che cosa si può fare con i dati della directory e
security model che descrive come i dati possono essere protetti da accessi non autorizzati.
LDAP Data Interchange Format (LDIF), un formato (text) standard per lo scambio di dati
tra directory
LDAP server software, commerciale o open-source
LDAP application programming interface (APIs) utilizzate per lo sviluppi di applicazioni
client LDAP
Il protocollo LDAP
Il protocollo LDAP è message-oriented. Il client inoltra un messaggio contenente una richiesta al
server e questi processa la richiesta rispedendo il risultato al client con una serie di uno o più
messaggi.
Ad esempio, quando il client LDAP ricerca la directory per una specifica entry, spedisce un
messaggio di richiesta al server che contiene un message ID univoco generato dal client. Il server
preleva le informazioni richieste dal suo DB e la rispedisce al client con un ulteriore messaggio,
seguito da un secondo messaggio detto result-code. Tutte le risposte dal server al client sono
identificate dal message ID fornito dalla richiesta del client.
Se la richiesta del client corrisponde a varie entry queste vengono spedite ciascuna in un messaggio
distinto contenente il DN (distinguished name) dell’oggetto trovato.
Il protocollo LDAP consente al client di inoltrare richieste multiple in una sola volta. In questo caso
il client genera un message ID univoco per ciascuna richiesta. Le risposte del server contengono
anche il message ID che viene utilizzato dal client per riordinare le risposte (le operazioni di sort dei
risultati non sono di competenza del protocollo LDAP ma della LDAP-SDK).
LDAP protocol operations
Le operazioni supportate dal protocollo LDAP possono essere riassunte in 3 categorie:
1
2
3
operazioni di interrogazione: search, compare
operazioni di update: add, dolete, modify, modify DN (=rename)
operazioni di autenticazione e controllo: bind, unbind, abandon
L’operazione di binding comprende il nome della directory entry con cui il client intende
autenticarsi con le credenziali (password, certificati digitali, …)
Combinando alcune di queste semplici operazioni LDAP, eventuali client directory enabled
possono effettuare operazioni di notevole utilità per gli utenti. Ad esempio un client di posta
elettronica potrebbe effettuare il lookup degli indirizzi di posta ed eventualmente dei certificati
digitali in una directory.
Modelli operativi di LDAP
LDAP Information Model:
definisce i tipi di dati e le unità di base dell’informazione che può essere archiviata in una directory.
Le unità di base dell’informazione sono gli oggetti (utenti, stampanti, computers, …) i quali sono
composti da attributi che possono avere uno o più valori. Lo schema regola l’appartenenza degli
attributi agli oggetti (se devono o possono appartenere ad un oggetto).
LDAP naming Model:
definisce come i dati vengono organizzati nella directory e come ci si riferisce ad essi. La
flessibilità offerta da LDAP consente di organizzare le entry (oggetti) in base alle proprie esigenze (
per tipologie di oggetti piuttosto che per posizione geografica degli stessi, …). Il modello specifica
che gli oggetti devono essere organizzati sotto forma di albero rovesciato, un concetto paragonabile
alla struttura di un file system Unix.
Il naming model è importante e necessario ai fini di fornire un nome univoco a ciascuna entry della
directory in modo che non nascano ambiguità nel riferirsi ad un determinato oggetto. In LDAP il
riferimento ad una entry viene chiamato Distinguished Name (DN).
cn=Mario Rossi,ou=people,dc=example,dc=com
Leggendo un DN da sinistra a destra si segue il percorso dall’oggetto alla radice della directory. La
parte più a sinistra del DN prende il nome di Relative Distinguished Name. Oggetti che risiedono al
di sotto del medesimo contenitore (stesso parent) devono avere RDN diversi.
LDAP Functional Model
Descrive le operazioni che possono essere effettuate sulla directory per mezzo del protocollo
LDAP. Le operazioni si dividono in tre gruppi: operazioni di interrogazione (ricerche nella
directory e reperimento di informazioni); operazioni di update (aggiunta, modifica e cancellazioni
di oggetti/entry); operazioni di autenticazione e controllo (processo di identificazione del client e
controllo della sessione).
Oltre a questi gruppi di operazioni la versione 3 del protocollo LDAP definisce un framework per
l’aggiunta di nuovi tipi di operazioni al protocollo (LDAP extended operations).
LDAP Security Model
IL protocollo LDAP è orientato alla connessione, il client apre una connessione verso il server
LDAP ed effettua varie operazioni nella stessa connessione. Una delle operazioni è quella
dell’autenticazione del client, in base alla quale il server accorda determinati privilegi. Il processo di
autenticazione verso un servizio di directory viene chiamato binding. Il processo di autenticazione
semplice consiste nel fornire un DN con la relativa password. Il server localizza la entry nella
directory corrispondente al DN fornito dal client e verifica se la password corrisponde a quella
archiviata nell’attributo userPassword.
Quando un client non si autentica viene effettuato il binding anonimo; generalmente il set di
privilegi in questo caso è minimo oppure talmente restrittivo da impedire qualsiasi operazione di
lettura o ricerca nella directory.
LDAPv2 supporta solamente l’autenticazione semplice in cui DN e password sono trasmesse in
chiaro dal client al server. LDAPv3 supporta invece vari metodi di autenticazione grazie
all’adozione del frameword SASL. SASL fornisce un metodo standard per il supporto di vari
protocolli di autenticazione.
LDAP Working Group ha definito dei metodi di autenticazione minimi che devono essere
supportati dai server LDAPv3. Nel documento (RFC 2829) i server LDAP vengono suddivisi in 3
gruppi distinti ciascuno con diversi requisiti:
1
directory servers pubblici (read only) possono accettare l’autenticazione anonima (senza
password)
2
server che supportano l’autenticazione basata su password devono supportare il
meccanismo SASL DIGEST-MD5 (RFC 2831)
3
server che richiedono sessioni cifrate e autenticazione devono implementare l’estensione
StartTLS (RFC 2830). Essa consente al client LDAP di richiedere la cifratura di tutto il
flusso di dati e di implementare una mutua autenticazione utilizzando certificati digitali a
chiave pubblica.
TLS consente al client di iniziare una connessione “in chiaro” e di negoziare la crittografia e
l’autenticazione dopo che la sessione è stata stabilita. Ciò consente al server LDAP che supporta
TLS di avere client sicuri e non sicuri sulla medesima porta (389 è la porta di default per le
connessioni LDAP).
LDIF
LDAP Data Interchange Format è un formato standard (text based) di descrizione delle directory
entry come definito dalla RFC 2849. Esso consente di esportare i dati (entry e attributi) da una
directory all’altra anche se i server utilizzano formati DB diversi. Esistono due tipi principali di file
LDIF. Il primo descrive un set di directory entry, l’altro una serie di update che descrivono le
modifiche che devono essere applicate alle directory entry.
LDAP Server Software
Un server LDAP è un programma che implementa il protocollo LDAP e gestisce il database che
ospita i dati della directory. La maggiorn parte dei server LDAP include una suite di applicativi che
aiutano nella gestione della directory.
LDAP API
Ai fini di facilitare lo sviluppo di applicazioni directory enabled sono state definite della
API standard per l’accesso e l’update delle directory. Esistono varie implementazioni della LDAP C
API (in fase di draft per LDAPv3) accanto alle quali si affiancano la Java API di Netscape, il
modulo Net::LDAP o PerLDAP, JNDI (Java Naming and Directory Interface) di JavaSoft e ADSI
di Microsoft.
Estensioni LDAPv3
Il processo di standardizzazione IETF richiede molto tempo, motivo per cui quando viene rilasciato
uno standard (LDAPv3) è preferibile che le successive integrazioni vengano implementate come
“estensioni” e cono come nuovo standard (es. LDAPv4).
Il protocollo LDAP ha tre meccanismi che estendono le funzionalità “core” del protocollo:
contols
extended operations
Simple Authentication and Security Layer (SASL)
LDAP controls
Gli LDAP controls sono informazioni extra che vengono allegate ad una operazione LDAP esistente
in modo da modificarla. Ad esempio il controllo Server-Side-Sorting consente di modificare una
query LDAP standard in modo che l’output venga ordinato dal server prima di essere spedito al
client.
Ogni controllo contiene un object identifier (OID) che identifica univocamente il tipo di controllo
ed un flag che indica la criticità del controllo stesso. Se un client imposta il flag isCritical il
server deve considerare il controllo nell’eseguire l’operazione; in caso contrario il server è libero di
ignorare il controllo se non è in grado di processarlo.
Controlli multipli possono essere inseriti in una singola operazione.
LDAP extended operations
A volte c’è la necessità di implementare delle funzionalità completamente nuove che non vengono
supportare dalle operazioni LDAP standard. In questo caso vengono definite delle estensioni del
protocollo. Ogni LPDA extended operation viene identificata univocamente da un OID. E’ possibile
utilizzare LDAP controls anche con le extended operations oltre che con le operazioni standard.
SALS Authentication Mechanisms
Uno dei grossi limiti di LDAPv2 è il fatto di non supportare protocolli do autenticazione forte al di
fuori di Kerberos v4 (scarsamente diffuso). L’unico metodo utilizzabile è quello di effettuare un
binding su distinguished name (DN) con password in chiaro.
In LDAPv3 invece che implementare un singolo metodo di autenticazione forte (LDAPv3) gli
sviluppatori hanno preferito incorporare un framework di autenticazione chiamato Simple
Authentication and Security Layer (SASL) che consente la coesistenza di più protocolli di
autenticazione. SASL consente quindi di aggiungere autenticazione e sicurezza (opzionale) ai
protocolli orientati alla connessione (come LPAP). Le specifiche del framework SASL sono
contenute nella RFC 2222.
Un SALS Mechanism descrive il flusso di informazioni necessarie a supportare un determinato
metodo di autenticazione. I meccanismi SASL sono definiti per vari protocolli di autenticazione
(Keberos v5, DIGEST-MD5, EXTERNAL…). La RFC 2892 descrive come SASL viene utilizzato
all’interno di LDAPv3. DIGEST-MD5 è un metodo di autenticazione che non trasmette password in
chiaro sulla rete. EXTERNAL è un meccanismo SASL che consente a LDAP di riutilizzare
credenziali già stabilite da un protocollo di livello più basso (comne SSL o TSL). Tutti i server
LDAPv3-compliant che supportano autenticazione basata su password devono supportare il
meccanismo DIGEST-MD5.
Root DSE
La root DSE è una speciale directory entry che contiene informazioni sul server, tra le quali la lista
di tutti i controlli LDAP, delle extended operations e dei meccanismi SASL supportati.
I valori degli attributi supportedExtension, supportedControl e supportedSASMechanisms indicano
le estensioni ed i meccanismi supportati dal server.
Ciclo di vita di un directory service
Il ciclo di vita di una directory può essere spezzato in tre fasi: design, deployment, maintenance.
Fase di Design:
raccolta di informazioni sull’ambiente di introduzione del servizio di
directory, sorgenti di dati, utenti e applicazioni directory-enabled
Directory needs. Il servizio dovrà coprire le esigenze degli applicativi che si
intendono sviluppare e degli utenti che gli utilizzeranno
Data. Qualsiasi servizio di directory avrà bisogno di dati. Ci sono buone probabilità
che esistano già notevoli fonti di dati utili a popolare il servizio. E’ necessaria una
operazione di catalogazione delle sorgenti di dati, di identificazione dei proprietari
delle informazioni stesse.
Schema. La directory nasce per supportare applicazioni directory-enabled. Le
applicazioni hanno dei requisiti che riguardano i dati contenuti nella directory, il loro
formato e il modo in cui vanno interpretati. Tali caratteristiche vengono definite
nello schema della directory
Namespace. E’ il metodo con cui si organizzano e si definiscono i riferimenti ai dati
di una directory.
Topology. Determina il numero di server, il modo in cui i dati della directory
vengono suddivisi sui server e la locazione fisica dei server stessi.
Replication. E’ il processo con cui i dati della directory vengono mantenuti
consistenti sui vari server per garantire un servizio più affidabile e performante
(bilanciamento delle query ad esempio)
Security. Pianificazione di protezione dei dati contenuti nella directory
Fase di Deployment: determinazione del vendor del servizio di directory, implementazione di una
configurazione di test per prove di stress, scalabilità, performance, affidabilità, ridondanza, fault
tolerance del sistema. La fase prevede di sottoporre il sistema ad un gruppo limitato di utenti ai fini
di ricevere un feedback. Al termine della fase il servizio di directory viene messo in produzione.
Choosing directory software. La scelta del software è importante e complessa. Il
software deve essere in grado di soddisfare le esigenze stabilite nella fase di design
compatibilmente con i costi. Considerare tutti i fattori sia tecnici e pratici. Non
optare per soluzioni per cui non c’è stata una esperienza diretta (hands on)
Piloting. Richiede il set-up (generalmente in scala ridotta) della directory frutto della
fase di design ai fini di sottoporla al feedback di un gruppo ristretto di utenti. Il
piloting consente di valutare la fattibilità delle decisioni prese in merito allo schema,
namespace, topology e replication oltre a valutarne la compatibilità con le
applicazioni. Durante la fase di piloting vengono testate performance e scalabilità
della directory per meglio comprendere come il servizio potrebbe assorbire eventuali
esigenze future.
Analyzing costs. E’ fondamentale osservare i costi del servizio da tutti i punti di
vista: vanno infatti presi in considerazione non solo i costi di implementazione, ma
anche quelli di manutenzione, …
Obtaining user feedback. Gli utenti sono coloro per cui viene fatto tutto questo
lavoro di pianificazione ed implementazione: il loro feedback quindi è fondamentale
per la riuscita dell’intero progetto.
Moving to production. Durante la fase di deployment è necessario pianificare lo
spostamento del servizio di directory dallo stato di pilot a quello di produzione. Il
processo deve essere quanto più possibile trasparente ed incrementale.
Maintenance: la fase di manutenzione è quella che si protrae più a lungo e spesso a questo
importante aspetto viene data l’attenzione minore durante la fase di design. Al contrario la
manutenzione dovrebbe essere presa seriamente in considerazione durante la fase di design in
modod da minimizzarne i costi successivi.
Data backups and disaster recovery. Un importante aspetto per mantenere un servizio
affidabile è quello di effettuare backup regolari dei dati della directory. E’inoltre di
vitale importanza la verifica dei backup per essere sicuri che i dati possano essere
recuperati nel caso di un disastro. Deve essere inoltre previsto un piano di recovery
dell’intera directory.
Data maintenance. Il compito più importante di un servizio di directory è quello di
fornire informazioni aggiornate, per cui devono essere messe a punto delle procedure
che mantengano quanto più possibile la directory aggiornata (da fonti di dati esterne)
Monitoring. Una directory deve essere performante, per cui possono essere
necessarie delle operazioni di tuning.
Troubleshooting. Anche le directory pianificate perfettamente possono incorrere in
qualche problema. Il successo di un servizio di directory è strettamente legato ad una
buona operazione di troubleshooting
Changing requirements. Per la loro natura i servizi di directory devono adattarsi
anche ad esigenze future. Ogni volta che si rende necessaria una estensione/modifica
(ad esempio l’introduzione di una nuova applicazione directory enabled) è necessario
introdurre un mini ciclo di design rivisitanto dati, schema, namespacem replication e
security della directory.
Design: directory needs
Prima di iniziare a lavorare sull’implementazione di un servizio di directory è bene capire il motivo
per cui sentiamo l’esigenza di questo servizio; tali esigenze saranno il frutto di una completo
processo di analisi e dovranno essere ben presenti durante tutta la fase di pianificazione.
Analisi dell’environment
Il primo passo per una corretto lavoro di pianificazione consiste nel conoscere e capire l’ambiente
in cui questo dovrà operare. I processo di esplorazione deve riguardare le seguenti aree:
Unità organizzative e distribuzione geografica: conoscere a fondo le l’organizzazione
aziendale e la distribuzione geografica delle stesse influisce in maniera determinante la
pianificazione del servizio specie nel numero dei server, sulle politiche delle deleghe della
directory, sulle modalità di pianificazione della manutenzione dei sistemi (specie per realtà
worldwide), …
Computers: creare inventari sui tipi di computer presenti, elencandone i ruoli, le necessità
di upgrade, … La varietà dei sistemi che devono accedere al servizio di directory può
determinare la scelta del directory server
La rete: si deve ottenere la mappa della rete o della porzione di rete che è interessata
dall’implementazione del servizio. Ogni segmento di rete deve essere etichettato con il tipo
di link, ampiezza di banda, affidabilità e costo del link. Il servizio di directory dipende
dalla rete per lo scambio di dati con gli applicativi oltre che tra i directory server stessi, per
cui le sue caratteristiche influenzano pesantemente sul numero di server e sulla locazione
degli stessi.
Software applicativo: buona parte del processo di design del servizio di directory viene
pilotata dalle necessità degli applicativi che si intendono far diventare directory-enabled
Design:data
Il servizio di directory è un database specializzato per cui una delle considerazioni più importanti
della fase di design riguarda i dati ovvero la tipologia delle informazioni che verranno archiviate
nella directory.
Per dato si intende l’intera collezione di informazione archiviata nella directory.
Per data element s’intende una porzione di dato mentre per data source o repository il sistema che
archivia una collezione di data elements. Nella terminologia LDAP i data element corrispondono ai
tipi di attributi (ad esempio il cognome di una persona, il tipo di processore di un elaboratore, …)
mentre il loro valore attribute value.
Pur vivendo nell’era dell’informazione raramente essa è disponibile nel momento e nel modo
aspettato, a volte per eccesso di informazione (risulta difficile trovare quello che stiamo cercando),
altre volte per mancanza di informazione (ciò che cerchiamo non è disponibile), altre volte ancora
per una errata formattazione dei dati, obsolescenza, …
Le linee guida adottate per la definizione dei tipi di dati che verranno archiviati del servizio di
directory devono essere collezionate e descritte in un documento che deve coprire i seguenti punti:
i dati che saranno (es. informazioni condivise da almeno una applicazione) e non saranno
archiviati (es. dati con valori di dimensione > 10k) nella directory
i modi di accesso ai dati (specie se si pianifica l’archiviazione di dati sensibili) ed i tipi di
autenticazione e cifratura richiesti
la modifica dei dati da parte di utenti o applicazioni ed i criteri per poter effettuare le
modifiche (autenticazione, …)
considerazioni di carattere legale per definire se ci sono tipologie di dati che non posso
essere archiviati o che non possono essere visualizzate da alcune categorie di utenti
definizione dei dati archiviati della directory e delle rispettive sorgenti esterne oltre che dei
flussi e delle priorità di una sorgente rispetto ad un’altra
definizione di un semplice processo per la gestione delle eccezioni non comprese nel
documento
Dopo aver definito la lista dei dati da includere nella directory vanno identificate le sorgenti da cui
ottenere i valori dei data elements e la gestione delle relazioni tra le varie sorgenti.
Sorgenti comuni di dati sono:
altri servizi di directory (Novell Directory, Microsoft Active Directory, NIS, …)
database
files o fogli di calcolo
applicazioni di collaborazione in possesso di database o directory built-in (email systems,
calendar systems, …)
utenti finali (spesso gli utenti costituiscono la migliore fonte per i dati che li riguardano
personalmente, specialmente per quando riguarda i contatti come il telefono, indirizzo, …)
E’ importante pensare a come i dati contenuti nella directory si relazionano con i dati archiviati
nelle sorgenti presenti nell’organizzazione. Spesso le aziende soffrono problemi di ridondanza ove i
dati sono archiviati in database multipli e scoordinati. Ai fini di pianificare con successo il servizio
di directory ove sono presenti varie sorgenti contenenti il medesimo tipo di dati si possono seguire
le seguenti tecniche:
replicazione: in presenza di servizi di directory provenienti dallo stesso vendor o che
utilizzano lo stesso protocollo di replicazione (come l’emergente standard LDUP IETF)
vanno abilitate le funzionalità per mantenere consistenti i valori dei data elements tra i vari
server (ottenendo ridondanza e bilanciamento del carico)
sincronizzazione: è il processo attraverso cui le modifiche apportate su un sistema vengono
propagate sugli altri. La sincronizzazione viene effettuata frequentemente ma la
consistenza dei dati non è garantita come dal processo di replicazione. La sincronizzazione
può essere effettuata in una o entrambe le direzioni e tra due o più sorgenti di dati. I
prodotti di sincronizzazione sono disponibili da vari produttori di software (es. Microsoft
Metadirectory Services) e generalmente consentono di aggiungere dei task al puro
processo di allineamento dei dati (ad esempio se una persona viene aggiunta al database
delle risorse umane non solo viene creata una utenza nel servizio di directory ma un trigger
scatena eventi esterni alla directory come la creazione di una casella postale, di una home
directory o concede l’accesso a determinate risorse di rete)
batch updates: procedure complesse che non vengono eseguite molto spesso (ad esempio
su base mensile) e coinvolgono il merge di dati provenienti da fonti di dati radicalmente
diverse
Design: schema
Lo schema è un insieme di regole che determina il tipo di dati che può essere archiviato in un
database o servizio di directory. Lo schema è importante perché può aiutare a mantenere l’integrità
e la qualità dei dati archiviati. Lo schema aiuta inoltre a ridurre la duplicazione dei dati e fornisce
una via ben documentata affinchè le applicazioni directory enabled possano accedere e modificare
le collezioni di oggetti presenti nella directory.
Ogni volta che viene richiesta al servizio di directory la modifica o l’inserimento di una entry esso
controlla il contenuto attraverso le regole dello schema. Ogni volta che vengono comparati i valori
di un attributo il servizio consulta lo schema per determinare l’algoritmo di comparazione da
utilizzare.
Lo schema può essere anche utilizzato per imporre dei limiti sulla dimensione, intervalli (range) e
formato dei dati archiviati della directory. Ad esempio nel rispetto degli standard l’indirizzo email
deve contenere un set specifico di caratteri e deve essere conforme ad un determinato formato
(indirizzo@dominio).
Elementi di una schema LDAP
Nei servizi di directory basati su LDAP lo schema consiste in tipi di attributi, sintassi degli attributi,
regole di comparazione degli attributi e classi di oggetti.
Attributi
Le directory entry contengono una collezione di tipi di attributi con relativi valori. I tipi di attributi
(da ora semplicemente attributi) contengono elementi di dati specifici come il nome di una persona,
il numero di telefono d’ufficio o il numero di copie/minuto di una stampante. In LDAP la
definizione di un attributo comprendele seguenti informazioni:
nome che identifica univocamente l’attributo
object identifier (OID) che identifica univocamente l’attributo
descrizione testuale
sintassi per l’attributo
set di regole di confronto che agiscono nelle operazioni di confronto e ricerca
indicatore di utilizzo (per applicazioni o per il solo servizio di directory
indicazione se l’attributo è single o multi valore
restrizioni sul range o le dimensioni dei valori che possono essere archiviati nell’attributo
Sintassi degli attributi
Ad ogni attributo viene associata una sintassi che specifica esattamente come i dati vengono
rappresentati.Come ogni attributo viene identificato da un OID altrettanto accade per le sintassi.
La maggior parte degli attributi di una directory sono del tipo DirectoryString. Altre sintassi
standard sono Binary, Boolean, CountryString, Integer, OctetString, …
Regole
Client e server LDAP devono utilizzare delle speciali regole per comparare i valori di attributi
differenti. Ad esempio nella comparazione di nomi di file per un filesystem unix va tenuto conto
che essi sono case sensitive mentre per un file system windows i nomi dei file non sono case
sensitive. Tra le matching rules standard ricordiamo booleanMatch, caseIgnoreMatch,
caseExactMatch, integerMatch, telephoneNumberMatch, …
Classi di oggetti
In LDAP le classi di oggetti vengono utilizzate per raggruppare informazioni in relazione tra loro.
Tipicamente una classe corrisponde ad oggetti della vita reale ovvero persona, stampante, apparato
di rete, …. Ogni directory entry appartiene ad una o più classi di oggetti. I nomi delle classi di
oggetti a cui una entry appartiene vengono sempre listate come un valore per l’attributo speciale (di
tipo multi-valued) chiamato objectclass. Il set di classi di oggetti associati ad un attributo segue
le seguenti regole:
determina quali tipi di attributi devono essere contenuti in una classe (ad esempio in una
classe di tipo person il nome della persona è obbligatorio)
determina quali tipi di attributo possono essere contenuti in una classe (in una classe
person il numero di telefono è facoltativo)
fornisce una via conveniente per i client della directory di prelevare informazioni relative
ad un sottoinsieme di entry durante le operazioni di ricerca (ad esempio una ricerca per
objectclass=person)
In LDAP la definizione di object class include le seguenti informazioni:
nome che identifica univocamente la classe
descrizione testuale
OID che identifica univocamente la classe
set di tipi di attributi obbligatori
set di attributi opzionali
il tipo di classe (structural, auxiliary e abstract)
Il “tipo” di una classe indica come la classe stessa viene utilizzata. Le structural classes descrivono
solamente gli aspetti base di un oggetto: ad esempio possono venir utilizzate per porre delle
restrizioni su dove una entry può venire archiviata lde DIT (directory information tree). La maggior
parte delle classi sono di questo tipo. Le auxiliary classes non pongono restrizioni su dove una entry
può essere archiviata e vengono utilizzate per aggiungere un set di attributi ad una entry che
appartiene già ad una structural class.
Ereditarietà delle classi
Una classe può essere derivata da un’altra classe; in tal caso essa eredita alcune caratteristiche della
classe da cui deriva. In questo caso si parla di subclassing oppure di object class ineritance.
Ad esempio la classe inetOrgPerson definita nella maggior parte dei servizi di directory estende
la classe person ed include ulteriori attributi per poter archiviare elementi comunemente utilizzati
in Internet o nella maggior parte delle organizzazioni. La classe di livelli inferiore deve avere tutti
gli attributi obbligatori nelle classi superiori e può utilizzare tutti i campi opzionali previsti da
queste.
In generale la classe da cui un’altra classe eredita alcune delle sue caratteristiche viene detta
superclasse o classe superiore. Tutte le classi derivano da una classe speciale di tipo abstract detta
top. La definizione della classe top consiste in un singolo attributo obbligatorio chiamato
objectclass ai fini di assicurare che tutte le entry della directory conterranno almeno un valore
per questo attributo.
Schema predefiniti e definizione di nuovi elementi
Le strutture degli schema vengono fornite da produttori di applicativi, documentazione standard sui
servizi di directory (es. IETF) e dai vari produttori di servizi di directory. In fase di installazione di
un servizio di directory vanno selezionati gli schema predefiniti in grado di soddisfare la
compatibilità con il maggior numero di applicazioni e servizi directory enabled. Qualora gli schema
predefiniti non coprano tutte le esigenze riscontrate in fase di pianificazione si renderà necessaria la
definizione di classi ed attributi personalizzati.
La creazione di nuove classi ed attributi comporta la definizione di una nomenclatura.
Generalmente una buona strategia consiste nel prefiggere il nome dei nuovi elementi dello schema
con una stringa che ricorda il nome dell’ente/organizzazione. In tal modo si limita la possibilità di
collisione con le altre definizioni esistenti.
Accanto alle problematiche di nomenclatura dei nuovi elementi va ricordato che ad ognuno di essi
va assegnato un identificativo univoco OID. Gli OID vengono generalmente rilasciati dall’ente
IANA. Essi sono del tipo 1.3.6.1.4.1.250. L’ente IANA rilascia l’identificativo della radice
assegnata ad un determinato ente; all’ente spetta una ulteriore “ramificazione” per l’identificazione
di classi, sintassi ed attributi (1.3.6.1.4.1.250.1, 1.3.6.1.4.1.250.2, 1.3.6.1.4.1.250.3, …)
Design: namespace
La pianificazione dello spazio di nomi è uno degli step più importanti. Il namespace di una
directory impatta infatti sulla manutenzione dei dati, sulla flessibilità dell’applicazione delle ACL
(access control list) e della replicazione, sull’abilità di soddisfare le applicazioni directory ebabled,
sulla navigabilità della directory, … Eventuali errori di pianificazione del namespace devono essere
rivisti in fase di design onde evitare costi e disagi non trascurabili se l’operazione viene fatta dopo
la messa in produzione del servizio.
Struttura del namespace
Il modello del namespace LDAP deriva dallo standard X.500 ovvero una struttura gerarchica molto
rigida. Un tipico namespace X.500 inizia dalla nazione come top della gerarchia seguita dalla
provincia, città sino ad individuare singoli elementi come le persone. In pratica nello spazio di nomi
LDAP la radice della gerarchia viene individuata da una nomenclatura che rispecchia un dominio
DNS (generalmente quello aziendale).
Nella nomenclatura LDAP una entry nella directory viene indicata con il nome di Relative
Distinguished name (RDN). Ad esempio nella figura sottostante l’oggetto CN=Mario Rossi è
RDN. Un RDN deve essere univoco al di sotto di un medesimo “parent”. Quando viene determinata
la posizione del RDN rispetto al top della gerarchia del namespace combinando RDN con i nomi
delle entry di tutti gli oggetti “padre” il nome risultante prende il nome di distinguished name
(DN) ovvero:
CN=Mario Rossi, OU=people, dc=example, dc=com
Le più diffuse tipologie di organizzazione dello spazio di nomi di una directory rientrano tra le
seguenti:
- data organization: lo spazio di nomi fornisce una via per organizzare i dati. Ad esempio una
porzione della directory potrebbe ospitare gli oggetti relativi alle persone, un’altra porzione
contenere device quali stampanti o computers. Una tale organizzazione semplificherebbe la
navigabilità della directory.
- data partitioning: uno spazio di nomi gerarchico consente di partizionare la directory e di
suddividerla tra più server (generalmente per siti geografici distinti)
- data replication: strettamente legata al partizionamento della directory, consente di
pianificare la struttura dello spazio di nomi tenendo in considerazione le problematiche di
replicazione tra siti distinti
- access control: grazie all’utilizzo delle Access Control List (ACLs) è possibile delegare
l’amministrazione di porzioni dell’albero della directory. Ai fini di ottimizzare
l’applicazione delle ACL è preferibile raggruppare gli oggetti in funzione di coloro che
verranno preposti alla loro gestione.
Design: Topology Design
I servizi LDAP sono predisposti per supportare directory distribuite dove l’albero viene suddiviso
attraverso molteplici server. La topologia del servizio di directory descrive il modo in cui essa viene
frazionata tra i vari server e come questi vengono collocati nei vari siti dell’azienda/organizzazione.
Una directory che risiede su più server viene chiamata directory distribuita. Quando un albero di
directory viene suddiviso attraverso vari server ognuno di questi è responsabile per una singola
porzione dell’albero, quindi viene ridotto il carico di lavoro che esso deve svolgere. Utilizzando
questo principio di suddivisione in partizioni e assegnazione delle partizioni a vari server rende la
directory maggiormente scalabile, in termini di numero di entry, rispetto alla soluzione con singolo
server. Il servizio DNS opera in modo similare, ove ogni porzione dello spazio di nomi viene
assegnato ad un singolo server che può eventualmente essere replicato per incrementare la
disponibilità di servizio.
L’unità di suddivisione di una directory dipende dall’implementazione utilizzata: dove Novell
Directory usa il termine directory partition, lo standard X.500 usa il termine di naming context.
Netscape Directory server v6 chiama queste unità databases mentre Microsoft Active Directory usa
il termine domain. Tutti questi termini rappresentano essenzialmente la stessa cosa, qui si userà il
termine directory partition.
E’ importante tener presente che la directory stessa deve nascondere all’utente questo
partizionamento, nel senso che dal punto di vista dell’utilizzatore finale (utente o applicazione) essa
deve apparire come una singola, logica directory.
Directory partition
Per directory partition si intende una porzione completa (subtree) del directory information tree
(DIT). Una singola entry risiede in una sola directory partition, a tutte le entry all’interno di una
partizione condividono un unico “antenato” detto partition root.
Utilizzando questo principio è possibile suddividere una singola vasta directory in molti partizioni
minori ognuna delle quali verrà assegnata ad un server distinto sia per motivi di carico (query da
parte dei client) che per motivi di garanzia di servizio.
A sua volta un server non necessariamente deve contenere una singola partizione, ma potrebbe
ospitarne più di una (ad esempio una copia read only della top-level partition e una copia master di
una determinata organizational unit).
Knowledge reference
Sia lo standard LDAP che X.500 definiscono come knowledge reference i puntatori che stabiliscono
le relazioni tra le varie partizioni di una directory.
Esistono due tipi di knowledge reference:
1. immediate superior knowledge reference: puntatore verso l’alto del DIT verso la radice che
collega una partizione al suo diretto superiore. Esso costituisce il gancio che dal top della
partizione consente l’aggancio alla partizione “padre”
2. subordinate reference: puntatore verso il basso del DIT verso un’altra partizione, ovvero il
gancio verso altre directory partiotions
Le directory basate sullo standard LDAPv3 annunciano la partizione che essi detengono in na entry
speciale chiamata rootDSE. Per scoprire le partizioni contenute in un server è sufficiente eseguire
una query (scope=base) con filtro di ricerca (objectclass=*)
Risoluzione dei nomi in directory distribuite
La risoluzione dei nomi è il processo con cui una directory mappa un distinguished names (DN)
fornito da un client ad un oggetto della directory.
Il processo viene utilizzato nelle seguenti circostanze:
per localizzare l’oggetto base di partenza per una query LDAP
per localizzare una entry oggetto di modifica, cancellazione, rename o operazione di bind
per localizzare il padre (parent) di una entry che deve essere aggiunta alla directory
La DN presentata in questo modo prende il nome di purported name. Il client assume che esso
esista, e sta alla directory controllare se questo corrisponde al vero.
Nel caso più semplice il client contatta il directory server e presenta il DN di una entry contenuta
nel server. Il processo di risoluzione è semplice: il server controlla che la entry esista a in caso
positivo esegue l’azione richiesta dal client. Ad esempio, se un client tenta di leggere una entry
tramite una query LDAP, il server controlla che la DN della entry sia in una delle partizioni che
esso ospita; se così è, controlla la entry nel suo database. Se la entry esiste tutti gli attributi richiesti
dal client vengono restituiti. In caso contrario viene restituito un errore del tipo “no such object”.
Se il client presenta un nome (purported name) il cui DN non è in una delle directory partition
ospitate dal server, questo deve usare tutti i knowledge reference disponibili per risolvere il nome
stesso oppure supportare il client in modo che possa localizzare il server che possa risolvere il nome
proposto. I collegamenti knowledge reference descrivono completamente come una directory
partition è inserita all’interno di un DIT, in tal modo un server è sempre in grado di sapere se il
passo successivo per il processo di risoluzione implica navigare in alto o in basso all’interno del
DIT.
LDAP Referrals e Search Result Continuation Reference sono porzioni di informazioni knowledge
reference inoltrate da un server LDAP ad un client LDAP che indicano altri server da contattare ai
fini di soddisfare la richiesta del client stesso.
LDAP Referrals: quando un client LDAP inoltra una operazione LDAP ti aggiunta, modifica,
cancellazione, o una ricerca con uno scope base-level, se il server non contiene la entry di
destinazione, l’informazione di knowledge reference viene ritornata al client in un LDAP referral,
ovvero un tipo speciale di messaggio di risultato LDAP che dirire il client ad un altro server che
potrebbe soddisfare l’operazione richiesta.
LDAP search result continuation reference: quando un client LDAP inoltra una query di tipo
one-level o subtree ed il server è a conoscenza di altre partizioni di directory subordinate, le
rispettive knowledge references vengono restituite al client come risultato della ricerca.
In altre parolei due concetti sono molto simili: l’unica differenza significativa sta nel fatto che le
LDAP referrals sono contenute in un LDAP result message mentre le altre come risultato di una
ricerca.
Le informazioni contenute in un referral o reference sono in forma LDAP Uniform Resource
Locator (URL) come definito nella RFC 2255 e sono le seguenti:
- host name del server da contattare
- porta del server
- base DN (nel caso di una operazione di search), o target DN (per operazioni di add,
delete, modifica, …)
Ad esempio se un client contatta il server2 per cercare l’albero dc=example,dc=com per tutte le
entry con cognome Smith il referral potrebbe essere:
ldap://server3.example.com:389/ou=Engineering%2Cdc=example%2Cdc=com
Questa URL indica che il client dovrà contattare l’host server3.example.com sulla porta 389 e
sottoporre una ricerca instradata al subtree ou=Engineering,dc=example,dc=com. Ogni
virgola all’interno del DN viene sostituita dal codice di escape “%2C”.
Design: Replication
Il processo di replica delle directory consente di mantenere i dati di questa disponibili su vari server
in modo da evitare single point of failure e per incrementare le performance, consentendo di avere
copia della directory disponibile e “vicina” ad utenti e gruppi che la utilizzano.
Attuando la replica, quindi la disponibilità dei dati della directory su più server distinti in luoghi
diversi si incrementa l’affidabilità del servizio. Se uno dei server presenta un malfunzionamento, i
client e le applicazioni directory-enabled possono contattare un altro server, La replica consente
pure di non incorrere in un disservizio a causa di problemi di rete. Si pensi a due sedi di una azienda
in due siti geografici distinti, ciascuna con il suo server, l’eventuale down del link tra i due siti non
comporterà alcun disservizio, se non per un minimo disallineamento delle repliche tra i rispettivi
server.
Strategie di replica
Single-master replication: in questo caso sono un server possiede una copia in scrittura della
directory, le repliche ne contengono la rispettiva copia in sola lettura. Tutte le operazioni di ricerca,
comparazione e bind possono venire soddisfatte da qualunque server (anche non master).
L’implementazione di soluzioni single-master introduce un single point of failure corrispondente al
server che possiede la copia in scrittura della directory.
Multimaster replication: in questo caso è sempre disponibile più di una copia in scrittura della
directory. I client possono inviare una operazione di update a qualsiasi replica. Diventa in questo
caso responsabilità dei server assicurare che le modifiche vengano propagate in maniera
consistente. La replica multimaster da un lato elmina il single point of failure, dall’altro introduce la
complessità della risoluzione dei conflitti di update
