Account Manangement: Integration of Active Directory with Fedora Directory Server and Likewise Identity

INTRODUZIONE                                                                                                                              
 
xii 
 
molte aziende, e lo sarà sempre più nel futuro in quanto conferisce un unico punto 
di amministrazione per una vasta gamma di servizi Internet e intranet e permette di 
gestire in modo integrato utenti, servers, stampanti, sistemi di file, controllo di 
accesso, norme di rete, sistemi desktop e impiego di applicazioni a livello aziendale. 
Alle necessità di alta affidaELOLWjHFRQWLQXLWjVLDVVRFLDO¶HVLJHQ]D di livelli di 
VFDODELOLWj GHOO¶infrastruttura che rispondano alle dinamiche di evoluzione dei 
volumi di servizi erogati.  
PULPDGHOO¶avvento delle Directory ServicesVSHVVRXQ¶XWHQWHFKHVLWURYDYD
a lavorare in una rete aziendale, veniva fornito di diverse password per poter 
usufriure dei servizi messi a sua disposizione, di conseguenza durante il lavoro 
giornaliero doveva ricordare più password, con ovvi problemi di memorizzazione. 
8QHVHPSLRHO¶LPPDJLQHsuccessiva. 
 
2SSXUHSRWHYDFDSLWDUH LO FDVR LQ FXLXQ¶XWHQWHGRYHYDFRPXQLFDUHFRQXQ
DOWURXWHQWH DOO¶LQWHUQRGLXQD VWHVVD rete aziendale e non era possibile utilizzare 
soltanto il nome della persona, ma occorreva necessariamente la sua e-mail. 
8Q¶DOWUa situazione che poteva capitare, riguarda la semplice stampa di un 
documento. Se non si disponeva di una stampante connessa al proprio computer, 
INTRODUZIONE                                    
 
xiii 
 
occorreva utilizzare una stampante di rete e per poterne usufruire, occorreva 
procurarsi tutte le informazioni necessarie per una corretta stampa, che spesso 
invece non avveniva a causa di eventuali errori nelle informazioni relative alla 
stampante. 
Per assolvere a questi e ad altri problemi, fu impiegata una singola directory 
aziendale anziché gestire dozzine di database sugli utenti e le risorse di rete. Una 
singola directory gerarchica che centralizzasse tutte le informazioni. Con il suo 
impiego è possibile effettuare richieste nella directory da ciascun punto di 
connessione sulla rete. E inoltre può essere facilmente replicata in pochi minuti e 
distribuita ai servers nei più lontani punti della rete. 
In questo tesi vengono riportati vari approci, per una corretta gestione delle 
XWHQ]H DOO¶LQWHUQR GL XQD UHWH SL R PHQR HVWHVD SUHVHQWDQGR XQ¶DUFKLWHWWXUD
realizzata mediante software opensource e proprietario per i servizi di directory.  
6SHVVRDOO¶LQWHrno di una rete ci si trova a gestire richieste di autenticazioni e 
autorizzazione provenienti da computer basati su sistemi operativi differenti. Per 
ovviare a tale problema, e quindi fare in modo che tutti gli utenti siano 
correttamente autenticati e autorizzati, ho analizzato e configurato due diversi 
servizi di directoryXQRQHOPRQGR/LQX[HO¶DOWURLQTXHOOR:LQGRZVLQPRGRWDOH
che si sincronizzino tra di loro per poter gestire contemporaneamente richieste di 
autenticazione e autorizzazione provenienti da computer con sistemi operativi 
differenti.  
 
 
 
 
INTRODUZIONE                                                                                                                              
 
xiv 
 
 
 
CAPITOLO 1                                                                                                                                                                                          DIRECTORY SERVICE 
 
1 
 
 
CAPITOLO 1 
 
DIRECTORY SERVICE 
 
1.1    Definizione di Directory 
 
Una directory è un contenitore di dati. Ad esempio, una directory è una guida 
TV, la quale elenca i programmi televisivi e gli orari di programmazione. Queste 
directory tradizionali sono stampate e distribuite a intervalli regolari e non sono 
modificate, ma sostituite da nuove emissioni; pertanto possono essere considerate 
directory non in linea. Tali directory sono utilizzate generalmente per la 
pubblicazione di informazioni di sola lettura.  
Una directory in linea è una directory a cui è possibile accedere e che è 
possibile aggiornare elettronicamente su una rete di computer, una LAN (local area 
network), una WAN (wide area network) o anche Internet. Molte directory non in 
linea dispongono di una corrispettiva directory in linea o elettronica. Le compagnie 
telefoniche pubblicano i propri elenchi e le pagine gialle sul Web e forniscono 
XQ¶LQWHUIDFFLDGLVHPSOLFHXWLOL]]R 
Altri tipi di directory in linea includono directory di applicazioni e directory 
destinate a un determinato scopo. Una directory di applicazione è relativa a 
XQ¶DSSOLFD]LRne software, ad esempio Lotus Notes o Novell GroupWise. Entrambe 
XWLOL]]DQRGLUHFWRU\SURSULHWDULHDGDWWHDOOHHVLJHQ]HVSHFLILFKHGHOO¶DSSOicazione.  
Una directory destinata a un determinato scopo può essere utilizzata da 
qualsiasi applicazione, ma è legata alla gestione dei dati per un obiettivo limitato. 
Un esempio di questo tipo di directory è rappresentato dal DNS (Domain Name 
System) utilizzato da Internet. Anche se differenti applicazioni utilizzano il DNS, le 
informazioni in esso contenute sono utili solo per specifiche attività, quali la 
risoluzione dei nomi e degli indirizzi IP.  
DIRECTORY SERVICE                                                                                                                                                                                          CAPITOLO 1                                                  
 
