Chapter 22. Fondamenti del collegamento in rete / 22.9. LDAP — Un servizio directory | ||||
|---|---|---|---|---|
 | 22.8. NIS: Network Information Service | 22.10. NFS – file system dislocati |  | |
Chapter 22. Fondamenti del collegamento in rete / 22.9. LDAP — Un servizio directory | ||||
|---|---|---|---|---|
| 22.8. NIS: Network Information Service | 22.10. NFS – file system dislocati | | |
In ambienti di lavoro collegati in rete è determinante che le informazioni importanti siano tenute in serbo in modo strutturato e che siano reperibili immediatamente. Questo problema viene risolto da un servizio directory, il quale alla stregua delle pagine gialle (ingl.Yellow Pages) che conosciamo dalla vita quotidiana, contiene le informazioni richieste in una forma ben strutturata, di facile consultazione ed immediatamente individuabili.
Nel caso ideale vi è un server centrale contenente i dati in una determinata directory che li distribuisce ai client nella rete tramite un protocollo particolare. I dati dovrebbero essere strutturati in modo che una gamma quanto vasta possibile di applicativi possa accedervi. In tal modo non è necessario che ogni tool per calendari o e-mail client disponga di una propria banca dati, ma potrà accede ad uno stock di dati gestiti centralmente. Questo ridurrebbe notevolmente il numero degli interventi di natura amministrativa per le informazioni in questione. Un protocollo aperto e standardizzato come LDAP (ingl. Lightweight Directory Access Protocol) assicura che una gamma quanto vasta possibile di applicazioni client possa accedere ai dati richiesti.
In questo contesto una directory assume il ruolo di una specie di banca dati ideata e ottimizzata sotto un punto di vista della sua accessibilità e idoneità per una facile e rapida consultazione:
Per poter realizzare un numero considerevole di accessi in lettura (contemporanei), l'accesso in scrittura viene limitato ai pochi aggiornamenti eseguiti dall'amministratore. Le banche dati si distinguono per la loro caratteristica di recepire in tempi brevi un volume di dati quanto vasto possibile.
Visto il numero ridotto degli accessi in scrittura sono solitamente dei dati possibilmente statici ad essere amministrati tramite un servizio directory, mentre i dati di una banca dati convenzionale sono di solito di natura dinamica visto che cambiano frequentemente. Per fare un esempio, la lista dei numeri di telefono dei dipendenti non cambieràcosì spesso come invece i dati del reparto di contabilità.
Nel caso di dati statici l'aggiornamento dei set di dati esistenti avviene raramente; nel caso di dati dinamici, soprattutto quando si tratta di set di dati relativi a conti bancari e contabilità, è la consistenza dei dati ad assumere un ruolo di primo piano. Se una somma va detratta da una parte e aggiunta ad un'altra, le due operazioni devono avvenire contemporaneamente, cioè tramite una sola “transazione” per assicurare la consistenza dei dati nel loro insieme. Banche dati supportano queste transazioni, directory no. Nel caso delle directory comunque inconsistenze temporanee sono accettabili.
Lo scopo di un servizio directory come LDAP non è tanto quello di supportare complessi meccanismi di aggiornamento ed interrogazione; si tratta piuttosto di consentire agli applicativi, che accedono a questo servizio, di accedervi in modo quanto semplice e veloce possibile.
Esistono tanti servizi directory, e non solo nel mondo Unix, ad esempio NDS di Novell, ADS di Microsoft, Banyans Street Talk e lo standard OSI X.500.
Originariamente LDAP è stato concepito come versione 'snella' di DAP (ingl. Directory Access Protocol), sviluppato per l'accesso a X.500. Lo standard X.500 regola la disposizione gerarchica delle voci della directory.
LDAP è stato per così dire alleggerito di alcune funzionalitàdi DAP, può essere utilizzato cross-plattform e fa un uso parsimonioso delle risorse, senza dover rinunciare alla disposizione gerarchica delle voci di X.500. Grazie a TCP/IP, diventa più semplice interfacciare applicazione e servizio LDAP.
Nel frattempo si è proseguito nello sviluppo di LDAP, e sempre più spesso LDAP viene implementato come soluzione stand-alone senza supporto per X.500. Con LDAPv3 (la versione del protocollo a vostra disposizione una volta installato il pacchetto openldap2 , LDAP supporta i cosiddetti Referrals che permettono di realizzare banche dati dislocate. Nuovo è anche il fatto che viene utilizzato SASL (ingl.Simple Authentication and Security Layer) quale strato di autenticazione e di sicurezza.
L'uso di LDAP non si limita alla possibilità di inviare delle richieste ai server X.500 come era invece previsto all'inizio. Con slapd esiste un server open source con il quale archiviare le informazioni degli oggetti in una banca dati locale. Questo server viene completato da slurpd preposto alla replica di più server LDAP.
Il pacchetto openldap2 è composto principalmente di due programmi.
Un server LDAPv3 stand-alone che amministra le informazioni degli oggetti in una banca dati basata su BerkeleyDB.
Questo programma replica le modifiche apportate ai dati del server LDAP locale agli altri server LDAP presenti nella rete.
slapcat, slapadd, slapindex
Un amministratore di sistema Unix utilizza solitamente il servizio NIS per la risoluzione dei nomi e la distribuzione dei dati nella rete. Un server centrale distribuisce ai client presenti sulla rete i dati di configurazione dei file e directory di /etc: group, hosts, mail, netgroup, networks, passwd, printcap, protocols, rpc e services. L'amministrazione di questi semplici file di testo risulta essere semplice, ma il tutto diventa più complicato quando si tratta di gestire una maggior quantitativo di dati, visto che manca ogni tipo di strutturazione. NIS è stato ideato solo per piattaforme Unix, quindi non può essere utilizzato per l'amministrazione centralizzata dei dati in una rete eterogenea.
LDAP invece non si limita a reti puramente Unix. Server Windows (a partire da Windows 2000) supportano LDAP quale servizio di directory. Anche Novell offre il servizio LDAP. Inoltre, LDAP sa fare più di quanto riferito finora.
LDAP può essere utilizzato per qualisiasi struttura di dati da amministrare centralmente. Ecco alcuni esempi:
In sostituzione di un server NIS
Mail routing (postfix, sendmail)
Rubriche per mail client come Mozilla , Evolution, Outlook, ....
Amministrazione delle descrizioni delle zone di un server dei nomi BIND9
e l'elenco non si esaurisce qui, visto che al contrario di NIS, LDAP è scalabile. La chiara struttura gerarchica dei dati è di aiuto quando si tratta di amministrare una quantità considerevole di dati.
Una directory LDAP ha una struttura ad albero. Tutte le registrazioni (dette oggetti) nella directory hanno un posizione ben definita all' interno di questa gerarchia. Questo gerarchia porta il nome di Directory Information Tree abbreviato con DIT. Il percorso completo che porta alla registrazione richiesta viene chiamato Distinguished Name abbreviato con DN. I singoli nodi che portano alla registrazione richiesta vengono chiamati Relative Distinguished Name o RDN. Gli oggetti sono in sostanza di due tipi:
Questi oggetti contengono altri oggetti. Queste classi di oggetti sono root (radice immaginaria dell'albero delle directory), c (ingl. country), ou (ingl. OrganizationalUnit) e dc (ingl. domainComponent). Questo modello ricorda quello delle directory in un file system.
Questi oggetti si trovano alla fine di un ramo. Al di sotto non vi sono altri oggetti. Esempi: Person, InetOrgPerson oppure groupofNames.
In cima alla gerarchia abbiamo una radice root. Seguono poi per esempio c (ingl. country), dc (ingl. domainComponent) oppure o (ingl. organization).
Le relazioni che intercorrono all'interno di un albero di directory LDAP vengono illustrate nel seguente esempio (si veda figura Figure 22.21, “Struttura di una directory LDAP”).
L'intera figura comprende un Directory Information Tree esempio. Le registrazioni (entries ) sono riportate su tre livelli. Ogni registrazione corrisponde nella figura ad un quadretto. Il Distinguished Name completo e valido per il dipendente SuSE fittizio Geeko Linux è cn=Geeko Linux,ou=doc,dc=suse,dc=de, che viene composto aggiungendo l'RDN cn=Geeko Linux al DN della registrazione precedente ou=doc,dc=suse,dc=de.
L'impostazione globale, quale tipo di oggetti debba essere archiviato nel DIT si realizza tramite uno schema . Il tipo di un oggetto viene stabilito tramite la Classe di oggetto. La classe di oggetto determina quali attributi debbano oppure possano essere assegnati all'oggetto in questione. Uno schema deve quindi contenere le definizioni di tutte le classi di oggetto e di tutti gli attributi utilizzati nello scenario di impiego desiderato. Esistono alcuni schemi diffusi (si veda RFC 2252 e 2256). Comunque, potete anche generare degli schemi vostri oppure utilizzare diversi schemi che si completano a vicenda, se richiesto dall'ambiente in cui viene utilizzato il server LDAP.
La tabella Table 22.10, “Classi di oggetto e attributi frequenti” offre una rassegna delle classi di oggetto utilizzate nell'esempio prese da core.schema e inetorgperson.schema con gli attributi necessari e valori di attributo adatti.
Table 22.10. Classi di oggetto e attributi frequenti
Classe di oggetto | Significato | Registrazione esempio | Attributi richiesti |
|---|---|---|---|
dcObject | domainComponent (parti del nome del dominio) | suse | dc |
organizationalUnit | organizationalUnit (Unita di organizzazione) | doc | ou |
inetOrgPerson | inetOrgPerson (Dati di persone per Intranet/Internet) | Geeko Linux | sn e cn |
Nell'output Example 22.17, “Estratto dal schema.core (A scopo esplicativo sono state numerate le righe)” vedete un'estratto di una direttiva schema con commenti che vi aiuteranno a comprendere la sintassi di nuovi schemi.
Example 22.17. Estratto dal schema.core (A scopo esplicativo sono state numerate le righe)
...
#1 attributetype ( 2.5.4.11 NAME ( 'ou' 'organizationalUnitName')
#2 DESC 'RFC2256: organizational unit this object belongs to'
#3 SUP name )
...
#4 objectclass ( 2.5.6.5 NAME 'organizationalUnit'
#5 DESC 'RFC2256: an organizational unit'
#6 SUP top STRUCTURAL
#7 MUST ou
#8 MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
x121Address $ registeredAddress $ destinationIndicator $
preferredDeliveryMethod $ telexNumber $
teletexTerminalIdentifier $ telephoneNumber $
internationaliSDNNumber $ facsimileTelephoneNumber $
street $ postOfficeBox $ postalCode $ postalAddress $
physicalDeliveryOfficeName $ st $ l $ description) )
...
Come esempio abbiamo il tipo di attributo organizationalUnitName e la classe di oggetto relativa organizationalUnit. Nel primo rigo abbiamo il nome dell'attributo, OID (Object Identifier) (numerico) univoco e l'abbreviazione dell'attributo. Il rigo 2 viene introdotto da DESC, una breve descrizione dell' attributo a cui qui segue l'indicazione del relativo RFC da cui è stata presa la definizione. SUP nel rigo 3 rimanda ad un tipo di attributo superiore, a cui appartiene questo attributo.
La definizione della classe di oggetto organizationalUnit inizia al rigo 4 come per la definizione dell'attributo con un OID ed un nome per la classe di oggetto. Nel rigo 5 abbiamo una breve descrizione della classe di oggetto. Con la registrazione SUP top il rigo 6 vi indica che questa classe di oggetto non è subordinata ad un'altra classe di oggetto. Nel rigo 7 vengono indicati dopo MUST tutti i tipi di attributo che devono essere utilizzati in un oggetto del tipo organizationalUnit. Nel rigo 8, dopo MAY avete l'elenco dei tipi di attributo che possono essere utilizzati con questa classi di oggetti.
Per una introduzione molto valida all'uso degli schemi rimandiamo alla documentazione su OpenLDAP che trovate nel vostro sistema installato sotto /usr/share/doc/packages/openldap2/admin-guide/index.html.
/etc/openldap/slapd.conf è il file di configurazione del vostro server LDAP, una volta inizializzato il sistema. Di seguito illustreremo brevemente le singole registrazioni e gli adattamenti necessari. Tenete presente che le registrazioni con un # all'inizio non sono abilitate. Per abilitarle dovete eliminare questo segno di commento.
Example 22.18. slapd.conf: direttiva include per schemi
include /etc/openldap/schema/core.schema include /etc/openldap/schema/inetorgperson.schema
Con questa prima direttiva in slapd.conf viene specificato lo schema secondo il quale è organizzata la vostra directory LDAP (si veda l'output Example 22.18, “slapd.conf: direttiva include per schemi”). La registrazione core.schema è obbligatoria. Se dovessero servirvi ulteriori schemi, aggiungeteli a questa direttiva (nell' esempio è stato aggiunto inetorgperson.schema). Altri schemi disponibili sono reperibili nella directory >/etc/openldap/schema/. Se intendete sostituire NIS tramite un servizio LDAP analogo, integrate qui gli schemi cosine.schema e rfc2307bis.schema . Per ulteriori informazioni su questa problematica, consultate la documentazione OpenLDAP fornita a corredo.
Example 22.19. slapd.conf: pidfile ed argsfile
pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args
Questi due file contengono il PID (ingl.process id ) e alcuni argomenti con i quali lanciare il processo slapd. Qui non è necessario apportare delle modifiche.
Example 22.20. slapd.conf: controllo degli accessi
# Sample Access Control
# Allow read access of root DSE
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
#
access to dn="" by * read
access to *
by self write
by users read
by anonymous auth
#
# if no access controls are present, the default is:
# Allow read by all
#
# rootdn can always write!
Nell'esempio Example 22.20, “slapd.conf: controllo degli accessi” vedete la sezione di slapd.conf che regola il controllo degli accessi alla directory LDAP sul server. Le impostazioni effettuate nella sezione globale di slapd.conf sono effettive, almenoché non vengono sovrascritte da proprie regole di accesso impostate nella sezione della banca dati. Nell'esempio riportato tutti gli utenti hanno accesso in lettura alla directory, ma solo l'amministratore (rootdn) ha il permesso di scrittura. Regolare i permessi di accesso sotto LDAP è un processo molto complesso, ecco alcune regole di base che vi aiutano a comprendere tale processo.
Ogni regola di accesso è strutturata nel modo seguente:
access to <what> by <who> <access>
what sta per l'oggetto o l'attributo a cui consentite di accedere. Potete proteggere singoli rami dell' albero directory in modo esplicito tramite proprie regole oppure impostare una regola per intere sezioni dell'albero directory tramite espressioni regolari. slapd analizzerà le regole nella sequenza riportata nel file di configurazione. Quindi le regole di ordine generale dovrebbero seguire a quelle più specifiche. slapd elaborerà la prima regola che giudicherà adeguata ed ignorerà tutte le registrazioni seguenti.
who stabilisce chi ha l'accesso a quanto impostato sotto what. Anche qui utilizzando delle espressioni regolari potete semplificarvi le cose. Anche in questo caso non appena slapd fa “centro” interromperà l' analisi di who, quindi regole di ordine generale dovrebbero seguire quelle più specifiche. Ecco le registrazioni possibili (si veda la tabella Table 22.11, “Gruppi utenti con permesso di accesso”):
access specifica il tipo di accesso. Si distingue tra le possibilità riportate nella tabella Table 22.12, “Tipi di accesso”
Table 22.12. Tipi di accesso
Identificatore | Significato |
|---|---|
none | Accesso negato |
auth | Per la presa di contatto con il server |
compare | Per l'accesso comparato agli oggetti |
search | Per l'applicazione di filtri di ricerca |
read | Permesso di lettura |
write | Permesso di scrittura |
slapd confronta il permesso richiesto dal client con quello concesso in slapd.conf. Se il permesso lì definito è superiore o uguale a quello richiesto dal client, l'accesso viene concesso. Se invece il client richiede permessi superiori, l'accesso viene negato.
Nell'output Example 22.21, “slapd.conf: esempio per il controllo degli accessi” vedete un esempio per un controllo degli accessi semplice su cui potete intervenire a piacimento tramite l'uso di espressioni regolari.
Example 22.21. slapd.conf: esempio per il controllo degli accessi
access to dn.regex="ou=([^,]+),dc=suse,dc=de" by dn.regex="cn=administrator,ou=$1,dc=suse,dc=de" write by user read by * none
Questa regola stabilisce che solo il relativo amministratore ha l'accesso in scrittura alle registrazioni ou. Gli altri utenti autenticati hanno il permesso di lettura ed a tutti gli altri viene negato ogni accesso.
![[Tip]](admon/tip.png) | Impostare le regole di accesso |
|---|---|
L'accesso viene negato se non vi è alcuna regola access to oppure alcuna direttiva by <who> valida. Vengono concessi solo i permessi esplicitamente indicati. Se non viene stabilita alcuna regola, vale il principio: permesso di scrittura per l'amministratore e quello di lettura per tutti gli altri. | |
Informazioni dettagliate ed una configurazione esempio dei permessi di accesso LDAP sono reperibili nella documentazione in linea del pacchetto installato openldap2 . Oltre alla possibilitàdi amministrare i controlli di accesso tramite il file di configurazione centrale del server (slapd.conf) vi è la possibilità di ricorrere alle ACI (ingl. Access Control Information ), per mezzo delle quali le informazioni di accesso per i singoli oggetti possono essere archiviate direttamente nell'albero LDAP. Dato che comunque questo modo di effettuare il controllo degli accessi non è molto diffuso e gli sviluppatori giudicano questa alternativa essere ancora nello stato sperimentale, rimandiamo alla relativa documentazione che trovate al sito dedicato al progetto OpenLDAP, ecco l'indirizzo: http://www.openldap.org/faq/data/cache/758.html.
Example 22.22. slapd.conf: direttive riguardanti la banca dati
database ldbm suffix "dc=suse,dc=de" rootdn "cn=admin,dc=suse,dc=de" # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw secret # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd/tools. Mode 700 recommended. directory /var/lib/ldap # Indices to maintain index objectClass eq
Nel primo rigo di questa sezione (si veda output Example 22.22, “slapd.conf: direttive riguardanti la banca dati”) viene stabilito il tipo di banca dati, nell'esempio LDBM. Tramite suffix nel secondo rigo viene stabilito per quale parte dell' albero di directory LDAP questo server debba essere quello di riferimento. Con rootdn si stabilisce chi dispone dell'accesso a scopo amministrativo per questo server. L'utente qui indicato non deve avere una registrazione LDAP o esistere come utente “normale”. Con la direttiva rootpw impostate la password dell'amministratore. Qui potete immettere al posto di secret anche il valore hash della password dell'amministratore generato con slappasswd . La direttiva directory indica la directory che contiene le directory della banca dati sul server. index objectClass eq determina che vi sia un indice delle classi di oggetto. Aggiungete eventualmente dei propri attributi che secondo la vostra esperienza sono quelli maggiormente richiesti. Se di seguito definite delle regole Access proprie per la banca dati, saranno queste ad essere applicate al posto delle regole Access globali.
Se il server LDAP è stato configurato e tutte le registrazioni desiderate sono state inserite nella directory LDAP secondo il modello riportato di seguito (si veda la sezione Section 22.9.4, “Gestione dei dati nella directory LDAP”), avviate il server LDAP come utente root immettendo il seguente comando:
rcldap start
Se volete fermare il server manualmente, immettete rcldap stop. Se volete conoscere lo stato di esecuzione del server LDAP, immettete rcldap status. Se volete lanciare e fermare il server all'avvio e allo spegnimento del relativo sistema, utilizzate l'editor dei runlevel di (si veda anche la sezione Section 10.6, “L'editor dei runlevel editor di YaST”) oppure create i relativi riferimenti dei script di avvio e di arresto sulla riga di comando tramite insserv (si veda la sezione Section 10.5.1, “Aggiungere script di inizializzazione”).
OpenLDAP offre all'amministratore una serie di programmi con i quali amministrare i dati nella directory LDAP. Ecco come aggiungere, cancellare, modificare dei dati oppure eseguire delle ricerche.
Se la configurazione del vostro server LDAP in /etc/openldap/slapd.conf è corretta, cioé contiene i valori adatti per suffix, directory , rootdn, rootpw ed index, potete iniziare con l'immissione dei dati. OpenLDAP utilizza a tal fine il comando ldapadd. Per motivi di praticità si consiglia di aggiungere gli oggetti alla banca dati possibilmente in gruppi. A tal fine LDAP supporta il cosiddetto formato LDIF (ingl. LDAP Data Interchange Format). Un file LDIF è un semplice file di testo che può contenere un numero qualsiasi di registrazioni composte da coppie di valori e attributi. Per vedere quali siano le classi di oggetto e gli attributi disponibili, consultate i file schema indicati in slapd.conf. Un semplice file LDIF adatto al nostro esempio (la figura Figure 22.21, “Struttura di una directory LDAP”) assumerebbe il seguente aspetto (si veda l'esempio Example 22.23, “Esempio di un file LDIF”):
Example 22.23. Esempio di un file LDIF
# SuSE dn: dc=suse,dc=de objectClass: dcObject objectClass: organization o: SuSE AG dc: suse # Dipartimento sviluppo (devel) dn: ou=devel,dc=suse,dc=de objectClass: organizationalUnit ou: devel # Dipartimento documentazione (doc) dn: ou=doc,dc=suse,dc=de objectClass: organizationalUnit ou: doc # Dipartimento IT interno (it) dn: ou=it,dc=suse,dc=de objectClass: organizationalUnit ou: it
![[Important]](admon/important.png) | Codifica dei file LDIF |
|---|---|
LDAP utilizza UTF-8 (Unicode). Gli accenti vanno quindi codificati correttamente. UTF-8 è il valore di default a partire da suselinux; 9.1 e viene supportato da tutti i comuni editor. Se avete impostato un encoding diverso per il vostro ambiente di lavoro (cfr. la sezione Section 9.4, “Adattamenti nazionali”), dovete rinunciare ai caratteri accentuati oppure utilizzare iconv per una ricodifica dei caratteri in UTF-8. | |
Salvate il file sotto <file>.ldif e passatelo al server con il seguente comando:
ldapadd -x -D <dn dell'amministratore> -W -f <file>.ldif
La prima opzione -x indica che in questo caso si rinuncia all'autenticazione tramite SASL. -D caratterizza l'utente che esegue questa operazione; indicate qui il DN valido dell'amministratore come configurato in slapd.conf. In questo esempio concreto si tratta di cn=admin,dc=suse,dc=de. Con -W eludete l'immissione della password sulla riga di comando (testo in chiaro) e attivate un richiesta di password a parte. La password relativa è stata impostata in precedenza in slapd.conf con rootpw. -f consegna questo file. Nell'esempio Example 22.24, “ldapadd di esempio.ldif” vedete in dettaglio il comando ldapadd.
Example 22.24. ldapadd di esempio.ldif
ldapadd -x -D cn=admin,dc=suse,dc=de -W -f esempio.ldif Enter LDAP password: adding new entry "dc=suse,dc=de" adding new entry "ou=devel,dc=suse,dc=de" adding new entry "ou=doc,dc=suse,dc=de" adding new entry "ou=it,dc=suse,dc=de"
I dati utenti dei singoli addetti possono venir raccolti in file LDIF distinti. Nel seguente esempio tux.ldif (si veda l'esempio Example 22.25, “File LDIF per Tux”) aggiungiamo l'addetto Tux alla nuova directory LDAP:
Example 22.25. File LDIF per Tux
# L'addetto Tux dn: cn=Tux Linux,ou=devel,dc=suse,dc=de objectClass: inetOrgPerson cn: Tux Linux givenName: Tux mail: tux@suse.it uid: tux telephoneNumber: +39 1234 567-8
Un file LDIF può contenere un numero qualsiasi di oggetti. Potete consegnare al server interi alberi di directory o anche solo parti di esso come ad esempio singoli oggetti. Se dovete modificare relativamente di frequente i vostri dati, si consiglia di suddividerli in tanti oggetti, in modo da risparmiarvi la ricerca laboriosa degli oggetti da modificare in file voluminosi.
Se dovete modificare dei dati potete utilizzare il tool ldapmodify. Il modo più semplice consiste nel modificare prima il relativo file LDIF e di riconsegnare in seguito il file modificato al server LDAP. Per modificare ad esempio il numero telefonico dell'addetto Tux da +39 1234 567-8 a +39 1234 567-10, editate il file LDIF come mostrato nell' esempio Example 22.26, “File LDIF modificato: tux.ldif”.
Example 22.26. File LDIF modificato: tux.ldif
# L'addetto Tux dn: cn=Tux Linux,ou=devel,dc=suse,dc=de changetype: modify replace: telephoneNumber telephoneNumber: +39 1234 567-10
A questo punto importate i dati modificati nella directory LDAP con il seguente comando:
ldapmodify -x -D cn=admin,dc=suse,dc=de -W -f tux.ldif
Oppure consegnate a ldapmodify gli attributi da modificare direttamente sulla riga di comando, procedendo nel modo seguente:
Lanciate ldapmodify ed immettete la vostra password:
ldapmodify -x -D cn=admin,dc=suse,dc=de -W Enter LDAP password:
Immettete le vostre modifiche rispettando esattamente questa sintassi:
dn: cn=Tux Linux,ou=devel,dc=suse,dc=de changetype: modify replace: telephoneNumber telephoneNumber: +39 1234 567-10
Leggete la pagina di manuale di ldapmodify per avere delle informazioni dettagliate su ldapmodify e la sua sintassi.
OpenLDAP offre con ldapsearch un tool per la riga di comando per rilevare e leggere dei dati nella directory LDAP. Un comando di ricerca semplice presenta la seguente sintassi:
ldapsearch -x -b dc=suse,dc=de "(objectClass=*)"
L'opzione -b definisce la base di ricerca, cioé il settore dell'albero della directory in cui eseguire la ricerca. Nel nostro esempio dc=suse,dc=de. Se volete eseguire una ricerca più mirata in alcuni sottosettori della directory LDAP (p.es. solo nella unità di organizzazione devel), consegnate questo settore tramite -b a ldapsearch. -x stabilisce l' utilizzo dell' autenticazione semplice. Con (objectClass=*) stabilite che devono essere letti tutti gli oggetti contenuti nella vostra directory. Utilizzate questo comando dopo aver generato un nuovo albero di directory per vedere se le vostre registrazioni sono state assunte correttamente e se il server risponde nel modo desiderato. Per ulteriori informazioni su ldapsearch rimandiamo alla relativa pagina di manuale (man ldapsearch).
vi consente di amministrare gli utenti tramite LDAP. Per realizzare ciò, se non è stato già impostato in fase di installazione, invocate il modulo +. installerà e configurerà automaticamente le modifiche LDAP descritte di seguito per PAM e NSS.
Per comprendere meglio il funzionamento del modulo client LDAP di dovreste conoscere un po' i processi che si svolgono 'dietro le quinte' sul client. Innazitutto, non appena abilitate durante l'installazione LDAP per l'autenticazione di rete oppure lanciate il modulo , vengono installati i pacchetti pam_ldap ed nss_ldap, e adattati i corrispondenti file di configurazione. Con pam_ldap viene utilizzato il modulo PAM preposto alla comunicazione tra processi di login e directory LDAP quale fonte dei dati di autenticazione. Viene installato il relativo modulo di software pam_ldap.so e adattata la configurazione PAM (si veda l'esempio Example 22.27, “pam_unix2.conf adattato per LDAP”).
Example 22.27. pam_unix2.conf adattato per LDAP
auth: use_ldap nullok account: use_ldap password: use_ldap nullok session: none
Se volete configurare manualmente ulteriori servizi LDAP, il modulo LDAP-PAM deve essere inserito nel file di configurazione PAM corrispondente al servizio che trovate sotto /etc/pam.d/ . File di configurazione già adattati per i singoli servizi si trovano sotto /usr/share/doc/packages/pam_ldap/pam.d/ . Copiate i file corrispondenti sotto /etc/pam.d/ .
Tramite nss_ldap adattate la risoluzione dei nomi di glibc, per via del meccanismo nsswitch, all'utilizzo di LDAP. Dopo aver installato questo pacchetto sotto /etc/ troverete un nuovo file adattato nsswitch.conf. Per sapere di più sul funzionamento di nsswitch.conf andate alla sezione Section 22.3.1, “File di configurazione”. Per l'amministrazione degli utenti ovvero l'autenticazione tramite LDAP, il vostro nsswitch.conf deve contenere le seguenti righe (cfr. esempio Example 22.28, “Adattamenti in nsswitch.conf”):
Example 22.28. Adattamenti in nsswitch.conf
passwd: compat group: compat passwd_compat: ldap group_compat: ldap
Queste righe istruiscono la libreria resolver di glibc , ad analizzare, quale fonte per i dati di autenticazione e dati utenti, innanzitutto i file corrispondenti locali del sistema sotto /etc e di accedere inoltre al server LDAP. Testate questo meccanismo facendovi mostrare tramite il comando getent passwd il contenuto della banca dati degli utenti. Nell'elenco dovrebbero comparire sia gli utenti locali del vostro sistema che tutti gli utenti del server LDAP.
Se non volete che sia consentito agli utenti amministrati tramite LDAP di eseguire il login sul server tramite ssh o login dovete aggiungere un rigo a /etc/passwd /etc/group un rigo. Nel caso di /etc/passwd si ha +::::::/sbin/nologin e per /etc/group +::: .
Dopo che nss_ldap e pam_ldap sono stati adattati da potete iniziare nel primo dialogo di con la configurazione vera e propria.
Nel primo dialogo ( si veda la figura Figure 22.22, “: configurazione del client LDAP”) abilitate attraverso il radio bottone l'utilizzo di LDAP per l'autenticazione degli utenti e sotto immettete la base di ricerca sul server, al di sotto della quale si trovano tutti i dati sul server LDAP. Nel secondo campo di immissione immettete l'indirizzo del server LDAP. Se il vostro server supporta TLS/SSL, marcate la voce , per consentire una comunicazione cifrata tra client e server. Se volete montare directory remote nel vostro file system abilitate la check box . Se come amministratore volete modificare attivamente dei dati sul server, fate clic su .
Il prossimo dialogo è suddiviso in due parti: nella parte superiore potete eseguire delle impostazioni generali riguardanti utenti e gruppi che determina il comportamento del modulo degli utenti di Nella parte inferiore inserite i dati di accesso per il server LDAP. Le impostazioni riguardanti utenti e gruppi si limitano alle seguenti voci:
Il sistema funge da file server e amministra le directory /home degli utenti? Attivando la check box, fornirà delle indicazioni del modulo utente per stabilire come maneggiare le directory degli utenti residenti sul sistema.
Abilitate questa check box per consentire agli utenti amministrati tramite LDAP di effettuare il login al sistema.
Determinate il tipo di gruppi LDAP da utilizzare. Avete la scelta tra: (impostazione di default) e .
| Utilizzare client YaST |
|---|---|
Il modulo di Client LDAP viene utilizzato per adattare i moduli per l'amministrazione di utenti e gruppi, ed eventualmente estenderli. Inoltre avete la possibilità di definire dei template con dei valori di default per i singoli attributi per semplificare il rilevamento dei dati. I valori qui impostati vengono archiviati nella directory LDAP sotto forma di oggetti LDAP. I dati utenti vanno inseriti tramite il modulo apposito di . Le informazioni vengono archiviate sotto forma di oggetti nella directory LDAP. | |
Per modificare la configurazione del server LDAP immettete in questo dialogo i dati di accesso richiesti (si veda figura Figure 22.23, “: configurazione avanzata”). Si tratta dei , al di sotto dei quali si trovano tutti gli oggetti di configurazione, e . Per intervenire sulle registrazioni del server LDAP, fate clic su . Compare una finestra in cui immettere la password LDAP per autenticarsi sul server. In base alle ACL o ACI del server vi sarà concesso l'accesso ai moduli di configurazione sul server.
Nel dialogo per la configurazione del modulo avete la possibilità di selezionare e modificare moduli di configurazione esistenti, crearne dei nuovi o creare e modificare dei template per questi moduli (si veda la figura Figure 22.24, “: configurazione del modulo”. Per modificare il valore all'interno di un modulo di configurazione o per cambiar nome ad un modulo, selezionate il tipo di modulo tramite il combo box sopra la rassegna del contenuto del modulo attuale. Nella rassegna vi è solo un elenco tabellare degli attributi consentiti in questo modulo e dei valori allocati. Qui trovate accanto agli attributi impostati anche altri attributi permessi per via dello schema utilizzato ma attualmente non utilizzati. Se intendete copiare il modulo, modificate semplicemente cn. Per modificare i singoli valori degli attributi, selezionateli nella rassegna dei contenuti e cliccate su . Si apre una finestra dialogo dove potete modificare le impostazioni dell'attributo. Con rendete effettive le vostre modifiche.
Se volete aggiungere ai moduli uno nuovo, fate clic su al di sopra della rassegna dei contenuti. Nel dialogo che appare immettete la classe di oggetto del nuovo modulo (nel nostro caso suseuserconfiguration o susegroupconfiguration) ed il nome del nuovo modulo. Se uscite dal dialogo con , il nuovo modulo viene inserito nella lista di selezione dei moduli esistenti e potrà essere selezionato e deselezionato tramite il combo box. Se volete cancellare il modulo attualmente selezionato, fate clic su .
I moduli per l'amministrazione di gruppi ed utenti integrano template con valori di default sensati se li avete definiti in precedenza tramite il client LDAP di . Per editare dei template fate clic su . Verranno visualizzati nel menu a tendina template già esistenti che possono essere modificati o una registrazione vuota che vi porta comunque alla maschera per editare i template. Selezionatene uno ed impostate le caratteristiche del template nel seguente dialogo . Questo dialogo si compone di due finestre con sommari tabellari. Nella finestra superiore sono elencati gli attributi di template generali. Stabilitene i valori secondo il vostro scenario di impiego oppure lasciatene dei vuoti. Attributi “vuoti” vengono cancellati sul server LDAP.
Sotto () vedete gli attributi del relativo oggetto LDAP (qui: configurazione dei gruppi e utenti), per i quali definite un valore di default. Potete aggiungere ulteriori attributi con valori di default, modificare coppie di attributi - valore e cancellare attributi interi. In egual maniera potete copiare un template modificando la registrazione cn per creare un nuovo template. Collegate il template con il relativo modulo impostando come descritto sopra il valore di attributo susedefaulttemplate del modulo sul DN del template adattato.
| Tip |
|---|---|
Potete generare dei valori di default per un attributo da altri attributi utilizzando delle variabili al posto di valori assoluti. Esempio: cn=%sn %givenName verrà generato automaticamente dai valori di attributo di sn e givenName. | |
Una volta configurati correttamente i moduli ed i template, con potete creare nuovi gruppi ed utenti.
Dopo aver configurato i moduli e template per la rete, vi accorgerete che il rilevamento dei dati degli utenti e dei gruppi si discosta solo minimamente dalla procedura da seguire senza l'utilizzo di LDAP. Illustreremo di seguito brevemente l'amministrazione degli utenti, la procedura di amministrazione dei gruppi è analoga.
Il modulo di amministrazione degli utenti di si trova sotto +. Se volete aggiungere un nuovo utente, fate clic su . Si apre una maschera dove potete immettere i principali dati dell'utente come il nome, login e password. Dopo aver inserito i dati premendo il bottone potrete configurare in modo più mirato l'appartenenza al gruppo, shell di login e directory home. I valori di default per i campi di immissione sono stati stabiliti in base alla procedura descritta nella sezione Section 22.9.5.2, “Configurazione del client LDAP”. Se avete abilitato l' uso di LDAP si apre una seconda maschera per l'immissione degli attributi di LDAP (si veda figura Figure 22.27, “: impostazioni LDAP aggiuntive”). Selezionate gli attributi di cui intendete modificare i relativi valori e cliccate su per aprire la finestra di immissione relativa. Con uscite dalla maschera e ritornate alla maschera iniziale per l'amministrazione degli utenti.
Dalla maschera iniziale dell'amministrazione degli utenti (si veda figura Figure 22.26, “: amministrazione utente”) il bottone vi dà la possibilità di applicare un filtro di ricerca LDAP agli utenti presenti o di configurare il client LDAP di tramite .
Temi più complessi come la configurazione SASL o l'impostazione di un server LDAP replicante, che si divide il lavoro con “slaves” sono stati esclusi da questo capitolo. Per avere delle informazioni dettagliate su questi temi consultate l'OpenLDAP 2.2 Administrator's Guide (per i link si veda sotto).
Sul sito web del progetto OpenLDAP trovate della documentazione dettagliata per utenti LDAP principianti ed esperti:
Le FAQ in tema di installazione, configurazione ed utilizzo di OpenLDAP: http://www.openldap.org/faq/data/cache/1.html
Una breve guida per configurare un proprio server LDAP: http://www.openldap.org/doc/admin22/quickstart.html o a sistema installato reperibile sotto /usr/share/doc/packages/openldap2/admin-guide/quickstart.html
Una introduzione dettagliata per tutti i principali ambiti della configurazione LDAP incl. il controllo degli accessi e cifratura: http://www.openldap.org/doc/admin22/ o a sistema installato sotto /usr/share/doc/packages/openldap2 /admin-guide/quickstart.html
Inoltre vi sono i seguenti Redbooks della IBM dedicati al tema LDAP:
Una introduzione dettagliata e generale ai principi di base di LDAP: http://www.redbooks.ibm.com/redbooks/pdfs/sg244986.pdf
Si rivolge in particolar modo agli amministratori di IBM SecureWay Directory. Vi trovate anche importanti informazioni generali su LDAP: http://www.redbooks.ibm.com/redbooks/pdfs/sg245110.pdf
Manuali in inglese su LDAP:
Howes, Smith & Good: Understanding and Deploying LDAP Directory Services. Addison-Wesley, 2. Edizione., 2003. - (ISBN 0-672-32316-8)
Hodges: LDAP System Administration. O'Reilly & Associates, 2003. - (ISBN 1-56592-491-6)
Chiaramente da non dimenticare in tema di LDAP i relativi RFC (ingl.Request for comments) 2251- 2256.
