Figura 9.24.
|
|
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 definiti secondo le specifiche X.500.
Esistono vari servizi di elenchi in rete proprietari, come ad esempio Oracle Internet Directory o Microsoft Active Directory; con OpenLDAP, del quale ci occupiamo in questa sede, è possibile realizzarli in modo completamente libero.
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 Query 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.4 per la gestione degli utenti, facendo riferimento alla distribuzione 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;
ldap-auth-client_x.y.z.deb
ldap-auth-config_x.y.z.deb
auth-client-config_x.y.z.deb
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» come NIS e OpenLDAP.
Siccome alcuni dei pacchetti citati comprendono programmi scritti in Perl, è necessario che quest'ultimo sia installato nella macchina che stiamo utilizzando.
Nelle ultime versioni di OpenLDAP (precisamente a partire dalla 2.3) il sistema di configurazione è completamente variato.
In precedenza veniva usato il classico file di configurazione /etc/ldap/slapd.conf (che comunque può ancora essere utilizzato, come descritto nel paragrafo 9.2.3), mentre ora si è passati ad un metodo basato su una voce DIT speciale che contiene i vari parametri e che viene denominato in varie maniere:
cn=config configuration; dal nome della voce dell'albero di directory che contiene i parametri;
slapd.d configuration; dal nome della directory che contiene fisicamente l'archivio con i dati di configurazione all'interno di /etc/ldap;
run-time configuration o zero down-time configuration; dal fatto che non occorre più fermare e riavviare il servizio dopo ogni variazione nella configurazione.
Il nuovo sistema è stato adottato proprio per avere maggiore flessibilità e per poter variare dinamicamente la configurazione con il servizio attivo.
Con alcune distribuzioni di GNU/Linux c'è la possibilità di inserire i parametri fondamentali per l'uso di OpenLDAP semplicemente riconfigurando il pacchetto con il comando:
# dpkg-reconfigure slapd
In questo modo si ricevono varie schermate con le richieste relative (tra le altre) alla radice dell'elenco e ai dati di accreditamento dell'utente amministratore.
Nelle versioni più recenti di Ubuntu questo non avviene in quanto il servente viene installato con una configurazione minima e deve essere manipolato con i comandi messi a disposizione dal pacchetto ldap-utils.
Gli unici aspetti su cui si può intervenire con la riconfigurazione sono:
la cancellazione dell'archivio in caso di eliminazione del pacchetto (si consiglia la risposta affermativa);
l'attivazione del supporto al vecchio protocollo LDAPv2 (la versione attuale è la 3); si può rispondere negativamente a meno che non si abbiano programmi che lo utilizzano.
Di seguito vediamo come inserire le informazioni di base nell'archivo di OpenLDAP, in una versione recente di Ubuntu.
Allo scopo vengono usati il comando ldapadd e i file con formato LDIF, che vengono dettagliati maggiormente nel paragrafo 9.2.5:
rendere disponibili gli schemi fondamentali (presenti, dopo l'installazione, nella posizione /etc/ldap/schema/), con il comando:
# ls /etc/ldap/schema/*.ldif | xargs -I {} ldapadd -Y EXTERNAL\
\-H ldapi:/// -f {}
definire il suffisso dell'elenco (che si suppone corrisponda al dominio max.planck), il tipo di archivio (BDB Berkeley Data Base) e i dati dell'amministratore, con il comando:
# ldapadd -Y EXTERNAL -H ldapi:/// -f slapd_db.ldif
dopo avere creato il file slapd_db.ldif con il seguente contenuto:
|
inserire la radice dell'elenco qualche unità organizzativa di base, con il comando:
# ldapadd -x -D cn=admin,dc=max,dc=planck -w admin\
\-f slapd_people.ldif
dove si suppone che la password dell'amministratore sia admin.
Il file slapd_people.ldif deve essere creato con il seguente contenuto:
|
Per verificare l'esito positivo delle operazioni appena descritte si può eseguire il comando:
# slapcat
che serve ad estrarre le informazioni dall'elenco e dovrebbe fornire questo risultato:
dn: dc=max,dc=planck objectClass: top objectClass: dcObject objectClass: organization o: max.planck dc: max description:: SG9tZSBuZXR3b3JrIA== structuralObjectClass: organization entryUUID: b59b4738-f605-102e-9bfe-8f074a5e4515 creatorsName: cn=admin,dc=max,dc=planck createTimestamp: 20100517134158Z entryCSN: 20100517134158.581185Z#000000#000#000000 modifiersName: cn=admin,dc=max,dc=planck modifyTimestamp: 20100517134158Z dn: ou=people,dc=max,dc=planck objectClass: organizationalUnit ou: people structuralObjectClass: organizationalUnit entryUUID: b59be2f6-f605-102e-9bff-8f074a5e4515 creatorsName: cn=admin,dc=max,dc=planck createTimestamp: 20100517134158Z entryCSN: 20100517134158.585171Z#000000#000#000000 modifiersName: cn=admin,dc=max,dc=planck modifyTimestamp: 20100517134158Z dn: ou=groups,dc=max,dc=planck objectClass: organizationalUnit ou: groups structuralObjectClass: organizationalUnit entryUUID: b59c1a82-f605-102e-9c00-8f074a5e4515 creatorsName: cn=admin,dc=max,dc=planck createTimestamp: 20100517134158Z entryCSN: 20100517134158.586593Z#000000#000#000000 modifiersName: cn=admin,dc=max,dc=planck modifyTimestamp: 20100517134158Z |
Concludiamo questo paragrafo sulla configurazione mostrando il contenuto di un altro file, molto importante, presente in Ubuntu e altre distribuzioni derivate da Debian; si tratta del file /etc/default/slapd che contiene alcune impostazioni fondamentali come il nome dell'utente e del gruppo con i privilegi dei quali è in esecuzione il servente OpenLDAP e soprattutto l'indicazione di quale è la modalità di configurazione adottata.
Quest'ultima impostazione è visibile proprio all'inizio del file; non aggiungiamo ulteriori considerazioni sul suo contenuto in quanto i commenti già presenti sono sufficientemente chiari.
|
Come accennato in precedenza, il vecchio metodo di configurazione del servizio OpenLDAP è ancora utilizzabile; prima di vedere come, esaminiamo il contenutodi un file di configurazione slapd.conf relativo ad una versione di OpenLDAP precedente alla 2.3:
|
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 sono di solito sufficienti per un uso «normale» di OpenLDAP (eventualmente sarebbe da aggiungere lo schema per Samba in caso si vogliano avere gli utenti di quest'ultimo gestiti in un elenco).
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; 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, può essere 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 usare il vecchio file di configurazione /etc/ldap/slapd.conf occorre convertirne il contenuto nel nuovo formato tramite il seguente procedimento:
creare il proprio file di configurazione con il vecchio formato e denominarlo /etc/ldap/slapd.conf (ovviamente la scelta di tale percorso/nome non è obbligatoria);
creare eventualmente la directory che deve contenere i nuovi archivi di configurazione; ad esempio /etc/ldap/slapd.d;
eseguire solo la prima delle tre operazioni elencate nel paragrafo 9.2.2 (quella che riguarda l'inserimento della radice dell'elenco, del tipo di archivio ecc.);
se attivo, fermare il servizio ldap;
posizionarsi nella directory /etc/ldap e convertire il file di configurazione con il comando seguente:
# slaptest -f slapd.conf -F slapd.d
a questo punto può essere necessario cambiare proprietario e gruppo proprietario di tutti i file creati con il comando:
# chown -R openldap:openldap slapd.d
riavviare il servizio ldap.
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 avviati automaticamente all'accensione del sistema.
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.
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 oggetti 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 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_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.
Tutti presenti nella directory /usr/share/migrationtools/.
Prima di usare questi strumenti occorre modificare il file /usr/share/perl5/migrate_common.ph, contenente le impostazioni di base per la migrazione, in modo che le righe riguardanti il nome del dominio e il suffisso assumano il seguente aspetto:
|
Procediamo poi alla creazione dei file LDIF posizionandoci in /usr/share/migrationtools/ ed 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 servente OpenLDAP, 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 /etc/ldap/ldap.conf (o /etc/ldap.conf) in modo che contenga le informazioni mostrate di seguito (il contenuto preciso del file varia secondo la versione dei pacchetti che si usano):
|
Questo è necessario anche nelle macchine clienti nelle quali, evidentemente, l'indirizzo indicato nella riga URI deve essere quello del servente e non quello del localhost; in caso ci fossero problemi di collegamento al servente si può provare ad inserire la riga host numero_ip al posto di URI.
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 di ldapadd:
# 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.24).
|
Figura 9.24.
|
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.27 si vede l'effetto del comando.
|
Figura 9.27.
|
# 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 è acquisita 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.28.
|
Figura 9.28.
|
e l'ottimo programma webmin (3) (<http://www.webmin.com>) che permette la gestione completa di un sistema GNU/Linux con una comoda interfaccia Web (alla porta 10000) e che possiede anche moduli per gli utenti OpenLDAP (ldap users and groups e ldap client utilizzabili in caso si siano installati anche i pacchetti di OpenLDAP per l'autenticazione degli utenti di cui parliamo nel paragrafo 9.3).
Nella figura 9.29 vediamo la schermata di configurazione del modulo ldap client:
|
Figura 9.29.
|
In figura 9.30 vediamo invece una delle schermate, dello stesso modulo, per l'interrogazione dei dati dell'elenco OpenLDAP.
|
Figura 9.30.
|
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), ldap-auth-client, ldap-auth-config, auth-client-config, libnss-ldap e libpam-ldap per i quali invece la procedura di installazione richiede alcune informazioni.
Si ricevono varie richieste riguardanti la configurazione di ldap-auth-config a partire dall'URI (Uniform Resource Identifier) del servente.
Nella figura 9.31 è visibile la relativa schermata in cui si suppone che il servente sia la macchina su cui si stanno configurando anche gli strumenti «lato cliente»; nella realtà questo è ovviamente il caso meno frequente, quindi consideriamo di dover indicare, al posto di localhost, l'indirizzo di una macchina remota.
|
Figura 9.31.
|
Successivamente viene richiesto il suffisso dell'elenco da utilizzare (figura 9.32).
|
Figura 9.32.
|
Quindi è la volta della versione di LDAP (scegliere la 3).
A seguire (figura 9.33) viene chiesto se si vuole che le password utility che utilizzano pam si comportino come se si stessero usando le parole d'ordine locali (ripondere affermativamente).
|
Figura 9.33.
|
La schermata successiva permette di specificare se l'accesso all'archivio di OpenLDAP richiede accreditamento (rispondere affermativamente).
Infine si devono immettere i dati dell'utente abilitato a cambiare le parole d'ordine (deve essere un utente privilegiato, vedi figura 9.34) e dell'utente usato per collegarsi all'elenco (meglio che non sia un utente privilegiato vedi figura 9.35).
Quest'ultimo utente ovviamente deve essere presente nell'elenco; per il suo inserimento si faccia riferimento a quanto descritto nel paragrafo 9.2.5.
|
Figura 9.34.
|
|
Figura 9.35.
|
Entrambe le schermate sono seguite dalla richiesta di immissione delle parole d'ordine degli utenti prescelti.
|
Una volta ultimata questa configurazione 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 devono installare i pacchetti nfs-kernel-server, nfs-common e portmap e si deve 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 installare i pacchetti nfs-common e portmap e 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.39 viene mostrata tale operazione con la successiva esecuzione di vari comandi che permettono di constatare come effettivamente l'utente si sia accreditato da remoto.
|
Figura 9.39.
|
Durante la configurazione del pacchetto ldap-auth-config dovrebbe avvenire anche la configurazione del servizio PAM.
In caso contrario si può procedere manualmente ricordando le precauzioni da prendere prima di modificare i moduli PAM che sono state elencate nel paragrafo 7.1.3.
Lo scopo delle modifiche è fare in modo che 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.3) 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
Si devono poi reinserire schemi e informazioni di base e configurare ldap-auth-config come descritto nei paragrafi 9.2.2 e 9.3.1.
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
A questo punto occorre differenziare le operazioni da svolgere in base al fatto che sia utilizzato il vecchio metodo di configurazione basato sul file /etc/ldap/slapd.conf oppure la cn=config configuration.
Nel primo caso si procede nel modo seguente:
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:
|
eseguire solo la prima delle tre operazioni elencate nel paragrafo 9.2.2 (quella che riguarda l'inserimento della radice dell'elenco, del tipo di archivio ecc.);
posizionarsi nella directory /etc/ldap e convertire il file di configurazione con il comando seguente:
# slaptest -f slapd.conf -F slapd.d
Per definire e usare lo schema per Samba con il nuovo metodo di configurazione occorre prima trasformare la sua definizione nel formato LDIF e poi inserirlo nell'elenco.
I passi da compiere sono:
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
creare il file schema_convert.conf (il nome può essere anche diverso) contenente:
|
creare una directory temporanea di lavoro:
# mkdir /tmp/ldif_output
convertire i dati dello schema con il comando:
# slapcat -f schema_convert.conf -F /tmp/ldif_output -n0\
\-s "cn={12}samba,cn=schema,cn=config" > /tmp/cn=samba.ldif
nel file generato /tmp/cn\=samba.ldif togliere dalle prime righe «{12}» in modo da ottenere:
|
e togliere le righe seguenti dal fondo del file:
|
infine aggiungere lo schema all'elenco con il comando:
# ldapadd -Y EXTERNAL -H ldapi:/// -f /tmp/cn\=samba.ldif
creare un nuovo file samba_indexes.ldif con:
|
caricare gli indici definiti in questo file con il comando:
# ldapmodify -Y EXTERNAL -H ldapi:/// -f samba_indexes.ldif
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 password 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 del pacchetto 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/migration_scripts/\
\smbldap-migrate-unix-accounts.gz > /usr/bin/smbldap-migrate-unix-accounts
# zcat /usr/share/doc/smbldap-tools/examples/migration_scripts/\
\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-groups -a -G /tmp/group
# smbldap-migrate-unix-accounts -a -P /tmp/passwd\
\-S /tmp/shadow
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 devono 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.1, 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.55 si vede il risultato di un tentativo di accreditamento su un cliente GNU/Linux da parte dell'utente verdimarco:
|
Figura 9.55.
|
In figura 9.56 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.56.
|
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.57).
|
Figura 9.57.
|
Nella figura 9.58 è invece mostrato il modulo di gestione dei dati di un utente dell'elenco.
|
Figura 9.58.
|
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 per l'autenticazione e la cifratura della comunicazione tra clienti e serventi in rete.
TLS è l'evoluzione di SSL ma la natura del protocollo non è cambiata di molto; in questo paragrafo si fa riferimento unicamente a SSL considerando il fatto che il livello di sicurezza ottenibile è del tutto analogo e che nell'uso assieme a OpenLDAP l'unica differenza visibile è nel fatto che se si usa TSL il servizio continua a rispondere sulla porta 389 mentre con SSL risponde sulla porta 636.
SSL si colloca nella pila dei protocolli TCP/IP tra il livello di trasporto e il livello applicazione e viene usato per rendere sicuri i servizi che utilizzano TCP; l'utilizzo più comune e noto anche al «grande pubblico» è quello che permette di rendere sicuro il protocollo HTTP e quindi le connessioni con i serventi Web (protocollo HTTPS).
SSL utilizza un algoritmo a chiave privata per cifrare la comunicazione tra due nodi di rete; la chiave privata viene invece trasmessa in modo sicuro grazie a un algoritmo a chiave pubblica.
In questo paragrafo non vengono forniti tutti i dettagli riguardanti la configurazione di OpenSSL tramite il file /etc/ssl/openssl.cnf, l'uso del comando openssl e l'uso degli strumenti per la creazione e firma dei certificati disponibili in /usr/lib/ssl/misc/; viene solo mostrato quanto indispensabile per la creazione di certificati e chiavi per rendere sicura la comunicazione con il servente OpenLDAP.
Una volta installato il pacchetto OpenSSL con il comando:
# apt-get install openssl
occorre definire un certificato valido per il servente e quindi creare una CA (Certification Authority) che possa firmare tale certificato.
Questa CA non è evidentemente una di quelle globalmente riconosciute in rete e autorizzate alla diffusione dei certificati, ma solo una CA «personale».
Prima di definire il certificato possiamo impostare la durata dello stesso ad un periodo più lungo di quello impostato per difetto (1 anno); questo si fa modificando nello script /usr/lib/ssl/misc/CA.sh la seguente riga:
|
sostituendo il valore 365 ad esempio con 1825 (5 anni).
Creiamo poi una directory utile ad accogliere tutti i file contenenti certificati e chiavi che ci accingiamo a definire e posizioniamoci in essa (tale posizionamento rimane in essere per tutti i comandi di questo paragrafo):
# mkdir /etc/ssl/ca
# cd /etc/ssl/ca
Quindi generiamo la nostra CA con il comando:
# /usr/lib/ssl/misc/CA.sh -newca
Vengono richiesti il nome di un certificato (invio per definirne uno nuovo); e i dati relativi alla propria organizzazione che verranno inseriti nel certificato stesso.
Nella figura 9.60 viene mostrata questa fase di lavoro con delle risposte relative ad una organizzazione di tipo scolastico (l'ITIS «Max Planck» di Treviso dove insegno).
|
Figura 9.60.
|
Importantissima è la risposta alla domanda riguardante il common name: occorre indicare il FQDN Fully Qualified Domain Name della macchina che ospita il servente (nell'esempio serlinux3.max.planck).
Sono invece opzionali e possono essere omesse le informazioni challenge password e company name.
Prestare anche particolare attenzione, all'inizio, alla definizione della pass phrase da associare al certificato della CA e che viene poi chiesta ogni volta che si fanno operazioni con il certificato o che se ne richiede l'uso (ad esempio al termine di questa procedura come si vede nella figura).
Nella figura 9.61 viene mostrato come si conclude il procedimento con la stampa a video dei dati del certificato; quest'ultimo con la relativa chiave pubblica viene memorizzato nel file /etc/ssl/ca/demoCA/cacert.pem mentre la chiave privata della CA nel file /etc/ssl/ca/demoCA/private/cakey.pem.
|
Figura 9.61.
|
Il passo successivo consiste nella generazione del certificato di richiesta e della chiave privata per il servente, da compiere con il comando:
# openssl req -new -nodes -keyout newreq.pem -out newreq.pem
Si ricevono le richieste di inserimento informazioni analoghe alle precedenti (figura 9.60 ma solo fino alla richiesta relativa al optional company name).
|
Attenzione al fatto che il common name deve essere lo stesso FQDN inserito in sede di creazione del certificato della CA personale. |
Il certificato di richiesta e la chiave privata vengono memorizzate nel file /etc/ssl/ca/newreq.pem.
Si può controllare la richiesta con il comando:
# openssl req -text -noout < newreq.pem
A questo punto serve la firma della CA sul certificato di richiesta in modo da avere un certificato valido; la si ottiene con il comando:
# /usr/lib/ssl/misc/CA.sh -sign
Nella figura 9.62 vediamo l'effetto di tale comando con la richiesta della pass phrase relativa alla CA definita in precedenza e le richieste di conferma della firma e di memorizzazione del certificato.
|
Figura 9.62.
|
Il procedimento si conclude con l'emissione a video dei dati del certificato e della chiave pubblica che vengono memorizzati nel file /etc/ssl/ca/newcert.pem.
Conclusa la creazione del certificato e della chiave del servente spostiamo i relativi file nella directory di configurazione di OpenLDAP cambiando loro anche il nome:
# cp /etc/ssl/ca/demoCA/cacert.pem /etc/ldap/cacert.pem
# cp /etc/ssl/ca/newcert.pem /etc/ldap/servercrt.pem
# cp /etc/ssl/ca/newreq.pem /etc/ldap/serverkey.pem
Proteggiamo poi da accessi indesiderati il file contenente la chiave privata rendendolo contemporaneamente leggibile al gruppo openldap (si tenga presente infatti che il demone slapd viene eseguito con i diritti di utente e gruppo openldap):
# chown root:openldap /etc/ldap/serverkey.pem
# chmod 640 /etc/ldap/serverkey.pem
Per configurare OpenLDAP per l'uso di SSL bisogna fare in modo che il servente sia in ascolto sia sulla porta 389 che sulla porta 636 che è quella dedicata al traffico cifrato; a tale scopo interveniamo nel file /etc/default/slapd e attiviamo la riga:
|
Occorre poi intervenire sulla configurazione del servente, distinguendo, come al solito tra le vecchie versioni di OpenLDAP e quelle nuove (a partire dalla 2.3).
Nel primo caso si devono aggiungere le seguenti righe nel file /etc/ldap/slapd.conf tra le direttive globali:
|
Nel secondo caso si deve eseguire il comando:
# ldapmodify -Y EXTERNAL -H ldapi:///
con il quale si entra nella console del comando ldapmodify e si digita quanto segue:
|
Al termine, dopo un ulteriore pressione del tasto [Invio], si ottiene il messaggio «modifying entry cn=config» e si può uscire premendo [Ctrl c].
Infine, in entrambi i casi presi in esame, facciamo ripartire il servizio.
Il primo file che prendiamo in considerazione sulle macchine clienti (fra le quali, come al solito, possiamo considerare anche lo stesso servente) è /etc/ldap/ldap.conf (o /etc/ldap.conf) per fare in modo che i programmi lato cliente LDAP come ad esempio quelli del pacchetto ldap-utils dialoghino con il servizio sul canale cifrato:
|
Si noti l'attivazione delle interrogazioni usando il protocollo sicuro LDAPS con indicazione del FQDN della macchina servente, che deve essere lo stesso usato nella definizione dei certificati.
Inoltre è importante la direttiva TLS_REQCERT allow che fa in modo che il cliente possa richiedere il certificato della CA al servente evitando di doverne possedere una copia in locale.
Ricordarsi infine di far ripartire il demone nscd.
Per testare il buon esito delle modifiche eseguire qualche ricerca con ldapsearch sia usando il canale in chiaro:
# ldapsearch -x -b dc=max,dc=planck -H 'ldap://serlinux3.max.planck'
che quello cifrato:
# ldapsearch -x -b dc=max,dc=planck -H 'ldaps://serlinux3.max.planck'
Inoltre verificare che gli utenti gestiti dal servente siano ancora raggiungibili dal servizio NSS con il comando:
# getent passwd
Se si vuole che anche il traffico tra i serventi Samba e OpenLDAP avvenga con l'uso di SSL occorre apportare delle modifiche ai file di configurazione di Samba e del pacchetto smbldap-tools.
|
Notiamo che questo è necessario solo se i due serventi sono in esecuzione su due macchine diverse altrimenti si tratta di una precauzione esagerata. In tal caso infatti si può considerare una protezione ragionevole quella ottenibile configurando il servizio in modo che sia in ascolto sulla porta 389 (canale in chiaro, da usare per Samba) e sulla porta 636 (canale cifrato, da usare per i clienti GNU/Linux), come visto nel paragrafo 9.5.3. Si deve infatti tenere presente che la comunicazione tra i clienti MS-Windows e il servente Samba non avviene in chiaro a meno che non si usino macchine equipaggiate con MS-Windows 95. |
In /etc/samba/smb.conf bisogna aggiungere la riga:
|
e cambiare quella relativa al backend degli utenti in:
|
In /etc/smbldap-tools/smbldap.conf bisogna attivare l'uso dei certificati variando o attivando le righe seguenti:
|
Inoltre è bene fare in modo che il servente OpenLDAP sia in ascolto solo sulla porta 636 (nel contesto «ipersicuro» che stiamo definendo la 389 non serve più) e quindi variamo la riga SLAPD_SERVICES di /etc/default/slapd in modo che diventi:
|
Infine riavviamo i servizi Samba e OpenLDAP.
1) OpenLDAP OpenLDAP License, 2.3
3) webmin 3-clause BSD-style license
4) ldap account manager GNU GPL