2 
 
Le directory di rete sono directory in linea che memorizzano informazioni 
relative DLVHUYL]LHDOOHULVRUVHGLUHWH,QJHQHUHLQFOXGRQRLQIRUPD]LRQLVXOO¶XWHQWH
su dati di protezione e un elenco di servizi disponibili, come i servizi di 
pubblicazione e di stampa.  
 
1.2    Definizione di un Servizio di Directory 
 
Spesso, alla domanda relativa a cosa è un servizio di directory, la maggior 
SDUWHGHOOHSHUVRQHULVSRQGHULIHUHQGRVLDOO¶RSHUDWRUHWHOHIRQLFRFKHULFHUFDLQXPHUL
WHOHIRQLFLSHU O¶XWHQWH ,QHIIHWWL OD ULVSRVWDqFRUUHWWD6H ODGLUHFWRU\ UDSSUHVHQta i 
GDWLHIIHWWLYLFLRqO¶HOHQFRGLSHUVRQHHLQXPHULWHOHIRQLFLJOLRSHUDWRULHLOPHWRGR
mediante cui sono chiamati, rappresenta il servizio di directory. Nel mondo 
elettronico le cose non stanno diversamente. La figura sottostante illustra un 
confronto tra un servizio di directory telefonico tradizionale e un servizio di 
directory elettronico.  
 
8QVHUYL]LRGLGLUHFWRU\IRUQLVFHO¶DUFKLYLD]LRQHHLOUHFXSHURGLLQIRUPD]LRQL
di directory per utenti e applicazioni. Le aree interessate dal servizio di directory 
CAPITOLO 1                                                                                                                                                                                          DIRECTORY SERVICE 
 
3 
 
riguarGDQROHSUHVWD]LRQLODSURWH]LRQHO¶DIILGDELOLWjODGLVSRQLELOLWjHODVHPSOLFLWj
di utiliz]R4XHVW¶XOWLPDFRPSRUWDFKHJOLVYLOXSSDWRULSRVVRQRVFULYHUHDSSOLFD]LRQL
per accedere alle informazioni di directory senza eccessive difficoltà di 
programmazione.  
Le directory di rete forniscono soluzioni adatte. Per assicurare elevata 
disponibilità, le informazioni di directory sono replicate in molti servers. I 
computers che accedono alle informazioni nella directory possono effettuare la 
stessa operazione dal server più vicino, con conseguente miglioramento delle 
prestazioni. Poiché è possibile raccogliere e presentare le informazioni di directory 
LQGLYHUVLPRGLQHULVXOWDXQDSLVHPSOLFHDFFHVVLELOLWjSHUO¶XWHQWHILnale.  
I servizi di directory facilitano le attività per gli sviluppatori, gli 
amministratori e gli utenti finali. Per uno sviluppatore, i servizi di directory 
facilitano la memorizzazione e la ricerca di informazioni relative alle risorse di rete. 
Le applicazioni possono pubblicare informazioni da memorizzare nella directory di 
rete che possono essere utilizzate da altre applicazioni; gli amministratori di rete 
ottengono vantaggi rappresentati da un miglioramento della protezione e dalla 
semplicità di amministrazione. Gli utenti beneficiano di un modello di protezione 
comune (senza la necessità di diverse password); essi usufruiscono della 
condivisione di dati tra applicazioni e non devono più ricordare elementi specifici di 
una risorsa nella directory, come ad esempio il percorso di rete della stampante.  
 
