Samba e OpenLDAP: creare un controller di dominio con Debian Etch: differenze tra le versioni

* Debian Etch 4.0

* Per Debian Sarge 3.0 vedi: [[Samba e OpenLDAP: creare un controller di dominio]]

* Per Debian Lenny 5.0 vedi: [[Samba e OpenLDAP: creare un controller di dominio con Debian Lenny]]

Questo articolo è un aggiornamento della guida [[Samba e OpenLDAP: creare un controller di dominio]], basata su '''Debian Sarge'''.<br/>

Vedremo questa volta come installare un server basato su '''Debian Etch''' e Samba 3 con backend di un database LDAP, affinché funga da Primary Domain Controller di una rete Windows. Lo stesso server LDAP verrà utilizzato anche per la gestione in contemporanea degli utenti Unix, in modo da avere un controllo unico e centralizzato sia sugli utenti Windows sia sugli utenti Linux.<br/>

Consiglio vivamente di prepararsi una buona tazza di caffé e di armarsi di pazienza e di molta attenzione, dato che un errore di battitura in qualche file di configurazione può mandare in rovina l'intero lavoro: poichè che i files da modificare saranno molti, di certo risulterebbe molto difficile e molto lungo andare a caccia di eventuali errori.<br/>

Il presente HOWTO è stato realizzato utilizzando un sistema Debian 4.0 Etch con tutti gli aggiornamenti di sicurezza ufficiali.  

La configurazione iniziale del sistema prevede un'installazione base Debian net install senza alcun componente aggiuntivo.<br/>

Durante tutto il processo si presuppone di agire come utente root.

<br/>

In tutta la guida saranno utilizzati i seguenti parametri per la configurazione della rete:

* Nome del server: server

* Password admin di LDAP: password

Questi parametri vanno ovviamente adattati alle vostre esigenze.

Il server LDAP è essenzialmente un database gerarchico che viene utilizzato per la memorizzazione dei dati degli utenti, dei computer del dominio e di tutto quanto si desideri gestire tramite una base dati condivisibile via rete tra più sistemi.<br/>

Si considera che il server in questione venga utilizzato all'interno di una rete aziendale altamente affidabile e non verranno, pertanto, trattati gli aspetti relativi alla crittografia delle comunicazioni. Questa scelta riduce la sicurezza, pertanto si consiglia di approfondire l'argomento.<br/>

Se ottenete le informazioni sul dominio significa che tutto è andato per il verso giusto; se ottenete un messaggio del genere "ldap_bind: Can't contact LDAP server (-1)" vi conviene eseguire nuovamente la configurazione di OpenLDAP.

Sebbene si possa amministrare OpenLDAP in maniera completamente testuale (nel corso della guida vedremo come) è consigliabile installare un'interfaccia grafica, che aiuterà a svolgere i normali compiti di amministrazione una volta terminato di configurare il dominio.<br/>

Nei repository Debian sono disponibili diverse interfacce grafiche. In questa guida la scelta è caduta su '''phpldapadmin''', che sembra essere la più diffusa.<br/>

L'ultimo comando dovrebbe restituirvi l'elenco delle opzioni disponibili in mkntpwd.

L'installazione di Samba va effettuata in questo momento perchè insieme ai pacchetti stessi di Samba saranno installate anche alcune utility che adopereremo nel paragrafo successivo.

<pre>

<br/>

I smbldap-tools sostituiscono i comandi standard di UNIX per la gestione di gruppi, utenti e password in modo da dialogare direttamente con il server LDAP e fornire un metodo per gestire in contemporanea gli account UNIX e SAMBA.<br/>

Malgrado la documentazione ufficiale di SAMBA asserisca che smbpasswd sia in grado di gestire tali account, utilizzando quello strumento occorre prima creare l'utente UNIX, poi quello Samba, pertanto ne sconsiglio l'utilizzo.

Installare il pacchetto smbldap-tools

<pre>

# apt-get install smbldap-tools

</pre>

Copiare i file <tt>smbldap.conf</tt> e <tt>smbldap_bind.conf</tt> in <tt>/etc/smbldap-tools</tt>.

<pre>

</pre><br/>

Passiamo ora alla configurazione del server LDAP.<br/>

