Figura 9.5.
|
|
[successivo] [precedente] [inizio] [fine] [indice generale]
In questo capitolo viene esaminata la possibilità di utilizzare Samba come PDC con gli utenti della rete memorizzati in un archivio gestito da OpenLDAP (1) (<http://www.openldap.org>).
Uno dei principali vantaggi di una soluzione di questo genere è che anche eventuali macchine clienti GNU/Linux possono far accreditare gli utenti servendosi dello stesso archivio; è così possibile una gestione completamente centralizzata e uniforme degli utenti in una rete eterogenea.
Prima di entrare nei dettagli vengono presi in esame la natura del servizio LDAP e la sua installazione e configurazione indipendentemente da Samba.
LDAP (Lightweight directory access protocol) è un protocollo di tipo cliente/servente proposto nel 1995 dall'università del Michigan allo scopo di accedere alle «directory» o «elenchi» in rete.
|
Da qui in poi si fa uso del termine «elenchi», anche se è sicuramente meno usato, soprattutto per evitare possibili confusioni con l'altro significato che il termine «directory» ha relativamente alla organizzazione logica dei dati sulle memorie di massa. |
Nella descrizione dell'acronimo LDAP si nota che è presente il termine «lightweight» che fa pensare a qualcosa di poco pesante; il motivo è che questo protocollo si pone come un'alternativa semplificata al preesistente protocollo ISO/OSI (International organization for standardization/Open systems interconnection) X.500 definito per la gestione degli elenchi in rete e noto anche come protocollo DAP.
I vantaggi di LDAP rispetto a X.500 sono fondamentalmente i seguenti:
X.500 non è compatibile con Internet, LDAP invece si perché usa TCP/IP;
X.500 è molto più complesso rispetto a LDAP;
LDAP è comunque compatibile con gli elenchi definite secondo le specifiche X.500.
Esistono vari servizi di elenchi in rete proprietari come ad esempio Oracle Internet Directory o Microsoft Active Directory ma è possibile realizzarli anche in modo completamente libero grazie al software OpenLDAP del quale si occupano queste dispense.
Un elenco è un catalogo di informazioni anche eterogenee organizzate in una struttura gerarchica; secondo la terminologia ufficiale si parla di un DIT (Directory information tree) che contiene vari nodi (objectclass) ognuno dei quali ha una serie di attributi obbligatori o facoltativi che forniscono informazioni sul nodo.
La struttura gerarchica di un elenco può essere rappresentata come un albero capovolto, con la radice in alto; in un elenco possono comunque essere presenti più alberi (cataloghi diversi).
Ogni nodo di un albero può avere un solo genitore e un numero variabile di figli.
Per ogni elenco deve essere definito uno schema cioè l'insieme degli attributi possibili dei nodi, della loro sintassi e dei tipi di oggetti presenti.
In base a questa prima descrizione si può pensare di confrontare un elenco con una base di dati in quanto in entrambi i casi si tratta di insiemi strutturati di dati; esistono però delle differenze che sono di fondamentale importanza:
i servizi di elenchi sono ottimizzati per il solo reperimento di informazioni e quindi adatti solamente nel caso di archivi molto statici, questo ovviamente non è vero per le basi di dati;
negli elenchi è generalmente possibile immagazzinare informazioni in modo più descrittivo rispetto alle basi di dati;
negli elenchi le informazioni possono essere agevolmente separate in alberi distinti, anche residenti su serventi diversi, così da avere, in modo semplice, distribuzione dei dati;
in modo altrettanto semplice è possibile replicare i dati di un elenco su più serventi così da avere ridondanza;
negli elenchi sono ammesse temporanee inconsistenze sui dati (dovute ad esempio ad aggiornamenti non istantanei tra serventi diversi), cosa non possibile in qualsiasi base di dati;
per gli elenchi non esiste o non è importante il concetto di transazione (o di operazione «atomica»), visto anche che gli accessi ai dati sono quasi esclusivamente in lettura;
per l'accesso ai dati di un elenco non è necessario usare un linguaggio strutturato come SQL (Structured data language) ma è sufficiente rispettare le regole semplificate definite dal protocollo LDAP.
Uno degli utilizzi più interessanti di LDAP è la gestione centralizzata degli utenti di una rete in ambiente GNU/Linux, compito per il quale può validamente sostituire il vecchio servizio NIS (Network information service).
Rispetto al NIS infatti LDAP ha una importante serie di vantaggi:
LDAP può funzionare «a cavallo» di due reti, NIS no;
LDAP, a differenza di NIS, è adatto anche in presenza di una mole considerevole di utenti;
con NIS le informazioni circolano sempre in chiaro, con LDAP non necessariamente in quanto è possibile usare strumenti come TSL/SSL per avere trasmissione cifrata dei dati, autenticazione dei nodi di rete, verifica di integrità dei dati;
le informazioni gestite in un elenco LDAP possono essere usate anche per altri scopi oltre che per l'autenticazione degli utenti (ad esempio per un indirizzario di posta elettronica), con NIS questo non è possibile;
con LDAP si possono concentrare in un unico archivio: gli utenti della rete su clienti GNU/Linux e quelli di un PDC Samba e quindi anche dei clienti MS-Windows; con NIS questo non è possibile: si hanno utenti GNU/Linux e utenti MS-Windows su due archivi separati con necessità di mantenere l'allineamento (cosa non banale da realizzare).
Prima di illustrare l'installazione e la configurazione di OpenLDAP è opportuno soffermarsi sulla progettazione dell'elenco delle informazioni da gestire.
Gli oggetti presenti in un elenco che sono «foglie» di un albero, cioà nodi terminali, senza figli, sono raggiungibili grazie ad un identificatore univoco chiamato DN (Distingueshed name) che ha un aspetto simile al seguente:
uid=rossimario,ou=People,dc=max,dc=planck |
Leggendo il DN da sinistra a destra si ottiene il percorso per risalire dalla foglia alla radice dell'albero; in senso inverso si ottiene la scala gerarchica dei nodi presenti.
Nell'esempio abbiamo due dc (Domain component) con valori rispettivamente max e planck che rappresentano il suffisso (o radice) dell'albero delle informazioni; seguono poi ou (Organizational unit) con valore People e uid (User id) con valore rossimario.
In pratica vuol dire che nell'elenco esiste un nodo identificato dall'uid rossimario, appartenente al gruppo o settore delle persone, all'interno dell'organizzazione identificata dal suffisso max.planck.
Naturalmente non è detto che tutti i DN siano definiti con le stesse componenti in quanto dipendono dal tipo di nodo cui si riferiscono; sicuramente avranno questa struttura i DN relativi a oggetti di tipo People.
|
I valori degli attributi degli oggetti di un elenco non sono case sensitive. |
Esiste anche un altro tipo di identificatore chiamato RDN (Relative distingueshed name) che può essere associato a qualsiasi nodo ma che non costituisce il percorso completo per reperirlo; esempi possono essere:
uid=rossimario ou=People |
La decisione su quale sia la radice dell'albero delle informazioni è ovviamente molto importante e deve essere presa con attenzione; esistono due metodi che solitamente vengono usati nella definizione degli elenchi in rete:
suffisso che identifica una organizzazione (azienda, scuola o altro) definito partendo da un nome di dominio; nell'esempio è stato scelto questo metodo usando un dominio privato, cioè non presente in Internet;
suffisso definito con un criterio geografico come nell'esempio che segue.
ou=finance,o=Government,st=Minnesota,c=US |
In questo caso abbiamo un nodo che potrebbe essere relativo al settore finanze della organizzazione Govern dello stato Minnesota negli Stati Uniti.
Il primo metodo è comunque solitamente preferito e viene utilizzato anche nel proseguo di queste dispense mantenendo il nome max.planck.
Come detto in precedenza ogni oggetto dell'elenco ha una serie di attributi grazie ai quali si rendono disponibili le informazioni relative a quell'oggetto.
Facendo di nuovo riferimento all'esempio di un oggetto di tipo People potremmo avere degli attributi come:
cn=Rossi Mario mail=rossimario@max.planck |
dove cn significa Common name.
Per sapere quali sono i tipi di oggetti presenti in un elenco e quali sono i relativi attributi si deve conoscere quale è lo schema dell'elenco.
Per fortuna non è quasi mai necessario definire gli schemi degli elenchi da parte dell'amministratore degli stessi, in quanto nel pacchetto OpenLDAP sono già inseriti degli schemi precompilati che sono sufficienti per tutti i tipi più comuni di elenchi in rete.
In questo paragrafo vediamo come installare, configurare e usare OpenLDAP versione 2.3 per la gestione degli utenti, facendo riferimento a distribuzioni Deian o derivate come Ubuntu.
Non vengono prese in considerazione alcune funzionalità come la replica dell'archivio su serventi diversi.
Per l'installazione dei pacchetti si può utilizzare uno degli strumenti tipici dell'ambiente Debian come apt-get da linea di comando o synaptic dalla grafica; qui non vengono forniti dettagli sull'utilizzo di questi strumenti per i quali si rimanda alle numerose fonti disponibili in Internet.
I pacchetti da installare sono:
slapd_x.y.z.deb
libldap2_x.y.z.deb
ldap-utils_x.y.z.deb
Il pacchetto slapd contiene il servente OpenLDAP e deve essere installato soltanto nella macchina servente.
Gli altri due pacchetti, che contengono rispettivamente le librerie per l'accesso agli elenchi e alcuni programmi di utilità per la gestione degli stessi, devono essere invece installati sia nel servente che nei clienti.
Nel pacchetto slapd è presente anche il demone slurpd che serve a gestire le repliche dell'archivio OpenLDAP tra serventi diversi e che qui, come detto, non usiamo.
Altri pacchetti da usare per sfruttare i servizi offerti da OpenLDAP; vengono qui solo elencati in attesa di esaminare i dettagli al momento opportuno:
migrationtools_x.y.z.deb
contiene dei programmi scritti in Perl per la migrazione delle informazioni (utenti, gruppi ecc.) dagli archivi GNU/Linux (file passwd, group ecc.) all'elenco OpenLDAP;
smbldap-tools_x.y.z.deb
contiene i programmi scritti in Perl per la gestione degli utenti Samba in OpenLDAP;
libnss-ldap_x.y.z.deb
libpam-ldap_x.y.z.deb
usati per permettere l'accreditamento nel sistema GNU/Linux agli utenti gestiti con OpenLDAP;
samba-doc_x.y.z.deb
nscd_x.y.z.deb
per il caching delle informazioni riguardanti l'accreditamento degli utenti (permette di migliorare le prestazioni di servizi «lenti» cone NIS e OpenLDAP.
Siccome alcuni dei pacchetti citati comprendono programmi scritti in Perl, è necessario che quest'ultimo sia installato nella macchina che stiamo utilizzando.
Durante l'installazione del pacchetto slapd si riceve solamente la richiesta della parola d'ordine dell'amministratore del servizio; ci sono però alcune altre informazioni importanti da inserire e per fare questo esistono due alternative:
intervenire direttamente nel file di configurazione /etc/ldap/slapd.conf;
eseguire il comando:
# dpkg-reconfigure slapd
Iniziamo dalla seconda alternativa che è la più semplice.
Dopo avere risposto negativamente alla domanda «Omit OpenLDAP server configuration?», si riceve la richiesta del nome di dominio che serve a creare la radice del nostro albero di informazioni; inseriamo max.planck (figura 9.5).
|
Figura 9.5.
|
Vengono poi richiesti il nome dell'organizzazione (che possiamo porre uguale al dominio) e la parola d'ordine per l'amministratore con relativa conferma.
La schermata successiva (preceduta da una nota esplicativa) richiede il tipo di base dati utilizzato da OpenLDAP; è bene scegliere BDB (Berkeley database backend) che ha ormai sostituito GDBM (Gnu database manager) presente nelle versioni precedenti di OpenLDAP (figura 9.6).
|
Figura 9.6.
|
Dopo avere risposto (si consiglia negativamente) alla domanda circa la cancellazione dell'archivio in caso di eliminazione del pacchetto slapd e alla eventuale domanda sulla rimozione di vecchi file prima della creazione del nuovo archivio, si arriva alla schermata che chiede se si vuole attivare il supporto al vecchio protocollo LDAPv2 (la versione attuale è la 3); si può rispondere negativamente a meno che non si abbiano programmi che lo utilizzano; questo conclude la configurazione.
Intervenire nel file di configurazione /etc/ldap/slapd.conf è più scomodo ma è comunque importante soffermarsi brevemente sul suo contenuto:
|
La numerazione delle righe ovviamente non è presente nel file, è stata aggiunta per poter fare riferimento, in modo più preciso, alle righe di maggiore interesse.
Il file contiene righe di commento che, come al solito, iniziano con «#» ed è suddiviso in tre sezioni:
direttive globali;
specifiche del backend
specifiche della base di dati.
Le opzioni presenti in una sezione possono sovrascrivere quelle presenti in una sezione precedente.
Nella sezione delle direttive globali vediamo la riga 8 che, se non commentata, permette di avere il supporto per il vecchio protocollo LDAPv2; a seguire una serie di righe (dalla 11 alla 14) che permettono di includere nella definizione del nostro elenco alcuni schemi già pronti.
Questi schemi dovrebbero essere sufficienti per l'uso che vogliamo fare di OpenLDAP (a parte lo schema per Samba che vediamo più avanti).
Nel caso fosse necessario utilizzare ulteriori schemi, anche di nostra produzione, basta aggiungere la relativa riga include nel file di configurazione e il file contenente le specifiche dello schema nella directory /etc/apt/schema.
A titolo di esempio viene mostrata una porzione del file /etc/ldap/schema/core.schema riguardante gli attributi uid e mail:
|
Riguardo le altre direttive globali ci soffermiamo solo sul livello di log a riga 29 (le altre dovrebbero essere abbastanza chiare ed in ogni caso si può fare riferimento ai commenti nel file e al manuale in linea di slapd.conf).
I valori possibili del livello di log sono -1, 0 o potenze del due; di seguito viene riportata la tabella dei valori che si trova nel manuale in linea di slapd.conf:
|
Il valore inserito può essere tale da attivare più opzioni di log; ad esempio se si sceglie 255 si attivano le opzioni corrispondenti ai livelli 1, 2, 4, 8, 16, 32, 64, 128.
Nella sezione delle specifiche del backend notiamo che, alla riga 45, è indicata BDB come base di dati (in conseguenza della scelta fatta precedentemente in sede di configurazione); notiamo inoltre che sarebbe possibile avere più di un backend (righe commentate da 49 a 52).
Molto più corposa è la sezione delle specifiche della base di dati, all'interno della quale notiamo subito come sia possibile gestire più basi di dati o alberi con un solo servente OpenLDAP (righe commentate da 125 a 131).
Nel nostro esempio è sufficiente gestire un solo albero e le relative direttive sono comprese tra riga 55 e riga 123.
Una delle più importanti è naturalmente l'indicazione della radice (o suffisso) a riga 61; anche in questo caso il valore corrisponde a quanto indicato al momento della configurazione del pacchetto slapd.
Alla riga 64 viene indicato dove risiede fisicamente l'archivio; seguono direttive sulla memoria cache il bloccaggio degli oggetti, l'indicizzazione dell'archivio, che qui non vengono approfondite.
Nell'ultima parte della sezione ci sono le direttive per le access list che servono a indicare chi può accedere all'elenco e quali operazioni può fare.
Nello specifico: con le righe da 95 a 99 si indica che l'utente amministratore può cambiare le parole d'ordine di tutti, che ognuno può cambiare la propria, che gli altri non possono né leggere né scrivere la parola d'ordine di qualcuno.
La seconda direttiva access di riga 110, è presente per evitare malfunzionamenti se si utilizza il meccanismo di autenticazione SASL (Simple authentication and security layer); nel nostro caso non servirebbe.
Con la terza (righe da 114 a 116) si stabilisce che l'amministratore può accedere in lettura e scrittura a qualsiasi oggetto, tutti gli altri utenti invece solo in lettura.
Prima di concludere la configurazione del servente, è opportuno definire i diritti di accesso di un altro utente, diverso dall'amministratore, da usare per la consultazione dell'elenco in sede di accreditamento.
A questo utente viene concesso solo il diritto di leggere le informazioni relative alle parole d'ordine (cosa sufficiente per le operazioni di accreditamento).
Un'altra possibilità sarebbe quella di accedere all'elenco come amministratore ma qui non viene presa in considerazione.
Entrambe le scelte hano infatti un «difetto»:
accedendo come utente «normale» si rende impossibile la modifica delle parole d'ordine degli utenti da parte dell'utente root lavorando dai clienti della rete;
d'altra parte l'accesso come amministratore comporta la necessità di scrivere in chiaro in alcuni file di configurazione sui client (vedi paragrafo 9.3) la parola d'ordine di tale utente; tali file saranno ovviamente leggibili solo da root ma la possibilità che tale utenza, per un cliente della rete, venga compromessa è comunque non trascurabile e comporta il rischio che la parola d'ordine dell'amministratore di OpenLDAP cada nelle mani di qualche malintenzionato.
Per motivi di sicurezza è da ritenere preferibile la prima alternativa.
La riga da aggiungere in /etc/ldap/slapd.conf (fra le righe 96 e 97 già presenti) è la seguente:
by dn="cn=auth,dc=max,dc=planck" read |
avendo evidentemente scelto auth come nome dell'utente da usare per la consultazione dell'elenco.
Per avviare o riavviare il demone di OpenLDAP, nella Debian o simili, si esegue:
# /etc/init.d/slapd start
oppure:
# /etc/init.d/slapd restart
Per fermarlo si esegue:
# /etc/init.d/slapd stop
Il servizio risponde sulla porta 389 (valore che può essere cambiato intervenendo nel file di configurazione).
Naturalmente è consigliabile fare in modo che il demone slapd sia inserito fra quelli che vengono attivati automaticamente all'attivazione della macchina.
Di solito a questo provvedono gli script di installazione del pacchetto; se ciò non avviene si può ovviare creando un collegamento simbolico nella directory /etc/rc2.d allo script di attivazione del demone con il comando:
# ln -s /etc/init.d/slapd /etc/rc2.d/S19slapd
Si presti attenzione al fatto che questo procedimento è valido solo per Debian e distribuzioni derivate, in altri casi varia leggermente.
Una volta attivato il servizio possiamo iniziare a interrogarlo anche se non possiamo aspettarci di ottenere molte informazioni, visto che l'elenco non è stato ancora «popolato».
Ecco infatti cosa si ottiene eseguendo il comando:
# slapcat
che fa parte del pacchetto slapd e ha lo scopo di elencare tutti gli oggetti presenti in archivio:
dn: dc=max,dc=planck objectClass: top objectClass: dcObject objectClass: organization o: max.planck dc: max structuralObjectClass: organization entryUUID: 9d3d2042-bfbf-102a-974f-5dcf1676f01f creatorsName: modifiersName: createTimestamp: 20060814090419Z modifyTimestamp: 20060814090419Z entryCSN: 20060814090419Z#000000#00#000000 dn: cn=admin,dc=max,dc=planck objectClass: simpleSecurityObject objectClass: organizationalRole cn: admin description: LDAP administrator userPassword:: e2NyeXB0fTR2R2c4ODNKQi9zVHc= structuralObjectClass: organizationalRole entryUUID: 9d3d7164-bfbf-102a-9750-5dcf1676f01f creatorsName: modifiersName: createTimestamp: 20060814090419Z modifyTimestamp: 20060814090419Z entryCSN: 20060814090419Z#000001#00#000000 |
Sono presenti solo due oggetti: la radice e l'utente amministratore.
Per inserire i dati all'interno dell'elenco e per poi poterli gestire si utilizzano una serie di programmi presenti nei pacchetti slapd e ldap-utils.
I primi sono eseguibili solo dall'utente root e il loro nome inizia con «slap»; gli altri sono eseguibili da tutti gli utenti e il loro nome inizia con «ldap».
Quello che segue è un elenco dei più importanti tra questi programmi.
Di quelli che utilizziamo per caricare e gestire il nostro elenco viene dato tra breve qualche dettaglio di utilizzo; per una panoramica più completa si rimanda, come sempre, ai relativi manuali in linea:
ldapadd: per inserire oggetti nell'elenco;
ldapdelete: per cancellare oggetti dall'elenco;
ldapmodify: per modificare oggetti dell'elenco;
ldapsearch: per cercare dati all'interno dell'elenco e visualizzarli;
slapacl: per verificare i permessi di accesso agli oggetti;
slapadd: per inserire ogetti nell'elenco;
slapcat: per visualizzare il contenuto di tutto l'archivio;
slapdn: per controllare che una certa stringa, passata come parametro, sia un DN valido per il nostro elenco;
slapindex: per generare o rigenerare gli indici dell'archivio;
slappasswd: per generare parole d'ordine cifrate da inserire in archivio (ad esempio con ldapmodify);
slaptest: per controllare che il contenuto di slapd.conf sia corretto.
Per inserire i dati nell'elenco si utilizzano file scritti in uno speciale formato chiamato LDIF (Lightweight directory interchange format).
Questo formato permette di descrivere gli oggetti dell'elenco e rende possibile il caricamento e lo scaricamento degli stessi in OpenLDAP.
Il formato LDIF è semplicemente un testo con una serie di coppie attributo/valore come nell'esempio che segue relativo ad un ipotetico oggetto «utente GNU/Linux»:
|
Prima di tutto dobbiamo inserire nell'elenco l'utente auth da utilizzare per la consultazione dei dati in sede di accreditamento degli utenti della rete, come spiegato alla fine del paragrafo 9.2.2.
Per questo prepariamo un file auth.ldif come il seguente:
|
La parola d'ordine può essere ottenuta con il comando:
# slappasswd -h {crypt}
e poi incollata nel file.
Quindi fermiamo il servizio OpenLDAP:
# /etc/init.d/slapd stop
e inseriamo poi l'utente eseguendo:
# slapadd -l auth.ldif
In teoria per inserire tutti i dati nell'elenco si dovrebbe operare in modo simile:
creare uno o più file in formato LDIF (e solitamente con estensione «ldif») contenenti gli oggetti (anche più oggetti per file) da inserire;
eseguire più volte il comando:
# slapadd -l nome_file.ldif
passando ogni volta uno dei file ldif creati (l'opzione -l indica al programma di leggere l'input dal file invece che dallo standard input).
Anche se tecnicamente fattibile, questo procedimento sarebbe senza dubbio lungo e noioso; ecco quindi che sono stati creati degli strumenti automatici di migrazione scritti in Perl che permettono di ottenere automaticamente i file LDIF relativi a molti degli archivi gestiti in un sistema GNU/Linux come ad esempio gli utenti e i gruppi (attingendo i dati dai file /etc/passwd, /etc/shadow, /etc/group).
Questi strumenti si trovano nel pacchetto migrationtools che è stato già citato come molto utile e quindi senz'altro da installare.
In particolare usiamo (nell'ordine in cui sono elencati):
migrate_common.ph: per le impostazioni di base della migrazione;
migrate_base.pl: per la definizione degli oggetti di base dell'elenco;
migrate_passwd.pl: per la migrazione degli utenti;
migrate_group.pl: per la migrazione dei gruppi.
Per usare questi strumenti posizioniamoci nella directory /usr/share/migrationtools/ e modifichiamo il file migrate_common.ph in modo le righe riguardanti il nome del dominio e del suffisso assumano il seguente aspetto:
|
Procediamo poi alla creazione dei file LDIF eseguendo:
# ./migrate_base.pl >base.ldif
# ./migrate_passwd.pl /etc/passwd >utenti.ldif
# ./migrate_group.pl /etc/group >gruppi.ldif
A questo punto può essere necessario intervenire sui file ottenuti per qualche modifica: ad esempio possiamo togliere dai file utenti.ldif e gruppi.ldif gli utenti e i gruppi «di sistema» (come bin, mail, news ecc.) che non sono utenti e gruppi effettivi.
Sicuramente dobbiamo eliminare dal file base.ldif le righe seguenti:
|
perché sono relative ad un oggetto già presente nell'elenco (è stato inserito quando si è configurato il pacchetto slapd).
Iniziamo quindi a popolare il nostro elenco con:
# slapadd -l base.ldif
In questo modo vengono inseriti molti oggetti utili all'inserimento successivo di utenti e gruppi.
Se adesso eseguiamo il comando:
# slapcat
otteniamo una risposta molto più corposa rispetto a quando l'elenco era quasi vuoto; ci sono infatti, oltre alla radice e all'utente amministratore, anche tutti gli oggetti seguenti:
dn: ou=Hosts,dc=max,dc=planck ou: Hosts objectClass: top objectClass: organizationalUnit structuralObjectClass: organizationalUnit entryUUID: 1cade61c-c183-102a-94fb-6f2027449ad2 creatorsName: modifiersName: createTimestamp: 20060816145616Z modifyTimestamp: 20060816145616Z entryCSN: 20060816145616Z#000000#00#000000 dn: ou=Rpc,dc=max,dc=planck ou: Rpc objectClass: top objectClass: organizationalUnit structuralObjectClass: organizationalUnit entryUUID: 1cae1e20-c183-102a-94fc-6f2027449ad2 creatorsName: modifiersName: createTimestamp: 20060816145616Z modifyTimestamp: 20060816145616Z entryCSN: 20060816145616Z#000001#00#000000 dn: ou=Services,dc=max,dc=planck ou: Services objectClass: top objectClass: organizationalUnit structuralObjectClass: organizationalUnit entryUUID: 1cb07e90-c183-102a-94fd-6f2027449ad2 creatorsName: modifiersName: createTimestamp: 20060816145616Z modifyTimestamp: 20060816145616Z entryCSN: 20060816145616Z#000002#00#000000 dn: nisMapName=netgroup.byuser,dc=max,dc=planck nisMapName: netgroup.byuser objectClass: top objectClass: nisMap structuralObjectClass: nisMap entryUUID: 1cb08fa2-c183-102a-94fe-6f2027449ad2 creatorsName: modifiersName: createTimestamp: 20060816145616Z modifyTimestamp: 20060816145616Z entryCSN: 20060816145616Z#000003#00#000000 dn: ou=Mounts,dc=max,dc=planck ou: Mounts objectClass: top objectClass: organizationalUnit structuralObjectClass: organizationalUnit entryUUID: 1cb0acc6-c183-102a-94ff-6f2027449ad2 creatorsName: modifiersName: createTimestamp: 20060816145616Z modifyTimestamp: 20060816145616Z entryCSN: 20060816145616Z#000004#00#000000 dn: ou=Networks,dc=max,dc=planck ou: Networks objectClass: top objectClass: organizationalUnit structuralObjectClass: organizationalUnit entryUUID: 1cb0ba9a-c183-102a-9500-6f2027449ad2 creatorsName: modifiersName: createTimestamp: 20060816145616Z modifyTimestamp: 20060816145616Z entryCSN: 20060816145616Z#000005#00#000000 dn: ou=People,dc=max,dc=planck ou: People objectClass: top objectClass: organizationalUnit structuralObjectClass: organizationalUnit entryUUID: 1cb0c832-c183-102a-9501-6f2027449ad2 creatorsName: modifiersName: createTimestamp: 20060816145616Z modifyTimestamp: 20060816145616Z entryCSN: 20060816145616Z#000006#00#000000 dn: ou=Group,dc=max,dc=planck ou: Group objectClass: top objectClass: organizationalUnit structuralObjectClass: organizationalUnit entryUUID: 1cb0d5a2-c183-102a-9502-6f2027449ad2 creatorsName: modifiersName: createTimestamp: 20060816145616Z modifyTimestamp: 20060816145616Z entryCSN: 20060816145616Z#000007#00#000000 dn: ou=Netgroup,dc=max,dc=planck ou: Netgroup objectClass: top objectClass: organizationalUnit structuralObjectClass: organizationalUnit entryUUID: 1cb1cb4c-c183-102a-9503-6f2027449ad2 creatorsName: modifiersName: createTimestamp: 20060816145616Z modifyTimestamp: 20060816145616Z entryCSN: 20060816145616Z#000008#00#000000 dn: ou=Protocols,dc=max,dc=planck ou: Protocols objectClass: top objectClass: organizationalUnit structuralObjectClass: organizationalUnit entryUUID: 1cb1dc90-c183-102a-9504-6f2027449ad2 creatorsName: modifiersName: createTimestamp: 20060816145616Z modifyTimestamp: 20060816145616Z entryCSN: 20060816145616Z#000009#00#000000 dn: ou=Aliases,dc=max,dc=planck ou: Aliases objectClass: top objectClass: organizationalUnit structuralObjectClass: organizationalUnit entryUUID: 1cb1ea82-c183-102a-9505-6f2027449ad2 creatorsName: modifiersName: createTimestamp: 20060816145616Z modifyTimestamp: 20060816145616Z entryCSN: 20060816145616Z#00000a#00#000000 dn: nisMapName=netgroup.byhost,dc=max,dc=planck nisMapName: netgroup.byhost objectClass: top objectClass: nisMap structuralObjectClass: nisMap entryUUID: 1cb201d4-c183-102a-9506-6f2027449ad2 creatorsName: modifiersName: createTimestamp: 20060816145616Z modifyTimestamp: 20060816145616Z entryCSN: 20060816145616Z#00000b#00#000000 |
Ora non rimane che inserire utenti e gruppi con i comandi:
# slapadd -l utenti.ldif
# slapadd -l gruppi.ldif
Si può verificare con slapcat che tutti i dati siano stati inseriti.
Ecco una parte della risposta, riguardante gli oggetti nell'elenco corrispondenti all'utente e al gruppo rossimario:
dn: uid=rossimario,ou=People,dc=max,dc=planck uid: rossimario cn: Rossi Mario objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount userPassword:: e2NyeXB0fSQxJEZjRlJNWnRrJG9YZWZmTldMd1RYSnNmV281amVtNTE= shadowLastChange: 13376 shadowMax: 99999 shadowWarning: 7 loginShell: /bin/bash uidNumber: 1001 gidNumber: 1001 homeDirectory: /home/rossimario gecos: Rossi Mario,,0422-1234567, structuralObjectClass: account entryUUID: 2355333c-c19a-102a-836a-21b74a8ee554 creatorsName: modifiersName: createTimestamp: 20060816174105Z modifyTimestamp: 20060816174105Z entryCSN: 20060816174105Z#000000#00#000000 dn: cn=rossimario,ou=Group,dc=max,dc=planck objectClass: posixGroup objectClass: top cn: rossimario userPassword:: e2NyeXB0fXg= gidNumber: 1001 structuralObjectClass: posixGroup entryUUID: 25f2f44e-c19a-102a-8997-638e7699ad6b creatorsName: modifiersName: createTimestamp: 20060816174110Z modifyTimestamp: 20060816174110Z entryCSN: 20060816174110Z#000000#00#000000 |
Per continuare a utilizzare il serventeOpenLDAP, ricordiamo poi di riattivarlo:
# /etc/init.d/slapd start
Vediamo brevemente come è possibile cancellare e modificare i dati dell'elenco e come si possono fare le ricerche; le prime due operazioni possono essere svolte solo da utenti autorizzati (per come abbiamo configurato il servente, solo dall'utente amministratore).
Vediamo poi anche un modo alternativo a slapadd per inserire i dati.
Dei comandi illustrati in questo paragrafo vengono fornite solo le linee essenziali di utilizzo; per i dettagli sulle numerose opzioni previste si rimanda come al solito ai manuali in linea.
Prima di utilizzare i programmi di gestione dell'elenco occorre modificare il file di configurazione (del pacchetto libldap2) /etc/ldap/ldap.conf come mostrato di seguito:
|
Questo pacchetto viene installato anche nelle macchine clienti nelle quali, evidentemente, l'indirizzo indicato nella riga URI deve essere quello del servente e non quello del localhost.
La presenza di queste impostazioni permette di usare i comandi di manipolazione dell'elenco senza indicare ogni volta informazioni come la radice dell'albero, l'indirizzo e la porta su cui è in ascolto il servente.
Per ulteriori dettagli sul contenuto di questo file si veda il manuale in linea di ldap.conf.
Il comando per cancellare un oggetto è ldapdelete; vediamo subito un esempio supponendo di voler cancellare l'utente rossimario:
# ldapdelete -x -D "cn=admin,dc=max,dc=planck" \
\ "uid=rossimario,ou=People,dc=max,dc=planck" -W
Il significato delle opzioni e degli argomenti è questo:
-D "cn=admin,dc=max,dc=planck": l'utente che si accredita per fare l'operazione è admin;
-x: viene usato l'accreditamento semplice e non SASL;
-W: la parola d'ordine di admin viene richiesta in modo interattivo;
"uid=rossimario,ou=People,dc=max,dc=planck": è il DN dell'oggetto da cancellare.
Alcune altre opzioni importanti:
-w psw: al posto di -W, permette di indicare direttamente la parola d'ordine;
-y nome_file: al posto di -W, permette di indicare un file contenente la parola d'ordine;
-f nome_file: al posto dell'indicazione del DN, permette di inserire una lista di oggetti da cancellare in un file (un DN per riga);
-H ldap://nome_host:num_porta: la richiesta di cancellazione è fatta al nodo nome_host sulla porta num_porta (i valori per difetto sono rispettivamente localhost e 389).
Per la modifica si usa il comando ldapmodify; anche in questo caso esaminiamo un esempio:
# ldapmodify -x -D "cn=admin,dc=max,dc=planck" -f file_modifiche.txt -W
Alcune opzioni (compresa -H) hanno esattamente lo stesso significato visto nel comando precedente; in questo caso si passa in input un file_modifiche che contiene le istruzioni sulle modifiche da apportare.
Il contenuto del file potrebbe essere simile al seguente:
|
Il file contiene uno o più DN da modificare e per ognuno il tipo di modifica da fare (nell'esempio è modify ma potrebbe anche essere add o delete in modo da rimpiazzare rispettivamente i comandi ldapadd o ldapdelete). Qui si chiede di modificare gli attributi homedirectory e loginShell con i nuovi valori indicati; è anche possibile eliminare o aggiungere attributi (se consentito dallo schema) rispettivamente scrivendo delete o add al posto di replace.
Una volta eseguito il comando, ecco il nuovo aspetto dell'oggetto mariorossi ottenuto con slapcat:
dn: uid=rossimario,ou=People,dc=max,dc=planck uid: rossimario cn: Rossi Mario objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount userPassword:: e2NyeXB0fSQxJEZjRlJNWnRrJG9YZWZmTldMd1RYSnNmV281amVtNTE= shadowLastChange: 13376 shadowMax: 99999 shadowWarning: 7 uidNumber: 1001 gidNumber: 1001 gecos: Rossi Mario,,0422-1234567, structuralObjectClass: account entryUUID: 02a4028a-c1b8-102a-8b59-6d8a33f08c2a creatorsName: createTimestamp: 20060816211455Z homeDirectory: /home/rossi loginShell: /bin/zsh entryCSN: 20060816212358Z#000000#00#000000 modifiersName: cn=admin,dc=max,dc=planck modifyTimestamp: 20060816212358Z |
Esiste anche la possibilità di utilizzare ldapmodify senza passare il file di comandi; in questo caso si inseriscono le istruzioni di modifica da tastiera, con la stessa sintassi usata nel file, concludendo l'input con [Ctrl d].
In precedenza abbiamo utilizzato il comando slapadd per inserire oggetti nell'elenco. La stessa operazione si può fare anche con il comando ldapadd con la differenza che non occorre essere l'utente root e che il servente OpenLDAP deve essere attivo.
Il modo migliore per inserire oggetti nell'elenco è quello di preparare dei file LDIF contenenti i dati e passarli in input a ldapadd.
Nel caso si debbano aggiungere utenti o gruppi si può ricorrere come «modelli» ai file LDIF creati automaticamente dalle procedure di migrazione.
Ecco un esempio di uso dildapadd:
# ldapadd -x -D "cn=admin,dc=max,dc=planck" -f file_dati.ldif -W
Non occorre avere i privilegi di root per eseguire il comando ma occorre comunque accreditarsi (come per la cancellazione e la modifica) presso il servente OpenLDAP come utente abilitato alla scrittura dei dati (in questo caso l'utente admin).
Le opzioni sono le stesse viste per i comandi precedenti e anche qui è prevista l'opzione -H.
Di seguito vediamo il contenuto di un possibile file di input per l'inserimento di un utente e di uno per il corrispondente gruppo; si tenga presente che si possono comunque inserire più elementi contemporaneamente semplicemente predisponendo i corrispondenti gruppi di righe nel file di input:
|
|
Riguardo alla parola d'ordine si può agire in due modi diversi:
generarla con il comando slappasswd (vedere il manuale in linea per i dettagli) e poi copiare la parola d'ordine cifrata ottenuta nel file di input come valore dell'attributo userPassword; ovviamente questo va fatto prima di eseguire il comando di caricamento dei dati;
aggiornare la parola d'ordine dopo avere inserito l'utente con il comando:
# ldappasswd -x -D "cn=admin,dc=max,dc=planck" -W \
\-S "uid=bianchipaolo,ou=People,dc=max,dc=planck"
Usando il secondo metodo si riceve richiesta della nuova parola d'ordine dell'utente e della sua conferma (è l'effetto dell'opzione -S) e poi della parola d'ordine dell'utente (amministratore) che si collega per svolgere l'operazione (vedere figura 9.23).
|
Figura 9.23.
|
Anche il comando ldappasswd prevede la possibilità di interagire con un servente diverso dal localhost grazie all'opzione -H.
Una volta che è stata assegnata la prima parola d'ordine ad un utente, questi può cambiarsela in ogni momento con un comando del tipo:
# ldappasswd -x -D "uid=bianchipaolo,ou=People,dc=max,dc=planck" -W -S
In questo caso non è necessario specificare il DN dell'utente di cui variare la parola d'ordine perché, in mancanza di questa informazione, il sistema agisce sull'utente che si collega al servente (in questo caso bianchipaolo).
Il comando per effettuare ricerche nell'elenco è ldapsearch.
Le opzioni e le possibilità di utilizzo sono numerose e quindi anche in questo caso si evita l'esame di tutti i dettagli, che sono comunque a disposizione nel manuale in linea, e si commentano alcuni esempi, ricordando che molte opzioni (-H, -x, -D, -W) hanno esattamente lo stesso significato visto nel paragrafo precedente.
# ldapsearch -x -LLL -b "dc=max,dc=planck"
Si chiede il contenuto di tutto l'elenco che ha come radice dc=max,dc=planck (opzione -b); l'opzione -L serve ad avere il risultato in formato LDIF, se sono due si disabilitano i commenti e se sono tre si disabilita anche la visualizzazione della versione di LDIF.
L'indicazione della base della ricerca può essere evitata se si inserisce nel file di configurazione /etc/ldap/slapd.conf tra le direttive globali, la riga seguente:
|
Come si vede non è necessario (anche se non è proibito) collegarsi al servente con credenziali valide perché la lettura delle informazioni è libera; per questo motivo nella risposta non appaiono gli attributi sensibili come la userPassword.
# ldapsearch -x -LLL -b "dc=max,dc=planck" "(cn=*)"
Si chiedono tutti gli oggetti che hanno un attributo cn presente, qualsiasi sia il valore di quest'ultimo.
# ldapsearch -x -LLL -b "dc=max,dc=planck" "(uid=*)"\
\loginShell homeDirectory
Si chiedono tutti gli utenti e si vogliono visualizzare solo gli attributi loginShell e homeDirectory; in figura 9.26 si vede l'effetto del comando.
|
Figura 9.26.
|
# ldapsearch -x -LLL -b "dc=max,dc=planck" "(ou=p*)"
Si chiedono tutte le organizational unit il cui nome inizia con «p» o «P» (si ricorda che i valori degli attributi non sono case sensitive).
# ldapsearch -x -LLL -b "dc=max,dc=planck"\
\ "(&(uid=*)(loginshell=/bin/bash))" loginShell homeDirectory
In questo ultimo esempio si vede l'uso di un filtro di ricerca multiplo: si vogliono gli oggetti con attributo uid presente e loginShell uguale a /bin/bash; si noti la sintassi che prevede l'indicazione dell'operatore booleano in testa alla stringa di ricerca.
Gli operatori booleani sono:
&: and;
|: or;
!: not.
Esistono vari strumenti grafici che facilitano la gestione di un elenco OpenLDAP.
Per i motivi già illustrati nella premessa, è consigliabile utilizzare questo tipo di programmi solo quando si è acquisista sufficiente conoscenza sulla struttura, la configurazione, la gestione di un elenco OpenLDAP, in modo da sfruttarne la comodità e velocità di utilizzo sapendo però quello che si sta facendo.
A titolo di esempio citiamo gq (2) (<http://gq-project.org/>) del quale vediamo un immagine in figura 9.27.
|
Figura 9.27.
|
e l'ottimo programma webmin (3) (<http://www.webmin.com>) che permette la gestione completa di un sistema GNU/Linux con una comoda interfaccia per programmi di navigazione (alla porta 10000) e possiede anche un modulo per gli utenti OpenLDAP (webmin-ldap-useradmin).
Nella figura 9.28 vediamo la schermata di configurazione del modulo:
|
Figura 9.28.
|
In figura 9.29 vediamo invece una delle schermate per la gestione degli utenti memorizzati nell'elenco OpenLDAP.
|
Figura 9.29.
|
Una volta installato e configurato il servente OpenLDAP si può passare a configurare i clienti affinché lo utilizzino per l'accreditamento degli utenti; a questo proposito possiamo senz'altro considerare tra i clienti anche la macchina dove è installato OpenLDAP.
Devono essere installati i pacchetti nscd (che non richiede configurazioni particolari), libnss-ldap e libpam-ldap per i quali invece la procedura di installazione richiede alcune informazioni.
Iniziamo da libnss-ldap con la schermata di figura 9.30
|
Figura 9.30.
|
per l'immissione dell'indirizzo del servente.
Evidentemente i dati mostrati sono relativi alla configurazione della macchina che ospita il servente stesso; se si tratta di un'altra macchina occorre variare opportunamente l'indirizzo IP.
Successivamente viene richiesto il suffisso dell'elenco da utilizzare (figura 9.31).
|
Figura 9.31.
|
Viene poi richiesta la versione di LDAP (scegliere la 3).
A seguire si hanno tre schermate riguardanti il modo di interrogazione dell'elenco e la sicurezza della parola d'ordine dell'amministratore.
Con la prima viene richiesto se l'interrogazione dell'elenco richiede l'accreditamento; rispondere affermativamente (figura 9.32).
|
Figura 9.32.
|
Poi si ha la domanda circa la possibilità di accreditarsi come amministratore per interrogare l'elenco; questo è il problema discusso alla fine del paragrafo 9.2.2.
In base alle considerazioni svolte rispondiamo negativamente (figura 9.33) a meno che non stiamo configurando come cliente la macchina che ospita il servente per la quale i rischi di compromissione dell'utenza root sono (o dovrebbero essere) molto minori rispetto ad una macchina «normale» della rete.
|
Figura 9.33.
|
con la schermata successiva si possono impostare in modo restrittivo i permessi relativi al file di configurazione di libnss-ldap; rispondiamo affermativamente (figura 9.34).
|
Figura 9.34.
|
Infine vengono richiesti l'account dell'utente con cui accreditarsi presso il servente OpenLDAP (figura 9.35) e la relativa parola d'ordine; utilizziamo l'utente auth come stabilito in precedenza.
|
Figura 9.35.
|
La configurazione si conclude con una schermata che ricorda l'esigenza di intervenire manualmente sul file /etc/nsswitch.conf per completare la configurazione del servizio NSS.
Per il pacchetto libpam-ldap le richieste sono analoghe; c'è solo una schermata in più che chiede l'algoritmo per la cifratura della parola d'ordine in caso essa venga variata (figura 9.36).
|
Figura 9.36.
|
I dati di configurazione vengono memorizzati nei file /etc/libnss-ldap.conf e /etc/pam_ldap.conf; se sono necessari cambiamenti si può intervenire su di essi oppure si può eseguire il comando dpkg-reconfigure sul pacchetto da variare.
|
Una volta configurato o riconfigurato il pacchetto libnss-ldap occorre riavviare il demone nscd:
|
Nel file /etc/nsswitch.conf, contenente la configurazione del servizio NSS, è necessario aggiungere l'archivio gestito con OpenLDAP tra le fonti dei dati relativi a utenti e gruppi come mostrato di seguito:
|
L'ordine con cui vengono elencate le fonti è significativo e quindi è opportuno lasciare la priorità a compat in modo che per primi siano interrogati i file di sistema.
A questo punto si è già in grado di verificare con il comando:
# getent passwd
che gli utenti dell'elenco appaiano fra quelli riconosciuti dal sistema.
Prima di fare questa prova è consigliabile togliere gli utenti e i gruppi dai file di configurazione del sistema /etc/passwd, /etc/shadow, /etc/group, cancellando le righe relative o usando i comandi userdel o deluser e groudel o delgroup; in questo modo siamo sicuri che gli utenti e i gruppi elencati sono davvero quelli di OpenLDAP.
Si può inoltre verificare il buon esito dell'accreditamento degli utenti sia sul sistema che ospita il cliente che su macchine clienti in cui si siano effettuate le configurazioni appena esaminate.
Prima di fare questa prova occorre però configurare un altro servizio che è molto utile nel contesto che stiamo esaminando: NFS (Network file system), con il quale possiamo centralizzare anche le directory personali degli utenti della rete GNU/Linux.
La macchina sulla quale far risiedere le directory può essere una qualsiasi nella rete, ma ha sicuramente senso che sia la stessa che accredita gli utenti, cioè quella dove è installato OpenLDAP.
Un esame approfondito del servizio NFS esula dagli scopi di queste dispense; ci limitiamo alle nozioni indispensabili il compito che ci proponiamo.
Nella macchina servente si deve installare il pacchetto nfs-kernel-server e configurare il file /etc/exports come mostrato di seguito:
|
Il significato della configurazione è abbastanza evidente: si vuole condividere la directory /home per tutte le macchine della rete con indirizzo 10.0.0.0 e maschera di rete 255.0.0.0 dando la possibilità di leggere e scrivere tale directory (fatti salvi i permessi sui singoli elementi in essa contenuti).
Si deve poi riavviare il servente NFS:
# /etc/init.d/nfs-kernel-server restart
Sulle macchine clienti bisogna invece intervenire nel file /etc/fstab aggiungendo una riga come questa:
|
Significa che la directory /home del servente (che si suppone abbia indirizzo 10.0.0.3) viene montata sulla /home di quella macchina, che deve esistere ed essere possibilmente vuota (il montaggio non cancella il contenuto preesistente ma lo rende irraggiungibile).
Affinché il montaggio avvenga bisogna però anche eseguire:
# mount -a
ma solo la prima volta perché i montaggi indicati nel file /etc/fstab vengono fatti automaticamente ad ogni riavvio del sistema.
Una volta fatte queste operazioni si può provare a collegarsi su una macchina cliente come utente presente nell'elenco OpenLDAP.
Nella figura 9.40 viene mostrata tale operazione con la successiva esecuzione di vari comandi che permettono di constatare come effettivamente l'utente si sia accredidato da remoto.
|
Figura 9.40.
|
Ricordando le precauzioni da prendere prima di modificare i moduli PAM che sono state elencate nel paragrafo 7.1.2, vediamo come modificare i file di configurazione di tale servizio affinché le applicazioni presenti su una macchina GNU/Linux (login, gdm, ssh ecc.) effettuino l'autenticazione degli utenti attraverso OpenLDAP:
Nei file di configurazione PAM dei servizi che si vogliono autenticare con OpenLDAP si devono aggiungere righe simili a quelle sotto elencate prima delle analoghe righe che fanno riferimento a pam_unix.so con opzione required.
|
In Debian e distribuzioni derivate si può intervenire nei seguenti file (usati da tutte le applicazioni):
/etc/pam.d/common-account
/etc/pam.d/common-auth
/etc/pam.d/common-password
/etc/pam.d/common-session
Anche in questo caso è possibile creare automaticamente la directory personale di un utente al suo primo accreditamento (come visto nel paragrafo 7.1.2) aggiungendo in testa al file /etc/pam.d/common-session la seguente riga:
|
Vediamo adesso come utilizzare Samba come PDC con archivio utenti gestito da OpenLDAP.
Questa possibilità è presente stabilmente dalla versione 3 di Samba; con le versioni precedenti era necessario configurare e compilare manualmente il software.
Si noti inoltre che, dovendo aggiornare un servente Samba dalla versione 2.2 alla 3 si deve prevedere una conversione degli oggetti dell'elenco in quanto non è stata mantenuta la compatibilità tra gli schemi di elenco utilizzati e si è passati dal tipo di oggetto sambaAccount a sambaSamAccount.
Per la conversione è possibile utilizzare lo script convertSambaAccount disponibile (in Debian) in /usr/share/doc/samba-doc/examples/LDAP/.
Supponiamo di avere già un archivio di utenti GNU/Linux e che l'elenco OpenLDAP sia inizialmente vuoto; quindi ripartiamo da zero eliminando gli eventuali oggetti inseriti con le prove precedenti.
Il modo più rapido per ottenere questo è fermare il servente slapd, cancellare il contenuto della directory /var/lib/ldap/ e ricreare l'elenco nuovo eseguendo il comando:
# dpkg-reconfigure slapd
Sono comunque da svolgere le operazioni di configurazione del servente OpenLDAP e dei pacchetti libnss-ldap e libpam-ldap descritte nei paragrafi 9.2.2 e 9.3.
Dobbiamo poi installare il pacchetto smbldap-tools che contiene tutto quello che serve per i nostri scopi; i programmi presenti sono scritti in Perl e sono i seguenti (per i dettagli di funzionamento si rimanda alla consultazione dei rispettivi manuali in linea):
/usr/sbin/smbldap-groupadd
/usr/sbin/smbldap-groupdel
/usr/sbin/smbldap-groupmod
/usr/sbin/smbldap-groupshow
/usr/sbin/smbldap-passwd
/usr/sbin/smbldap-populate
/usr/sbin/smbldap-useradd
/usr/sbin/smbldap-userdel
/usr/sbin/smbldap-userinfo
/usr/sbin/smbldap-usermod
/usr/sbin/smbldap-usershow
Prima di iniziare a definire l'elenco occorre modificare la configurazione di questo pacchetto e di OpenLDAP compiendo le seguenti operazioni:
copiare i file smbldap.conf e smbldap_bind.conf da /usr/share/doc/smbldap-tools/examples/ a /etc/smbldap-tools/ con i comandi:
# zcat /usr/share/doc/smbldap-tools/examples/smbldap.conf.gz >\
\/etc/smbldap-tools/smbldap.conf
# cp /usr/share/doc/smbldap-tools/examples/smbldap_bind.conf\
\/etc/smbldap-tools/
modificare il file smbldap.conf come mostrato di seguito:
|
i parametro più importanti sono il SID (Security identifier), l'indirizzo del servente OpenLDAP, la radice dell'albero, l'uso di TLS, il metodo di cifratura delle parole d'ordine.
Per ottenere il SID bisogna eseguire il seguente comando sulla macchina in cui è attivo il servente Samba:
# net getlocalsid
si noti che l'uso di TLS è disattivato (riga 80), che il metodo di cifratura è crypt (riga 132), che l'unità organizzativa cui appartengono gli utenti è Users (riga 105) e non People come negli esempi precedenti; importante è anche la riga 126 in cui si stabilisce in quale DN memorizzare i contatori uid e gid da usare quando si creano nuovi utenti;
modificare il file smbldap_bind.conf inserendo il DN dell'amministratore e la relativa parola d'ordine;
sistemare i permessi dei file di configurazione:
# chmod 0644 /etc/smbldap-tools/smbldap.conf
# chmod 0600 /etc/smbldap-tools/smbldap_bind.conf
copiare lo schema di elenco per Samba con il comando:
# zcat /usr/share/doc/samba-doc/examples/LDAP/samba.schema.gz >\
\/etc/ldap/schema/samba.schema
aggiungere nel file /etc/ldap/slapd.conf, tra le direttive globali, la riga:
|
per ottimizzare gli accessi ai dati in elenco da parte di Samba si possono inserire le righe seguenti fra le direttive della base di dati in /etc/ldap/slapd.conf:
|
per permettere agli utenti di cambiare la loro parola d'ordine NT e LM (Lan manager) si può cambiare, sempre nello stesso file, la riga:
|
in:
|
A questo punto si fa ripartire il servente OpenLDAP e si può popolare l'elenco eseguendo il comando:
# smbldap-populate -a admin
Vengono inseriti tutti gli oggetti di base per il funzionamento di Samba con backend OpenLDAP e al termine viene richiesto di inserire la pasword per l'amministratore dell'elenco.
Vediamo ora le modifiche da apportare al file /etc/samba/smb.conf affinché il servente Samba funzioni in associazione a OpenLDAP.
Ovviamente si danno per acquisite tutte le configurazioni utili al funzionamento di Samba comprese quelle per la funzionalità di PDC illustrate nel capitolo 6.
Tutte le righe prese in esame fanno parte della sezione global del file di configurazione.
Prima di tutto si configura l'archivio degli utenti intervenendo sulla direttiva passdb backend:
|
Quindi si impostano le opzioni relative all'elenco:
|
Altre impostazioni riguardano la possibilità di cambiare la parola d'ordine e di amministrare utenti e gruppi da MS-Windows e fanno uso di alcuni dei programmi delpacchetto smbldap-tools:
|
Dopo avere controllato con testparm che non ci siano errori si aggiunge la parola d'ordine dell'amministratore di Samba con il comando:
# smbpasswd -w psw_di_admin
e si fa ripartire il servente.
Rimangono da inserire gli utenti (compresi gli utenti speciali corrispondenti alla macchine) per i quali si possono creare dei file LDIF in modo analogo a quanto mostrato in precedenza.
Se però, vogliamo partire da un archivio utenti GNU/Linux già esistente, possiamo migrarlo usando dei programmi Perl forniti con il pacchetto smbldap-tools.
Rendiamo tali programmi disponibili per l'esecuzione con i comandi:
# zcat /usr/share/doc/smbldap-tools/examples/smbldap-migrate-unix-\
\accounts.gz > /usr/bin/smbldap-migrate-unix-accounts
# zcat /usr/share/doc/smbldap-tools/examples/smbldap-migrate-unix-\
\groups.gz > /usr/bin/smbldap-migrate-unix-groups
# chmod 755 /usr/bin/smbldap-migrate-unix-*
Copiamo poi i file /etc/passwd, /etc/shadow e /etc/group in /tmp/ e togliamo dai file copiati le righe relative a utenti e gruppi di sistema; saranno questi file, così «depurati» a costituire l'input per la migrazione.
Per inserire utenti e gruppi nell'elenco eseguiamo (con il servente OpenLDAP attivo):
# smbldap-migrate-unix-accounts -a -P /tmp/passwd\
\-S /tmp/shadow
# smbldap-migrate-unix-groups -a -G /tmp/group
dopodiché si possono eliminare utenti e gruppi migrati dai file /etc/passwd, /etc/shadow e /etc/group.
A questo punto non rimane che definire la parola d'ordine degli utenti con il comando:
# smbldap-passwd nome_utente
In verità la parola d'ordine per GNU/Linux sarebbe già definita (migrata da /etc/shadow) ma manca quella per MS-Windows; il comando le ridefinisce entrambe (si può anche definire solo la parola d'ordine per GNU/Linux o solo quella per MS-Windows usando l' opzione -s o l'opzione-u ).
Ecco una parte della risposta al comando slapcat riguardante l'utente e il gruppo verdimarco dopo la migrazione e la definizione della parola d'ordine:
dn: uid=verdimarco,ou=Users,dc=max,dc=planck objectClass: posixAccount objectClass: inetOrgPerson objectClass: shadowAccount objectClass: sambaSamAccount uid: verdimarco cn: Verdi Marco sn: Marco uidNumber: 1002 gidNumber: 1002 gecos: Verdi Marco,,, homeDirectory: /home/verdimarco loginShell: /bin/bash shadowLastChange: 13390 shadowMax: 99999 shadowWarning: 7 sambaSID: S-1-5-21-4251291460-501516116-4086100184-3004 structuralObjectClass: inetOrgPerson entryUUID: aa0935aa-cc48-102a-880c-4b28893bdc7f creatorsName: cn=admin,dc=max,dc=planck createTimestamp: 20060830075535Z sambaLMPassword: F1CDD48D94CE974325AD3B83FA6627C7 sambaNTPassword: 4B56A9FE1BF0C1D8F3BE14D8E86022E3 sambaPwdLastSet: 1156925821 userPassword:: e0NSWVBUfXJJOHY5R3FrOHdRN3c= sambaAcctFlags: [UX ] entryCSN: 20060830083209Z#000000#00#000000 modifiersName: cn=admin,dc=max,dc=planck modifyTimestamp: 20060830083209Z dn: cn=verdimarco,ou=Groups,dc=max,dc=planck objectClass: posixGroup objectClass: sambaGroupMapping cn: verdimarco userPassword:: e2NyeXB0fXg= gidNumber: 1002 sambaSID: S-1-5-21-4251291460-501516116-4086100184-3005 sambaGroupType: 2 structuralObjectClass: posixGroup entryUUID: 4a780ca4-cc4f-102a-880f-4b28893bdc7f creatorsName: cn=admin,dc=max,dc=planck createTimestamp: 20060830084302Z entryCSN: 20060830084302Z#000002#00#000000 modifiersName: cn=admin,dc=max,dc=planck modifyTimestamp: 20060830084302Z |
Per gestire gli utenti dell'elenco OpenLDAP per Samba si possono usare i comandi del pacchetto smbldap-tools come smbldap-groupadd, smbldap-useradd, smbldap-userdel, il cui ruolo dovrebbe essere chiaro già dal nome.
Ad esempio per inserire in elenco il nuovo utente rossimario, appartenente al gruppo omonimo, e definirne la parola d'ordine si eseguono i comandi:
# smbldap-groupadd -a rossimario
# smbldap-useradd -a -g rossimario -m rossimario
# smbldap-passwd rossimario
L'opzione -a nel primo comando provoca la creazione di un SID per quel gruppo; nel secondo comando invece fa si che quell'utente abbia anche un account Samba oltre che GNU/Linux.
L'opzione -g serve ad assegnare l'utente al gruppo indicato, mentre -m permette la creazione automatica della sua directory personale.
Se invece si deveno inserire in elenco delle utenze per macchina (cosa essenziale se abbiamo come clienti delle workstation MS-Windows NT o XP) dobbiamo eseguire:
# smbldap-useradd -w nome_utenza
dove -w significa appunto che si tratta di una utenza di tipo macchina.
Arrivati a questo punto si può provare a utilizzare il nostro servente Samba con backend OpenLDAP sia da clienti GNU/Linux configurati come illustrato nel paragrafo 9.3, sia da clienti MS-Windows configurati come spiegato nel capitolo 6.
A tale proposito si noti che, per unire le workstation MS-Windows al dominio gestito da Samba, viene richiesto di accreditarsi (durante il processo di unione effettuato sulla workstation) con un utente Samba con sufficienti privilegi: si può utilizzare a tale scopo l'utente admin.
Nella figura 9.52 si vede il risultato di un tentativo di accreditamento su un cliente GNU/Linux da parte dell'utente verdimarco:
|
Figura 9.52.
|
In figura 9.53 invece c'è una prova di collegamento alla risorsa condivisa tmp del servente Samba (il cui nome è plancknew) effettuata con lo strumento smbclient e atta a verificare la validità dello stesso utente anche come account Samba.
|
Figura 9.53.
|
Un cliente grafico per gestire gli utenti di Samba con backend OpenLDAP è ldap account manager (4) (<http://lam.sourceforge.net/>).
Si tratta di uno strumento, scritto in PHP, che fornisce un'interfaccia Web per la gestione dei dati dell'elenco.
Una volta installato e configurato (per i dettagli si rimanda alla documentazione del pacchetto) si accede all'interfaccia collegandosi all'indirizzo https://localhost/lam e si ottiene la schermata di accreditamento (vedi figura 9.54).
|
Figura 9.54.
|
Nella figura 9.55 è invece mostrato il modulo di gestione dei dati di un utente dell'elenco.
|
Figura 9.55.
|
Fino a questo momento è stato illustrato l'uso di un servente OpenLDAP con comunicazione in chiaro tra quest'ultimo e i clienti.
Questa soluzione comporta ovviamente il rischio che le parole d'ordine degli utenti cadano in mano a persone non autorizzate e tale rischio è presente anche se il servizio è utilizzato solo in un contesto di rete locale.
Per ridurre ai minimi termini tale rischio di può cifrare la comunicazione con il servente OpenLDAP usando OpenSSL.
OpenSSL (5) (<http://www.openssl.org>) permette l'utilizzo dei protocolli SSL (Secure socket layer) e TLS (Transport layer security).
SSL è stato sviluppato dalla Netscape ed è divenuto lo strumento universalmente accettato pe