1.3    Cenni Storici sulle Directory 
 
Le directory di rete comportano grandi vantaggi per gli utenti, per i 
professionisti IT e gli sviluppatori. Il modo in cui tali vantaggi si sviluppano, è 
determinato dalla storia delle directory di rete, specialmente dallo sviluppo e 
GDOO¶HYROX]LRQH GHO DNS, X.500 e LDAP, tre servizi di directory. La figura 
sottostante illustra i periodi di alcuni degli eventi più significativi nella storia delle 
directory.  
DIRECTORY SERVICE                                                                                                                                                                                          CAPITOLO 1                                                  
 
4 
 
 
 
1.4    DNS (Domain Name System) 
 
Una delle principali directory elettroniche, il sistema DNS (Domain Name 
System) prevede la corrispondenza dei nomi di dominio, su Internet, con i rispettivi 
indirizzi IP (Internet Protocol) difficili da ricordare. Come le persone dispongono di 
numeri telefonici, i computer su una rete TCP/IP dispongono di indirizzi IP. 
Affinché un computer comunichi con un altro computer sulla rete, è necessario che 
FRQRVFDO¶LQGLUL]]R,3GHOO¶DOWURFRPSXWHU/HLQIRUPD]LRQLXWLOL]]DWHGDl DNS sono 
create localmente e distribuite globalmente. È possibile aggiungere un nuovo 
computer alla rete, assegnargli il nome copper1 e indicare al server DNS il nuovo 
QRPHGHOFRPSXWHUHO¶LQGLUL]]R,3 
Data la presenza su Internet di migliaia di computer, sarebbe dispendioso 
replicare tutte le informazioni a tutti i server DNS. Invece, quando un server DNS 
non riconosce un nome che gli viene fornito, invia la richiesta a un altro server DNS 
CAPITOLO 1                                                                                                                                                                                          DIRECTORY SERVICE 
 
5 
 
nella catena. Infine, il sistema rileva il server responsabile del dominio 
coppersoftware.com, richiede la ricerca di copper1 H UHVWLWXLVFH O¶LQGLUL]]R ,3
Poiché DNS è un sistema notevolmente solido, tutti i computer connessi a Internet 
sono in grado di comunicare con copper1, specificando il nome 
copper1.coppersoftware.com; il nome di dominio completo per il DNS di rete 
rappresenta un eloquente esempio di directory destinata a un determinato scopo. 
 
1.5     Servizio di Directory X.500 
 
Il proliferare di applicazioni di rete ha comportato la necessità di directory 
standardizzate che implementassero interfacce di programmazione comuni, in modo 
che più applicazioni potessero accedere alle stesse informazioni. Questo periodo ha 
DYXWR LQL]LR QHO FRUVR GHJOL DQQL ¶ FRQ GLYHUVH RUJDQL]]D]LRQL D]LHQGDOL H
accademiche volte alla ricerca di una soluzione comune di directory. Nel 1988, 
O¶,QWHUQDWLRQDO7HOHFRPPXQLFDtions Union ha pubblicato i servizi di directory X.500 
e definito il protocollo DAP (Directory Access Protocol). Questo standard 
rappresentava il culmine dello sforzo compiuto da CCITT (International Telephone 
and Telegraph Consultative Committee), ora nota come ITU-T, e 
GHOO¶RUJDQL]]D]LRQH ,62 ,QWHUQDWLRQDO 6WDQGDUGV 2UJDQL]DWLRQ SHU SURdurre uno 
standard globale dei servizi di directory. Lo standard X.500 è stato aggiornato nel 
1993 e in seguito nel 1997.  
6YLOXSSDWL GDOO¶LQL]LR SHU HVVHUH XQ VHUYL]LR GL GLUHFWRU\ JOREDOH
omnicomprensivo, X.500 e DAP furono considerati difficili da implementare e non 
ebbero ampia diffusione commerciale. Un altro limite fu rappresentato dal fatto che 
X.500 dipendeva dai protocolli di rete OSI (Open Systems Interconnect) anziché dai 
modelli Internet attualmente prevalenti, basati su TCP/IP. Sebbene X.500 
presentasse una natura distribuita ed efficaci funzionalità di ricerca nelle directory, 
WDOLFDUDWWHULVWLFKHULFKLHGHYDQRXQ¶HOHYDta quantità di risorse di elaborazione.  
DIRECTORY SERVICE                                                                                                                                                                                          CAPITOLO 1                                                  
 