Innanzitutto dobbiamo copiare in <tt>/etc/ldap/schema</tt> lo schema LDAP necessario per SAMBA.

<br/>

Ogni volta che un client accede ad un server LDAP deve impostare la base di ricerca e, nel caso si trovi su un server differente, l'URL del server LDAP. Queste informazioni possono essere impostate come default nel file <tt>/etc/ldap/ldap</tt>.conf aggiungendo le righe:

<pre>

che dovrebbe fornire tutti i dati presenti nel server LDAP. Sempre pochi, ma in numero maggiore rispetto a quanto elencato la volta precedente.

<br/>

Prima di iniziare a configurare Samba è necessario creare le directory nelle quali risiederanno le homes degli utenti, gli script di netlogon e i profili centralizzati (o profili roaming). Alcune di queste directory sono già state indicate nel file <tt>/etc/smbldap-tools/smbldap.conf</tt>, quindi è bene stare attenti a non commettere errori.<br/>

<pre>

</pre>

Per un funzionamento corretto SAMBA ha bisogno di diversi gruppi predefiniti e 2 utenti: Administrator e nobody.<br/>

La tabella seguente riepiloga i gruppi e gli utenti di default di un dominio Windows:

Inoltre, affinché si riesca ad aggiungere computer al dominio in modo automantico (da macchine Windows), deve esistere un utente con uid = 0 da utilizzare per questa operazione. Tale utente può essere un utente root (da aggiungere a mano) o lo stesso Administrator cambiandogli l'uid. Quest'ultima è la scelta presa in questa configurazione, in modo da avere un utente Administrator che è Administrator per Samba e root per il "dominio" UNIX.

Per creare i gruppi predefiniti e gli utenti utilizzati da Samba è possibile procedere in due modi.

La prima via consiste nel fare uso di alcuni script forniti con il pacchetto <tt>smbldap-tools</tt> che abbiamo già installato:

<pre>

Questo sarà anche il comando che dovrà essere normalmente utilizzato per la gestione delle password.

Il secondo metodo prevede l'utilizzo della GUI di phpLDAPadmin. Per operazioni così lunghe e ripetitive come il popolamento iniziale di un database LDAP è un metodo che sconsiglio, ma può essere utile a questo punto osservare il funzionamento di questa GUI.<br/>

Innanzitutto bisogna collegarci con un browser al nostro server:

</pre>

A questo punto occorre configurare il nostro server affinchè veda gli utenti LDAP come normali utenti unix di sistema.

Poichè il nostro server LDAP sarà consultato in maniera continuativa, potrebbe essere una buona idea installare un servizio di cache per alcuni dati degli utenti. In questo modo i dati contenuti in cache saranno forniti senza eseguire un accesso al database LDAP, velocizzando di conseguenza i tempi di risposta del server. Il demone nscd (name service caching daemon) esegue esattamente questa cosa:

<pre>

</pre>

Per prima cosa installeremo il pacchetto libnss-ldap, con il classico comando:

<pre>

</pre>

L'installazione del pacchetto libpam-ldap viene eseguita allo stesso modo di quella precedente:

<pre>

</pre>

Affinchè le directory dei profili e altre cosette funzionino senza intoppi è necessario assegnare i giusti permessi agli utenti di dominio:

<pre>

dove DEBIAN è il nome Samba assegnato al server.

Adesso siamo pronti per la creazione del primo utente con il comando:

<pre>

</pre>

E' possibile creare uno script "logon.bat" (come specificato nel file /etc/smbldap-tools/smbldap.conf) da mettere nella cartella indicata per la condivisione netlogon. Questo script conterrà alcuni comandi che saranno eseguiti all'avvio dei client Windows.  

Tale script dovrà esser scritto in modalità dos, per far questo sfrutteremo il tool unix2dos contenuto nel pacchetto tofrodos.

Tenete conto che con queste impostazioni viene già creata un'unità di rete collegata alla home dell'utente linux.

Il nostro server è ora pronto per essere utilizzato. Per testarne le funzionalità è possibile procedere per gradi, in modo da isolare quelli che sono i problemi di configurazione da quelli che sono i problemi di rete o dei client Windows.<br/>

A tal fine il primo accesso può essere fatto dal server stesso con il comando:

# Non ancora testato.