6 
 
Quando i fornitori di software esaminarono X.500, rilevarono che la 
FRPSOHVVLWj GHOO¶LQWHUIDFFLD HUD SUHRFFXSDQWH H QRQ VL UHVHUR FRQWUR GHOOH
potenzialità di questo stanGDUGHIILFDFHHDSHUWR(VVLQRQLQWXLURQRO¶LPSRUWDQ]DGL
un servizio di directory gloEDOH H OH GLUHFWRU\ SURSULHWDULH HEEHUR XQ¶HYROX]LRQH
analoga al software utilizzato. La figura successiva illustra i componenti di un 
sistema X.500.  
 
 
 
1.6    /¶DYYHQWRGL/'$3 
 
Le versioni precedenti delle applicazioni utilizzavano directory, che però 
erano proprietarie, QHO VHQVR FKH O¶LQWHURSHUDELOLWj FRQ DOWUL FOLHQWs era disponibile 
solo in determinati casi. La flessibilità, la protezione e la replica erano minime o 
addirittura inesistenti. I sistemi operativi di rete come Banyan VINES, Microsoft 
:LQGRZV 17 H 1RYHOO 1HW:DUH LQL]LDURQR O¶LPSOHPHQWD]LRQH GL PRGXOL GL
directory per gestire utenti e risorse di rete. NetWare disponeva di Bindery, mentre 
Windows NT disponeva del database SAM (Security Account Manager). Banyan 
iniziò con un servizio di directory integrato denominato StreetTalk, innovativo ma 
che non ottenne mai un successo commerciale. Ciascuna directory memorizzava 
CAPITOLO 1                                                                                                                                                                                          DIRECTORY SERVICE 
 
7 
 
informazioni sugli utenti e le risorse di rete, ma ciascuna era orientata verso 
O¶DXWHQWLFD]LRQH H OD SURWH]LRQH che erano le esigenze principali dei sistemi 
operativi di rete in quel periodo.  
Dal 1993, con la seconda revisione di X.500 che generò un lieve interesse 
comPHUFLDOH XQ JUXSSR GL ULFHUFDWRUL GHOO¶8QLYHUVLWj GHO 0LFKLJDQ VYLOXSSDURQR
XQ¶DOWHUQDWLYD DOOD FRPSOHVVD LQWHUIDFFLD '$3 LQ; /¶RELHWWLYR HUD TXHOOR GL
creare un protocollo di accesso più semplice alle directory X.500. Il gruppo creò un 
protocollo che rimuove-va molti elementi di X.500 di intralcio agli sviluppatori, 
particolarmente il modello di rete OSI, e che eliminava molte delle funzioni non 
utilizzate di DAP. Questa versione di DAP partì come DIXIE (RFC 1249) e divenne 
nota come LDAP (Lightweight Directory Access Protocol). Anche se questa prima 
versione di LDAP costituiva un notevole miglioramento rispetto al complesso DAP 
di X.500, non fu immediatamente presa in considerazione dai fornitori, almeno fino 
alla pubblicazione di LDAPv2 (nella forma proposta in RFC 1487 e come standard 
in RFC 1777).  
Inizialmente, LDAP era una semplice alternativa al protocollo DAP di X.500. 
Tuttavia, poiché LDAP definiva il protocollo, gli sviluppatori erano liberi di 
effettuare le implementazioni di un servizio di directory che si conformava 
semplicemente ai requisiti di LDAP e non richiedeva X.500. La prima 
LPSOHPHQWD]LRQH IX HIIHWWXDWD SUHVVR O¶8QLversità del Michigan, dove nel 1995 
furono sviluppati SLAPD (stand-alone LDAP daemon) e il relativo partner di 
replica SLURPD (stand-alone LDAP update replication daemon). SLAPD era un 
semplice server LDAP in grado di comunicare con diversi database differenti che 
fungevano da directory. SLURPD era il programma che replicava le modifiche 
apportate nel database di directory, agli altri computer che fungevano da server di 
directory.  
,PSRUWDQWH SHU LO VXFFHVVR GL /'$3 IX LQROWUH OR VYLOXSSR GHOO¶LQWHUIDFFLD
API (Application Programming Interface) per il linguaggio C. Definita in RFC 
1823, questa API include un insieme di funzioni che gli sviluppatori possono