Nel caso si disponga di un secondo server e si voglia utilizzare un unico database degli utenti è possibile seguire 2 strade differenti:

# Configurare il secondo server per accedere a LDAP seguendo le indicazioni esposte per il server di dominio, ovviamente senza farlo diventare server di dominio, ma con autenticazione degli utenti

A questo punto è possibile creare share e assegnare permessi in base a utenti e gruppi definiti nel dominio.

Vengono suggeriti di seguito alcuni metodi per effettuare dei backup del database LDAP. Consiglio di prendere seriamente in considerazione l'idea di impostare dei backup regolari magari tramite cron e suggerisco altresì di effettuare '''sempre''' un backup dei dati LDAP prima di ogni modifica o riconfigurazione del server.

Un offline physical backup deve essere effettuato sul server stesso. Lo svantaggio di questo tipo di backup è che il server LDAP non sarà disponibile per l'intera durata del processo.

# Stopare il server LDAP: <tt>/usr/sbin/rcldap stop</tt>

# Riavviare il server LDAP: <tt>/usr/sbin/rcldap start</tt>

Questo tipo di backup, noto anche come '''database dump''' richiede sempre l'arresto del servizio LDAP:

# <tt>/usr/sbin/rcldap stop</tt>

# <tt>/usr/sbin/rcldap start</tt>

Questo tipo di backup, a differenza dei precedenti, utilizza LDAP stesso per effettuare il dump dei dati del database e quindi, pur appensantendo il server, non richiede l'arresto del servizio.

# <tt>ldapsearch -h LDAPServer -x -b baseDN > ldap.\$(date +'\%Y\%m\%d-\%T')</tt><br/>

dove <tt>LDAPServer</tt> è il nome del server e <tt>baseDN</tt> è il distinguished name (DN) della struttura LDAP, nel nostro caso <tt>dc=dominio,dc=local</tt>

# Per ripristinare un offline backup:

## <tt>/usr/sbin/rcldap stop</tt>

dove <tt>adminDN</tt> è nel nostro caso dn=admin,dc=dominio,dc=local

Se siete interessati a fornire ridondanza alla vostra rete, potete prendere in considerazione l'idea di inserire un secondo server OpenLDAP sincronizzato con il server principale che abbiamo appena configurato.<br/>

In tal caso suggerisco di seguire [[Implementare un'architettura ridondante master/slave OpenLDAP | questa guida]], nella quale viene utilizzato lo stesso database LDAP che abbiamo appena configurato per costruire un server di replica.

OpenLDAP ha la brutta abitudine di non risistemarsi per bene quando la donna delle pulizie inciampa nell'interruttore generale della corrente. Perciò conviene installare:

<pre>

Questo pacchetto contiene l'utility db4.2_recover che viene lanciata automaticamente ad ogni restart di ldap, risolvendo eventuali problemi di incongruenza del Barkley DB.

<br/>

Altre due interfacce grafiche comode, da utilizzare congiuntamente o in alternativa a phpldapadmin, sono gosa e ldap-account-manager.

* '''LDAP-Account-Manager'''

''To do''

<pre>

# smbldap-useradd -a -m -c "Descrizione Utente" -u 100xx nome.utente

</pre>

<pre>

# smbldap-groupadd -g 500xx "NomeGruppo"

</pre>

Per impostare il gruppo primario dell'utente:

<pre>

</pre>

<pre>

# ldapsearch -x objectClass=posixGroup

</pre>

<pre>

# smbldap-groupshow "gruppo"

</pre>

<pre>

smbclient //nomeserver/nomecartella -U nome.utente%password.utente -N -Tc backup.tar /percorso/locale/del/backup

</pre>

<pre>

smbclient -L nomeserver

</pre>

<pre>

   slapcat -l /tmp/backup.ldif     

   slapadd -c -l /tmp/backup.ldif

</pre>

<pre>

ldapsearch -b "dc=miodominio,dc=local" -x

</pre>

Nel caso si reinstalli slapd controllare non ci sia un backup in /var/backups con lo stesso numero di versione, altrimenti un dpkg.reconfigure non ricrea il file di configurazione corretto.

[[Samba e OpenLDAP: creare un controller di dominio]]<br/>

[[Samba e OpenLDAP: creare un controller di dominio con Debian Etch]]<br/>