Sistemi Aperti
SAMBA 2.2.2: il Domain Controller per una rete Microsoft
Introduzione
In qualsiasi organizzazione lavoriate, è altamente probabile che vi verrà
richiesto un server di rete, che funga ALMENO da file e print server.
Ad oggi, la maggior parte delle aziende preferiscono un'architettura basata su
Windows 2000 Server, con Active Directory, ecc.
Questo articolo vuole
mostrare una alternativa reale, valida e di bassissimo costo, basata su Linux
e sulla nuova versione di SAMBA.
Qualche considerazione
I pregi di un domain controller in una rete Microsoft sono, a mio avviso, innegabili:
gestione centralizzata degli account, ACL (Access Control List) molto granulari,
file e print sharing estremamente ben integrati coi sistemi operativi più diffusi per
le workstation...
D'altro canto, i vantaggi di un server Linux sono ben noti: basso costo (se non
addirittura nullo), minor manutenzione, maggior stabilità e flessibilità, ecc. (spero che questi non
vengano considerati pareri personali, ma dati di fatto!!)
Poter utilizzare una macchina Linux come PDC, quindi, significa:
- offrire tutti i vantaggi dell'appartenenza a un dominio
- sfruttare al massimo le ACL
- ridurre i costi di amministrazione e manutenzione
- ridurre drasticamente i costi di licenza
- migliorare, a parità di hardware, le prestazioni complessive
Per chi ha qualche dubbio, e pensa che la soluzione possa essere un ripiego,
rimando a un
articolo di PcMagazine... Ve lo consiglio!
In principio era il file sharing...
SAMBA nasce per offrire i servizi di file e print sharing anche ai sistemi
operativi Microsoft. Correva la versione 2.0.x, e SAMBA permetteva di utilizzare
una macchina Linux come file e print server. Poteva addirittura svolgere le
funzioni di Domain Controller (quindi browsing di rete e logon server),
ma solo per client Windows 9x. La vera novità sta nella versione 2.2.x: ora l'evoluzione
è quasi completata! Anche client NT, Win2K e XP possono utilizzare il nostro
Linux come Domain Controller (no, il pinguino non si è venduto, tranquilli...)!
Vorrei sottolineare il "quasi", in quanto non sono ovviamente disponibili tutti
quei servizi (sulla cui utilità non intendo assolutamente entrare in merito...)
offerti da Active Directory.
L'ambiente di test
Ci tengo a precisare che le soluzioni presentate in questo articolo sono tutte
realmente implementate in ambiente di produzione (e senza che gli utenti si siano accorti
del trucco!).
Il nostro server è un PC assemblato, per i dettagli tecnici vi rimando all'appendice B.
La distribuzione utilizzata è una RedHat 7.1: questa scelta è stata dettata da
banali preferenze personali.
Installazione
Procediamo ad una installazione ex-novo del sistema
operativo: le cose su cui focalizzarci sono il partizionamento del disco e i servizi da installare.
Consiglio di non utilizzare il partizionamento automatico: a mio avviso è molto comodo (e decisamente
più sicuro) "arginare" tutto il file system condiviso in una unica partizione, che monteremo
ad esempio come /share. Generalmente io consiglio anche di separare i mountpoint / e /var, ma
ovviamente non è indispensabile.
Al momento di selezionare i servizi, io consiglio vivamente di installare meno roba possibile. Anche
l'interfaccia grafica è superflua (esistono tools per l'amministrazione remota via web!). Soprattutto, non
è necessario selezionare la connettività DOS/Windows (installeremo una versione di SAMBA totalmente
differente!).
Una volta completata l'installazione, ed eventualmente proceduto all'hardening del sistema (vedi
appendice A), occorre fare un paio di modifiche alla struttura delle home degli utenti (in modo da
ritrovarcele direttamente nella cartella /share). Creiamo una cartella /share/home e poi facciamo in modo
che la vecchia /home punti a questa; loggati come root, scriviamo:
mkdir /share/home
chmod go+x /share/home
(nel caso durante l'installazione siano stati creati degli utenti, spostarne la relativa home nella nuova posizione)
rm -f /home
ln -s /share/home /home
rm -rf /etc/skel/* /etc/skel/.*
mkdir /share/public
mkdir /share/netlogon
In pratica, abbiamo creato una cartella /share/home e abbiamo creato un link simbolico ad essa al
posto della vecchia. Abbiamo inoltre rimosso tutto il contenuto di /etc/skel, in modo che d'ora in poi ogni nuovo utente
verrà creato con la home directory vuota. Creiamo anche le cartelle /share/public e /share/netlogon
Passiamo ora alla installazione di SAMBA: scarichiamo innanzitutto la versione più recente, magari già in
formato binario (samba-2.2.2.rpm, circa 10 Mb).
Questo rpm include già sia la parte client che quella server, oltre all'insostituibile utility SWAT, per la gestione del
server. Verifichiamo di non avere nessuna versione di SAMBA precedentemente installata (essendo pacchetti differenti,
consiglio di evitare l'aggiornamento, ma procedere ad una installazione "pulita"):
rpm -qa |grep samba
e se davvero non abbiamo nulla, installiamo quanto appena scaricato da Internet.
Configurazione
D'ora in avanti, ci riferiremo al nostro server come SMBSERVER. Modifichiamo i file /etc/hosts (in linux) o lmhosts
(in windows), aggiungendo la riga
SMBSERVER ip_del_nostro_server_linux
Andiamo quindi a modificare il file
/etc/xinetd.d/swat in modo da abilitare il servizio, e permettere le connessioni dall'IP della vostra macchina:
# default: off
# description: SWAT is the Samba Web Admin Tool. Use swat \
# to configure your Samba server. To use SWAT, \
# connect to port 901 with your favorite web browser.
service swat
{
disable = no
port = 901
socket_type = stream
wait = no
user = root
server = /usr/sbin/swat
log_on_failure += HOST
}
Per iniziare a lavorare, apro il mio browser preferito e vado all'indirizzo http://SMBSERVER:901
Se abbiamo fatto le cose per bene, si aprirà una finestra in cui mi vengono chiesti username e password.
Forniamo le credenziali di root (in futuro, consiglio di creare un utente ad hoc), ed eccoci!!
Ammetto che configurare da zero un server può essere, per i neofiti, una operazione lunga e faticosa, per cui
vi rimando all'Appendice D, in cui riporto un file di esempio. Spendiamo due parole però su alcuni parametri
fondamentali o interessanti: innanzitutto, ricordiamoci che per poter utilizzare SAMBA come logon server, è
NECESSARIA una share netlogon; io poi consiglio di renderla non scrivibile (in un futuro potrete utilizzarla
per rendere disponibili i logon script!).
Il parametro "workgroup" stabilisce il nome del dominio; è inoltre necessario settare a yes i parametri
"encrypt passwords" e "update encrypted" (che gestiscono il tipo di crittografia durante l'autenticazione).
Impostare il parametro "os level" ad un valore superiore a 20 fa si che il server vinca automaticamente
le elezioni per il controller di dominio.
La share "homes" fa in modo che, automaticamente, un utente si ritrovi la sua home directory condivisa, a suo uso
esclusivo. Il parametro "browseable = No" fa si che ognuno possa vedere solo la propria.
L'ultimo passo è la creazione degli account: la gestione degli account e delle password è forse la parte più
complessa di SAMBA, ma a mio avviso anche quella più interessante! In Appendice C si spiegano meglio l'architettura
ed alcuni trucchetti, ma per chi è impaziente, di seguito riporto i passi fondamentali.
Chi si è confrontato con reti Microsoft sa che, oltre agli account utente, vanno creati nel dominio anche i machine
account per i computer WinNT o 2000. Nel file di configurazione abbiamo impostato i parametri per farlo in
automatico (add user script e passwd program), direttamente dalle macchine Microsoft al momento in cui
ci si unisce a un dominio. Io comunque consiglio di farlo a mano, con i seguenti comandi:
/usr/sbin/useradd -d /dev/null -g 100 -c"descrizione della macchina" -s /bin/false nome_macchina$
passwd -l nome_macchina$
smbpasswd -a -m nome_macchina
Fate attenzione ai simboli "$" dove presenti!!! Per la creazione degli account utente, la filosofia è la stessa:
/usr/sbin/useradd -d /dev/null -g 100 -c"descrizione utente" -s /bin/false nome_utente
smbpasswd -a nome_utente
Vi verrà chiesto di immettere la password, e il gioco è fatto!! Ultimo consiglio: create anche un utente "smbguest",
che servirà alle macchine Win9x per il browsing della rete.
Conclusioni
In questo articolo si è discusso sulla possibilità di utilizzare un server Linux come server di Dominio in una
rete Microsoft. I vantaggi di tale soluzione sono stabilità, prestazioni, bassi costi di manutenzione, nessun costo
di licenza. La versione attuale di SAMBA (2.2.2) permette l'integrazione di macchine Win9x, ME, NT4 e Windows2000;
supporta le ACL secondo il modello di WindowsNT, ed ha una ottima utility di amministrazione accessile via web.
Il prezzo da pagare è l'assenza di tutti i servizi legati ad Active Directory.
di Tommaso Di Donato
Appendice A:
Un minimo di sicurezza...
Inutile dire che, al termine dell'installazione, sarà necessario un upgrade di molti pacchetti (si sa, i bug
esistono...); oltre a questo, vale la pena disabilitare i servizi superflui: per un domain contoller SAMBA
consiglio di mantenere solo atd, crond, keytable, lpd, network, random, sshd, syslog e xinetd.
Per chi è interessato ad approfondire l'hardening post-installazione, consiglio
Securing & Optimizing Linux
(Ringraziamo tutti quanti OpenDocs!!!)
Appendice B:
un server per applicazioni mission critical molto economico
Purtroppo o per fortuna, fin dal mio primo impiego ho sempre avuto a che fare con
sistemi mission critical, che quindi necessitavano di fault tolerance e tempi di
down tendenti a zero... Questo, ahimè, difficilmente si sposa con il nostro budget.
Per il server dell'articolo è stato utilizzato un controller IDE 3Ware Escalade,
della famiglia 6000. Esso permette un RAID 0,1,5 hardware, gestisce gli spare disk
(hot swap), ed è completamente supportato a livello di kernel! Utilizza normali dischi IDE
(quindi di basso costo), ed è fornito assieme ad una pratica utility di monitoraggio/manutenzione
ad interfaccia Web. Unico difetto: non gestisce (ancora) i dischi ATA100, ma
solo ATA66.
Appendice C:
la gestione degli utenti in SAMBA
Parlando di SAMBA, il file /etc/samba/smbpasswd è l'analogo di /etc/passwd per il sistema operativo; in pratica, perché un
utente si possa collegare, lo dobbiamo aggiungere a questo file. La confusione può nascere da questo: ogni utente
in smbpasswd deve essere anche utente di s.o., ma solo gli utenti in smbpasswd potranno connettersi al dominio utilizzando SAMBA.
Un esempio: nella mia LAN, io devo fare accedere l'utente "mario". Per fare ciò, io dovrò aggiungere mario come utente di s.o.
tramite /usr/sbin/useradd; poi, lo aggiungerò anche come utente SAMBA. Nel file /etc/passwd troviamo molti altri utenti, ad esempio
ftp, games, rpcuser, ma questi non li ho aggiunti a /etc/samba/smbpasswd, e quindi non esistono a livello di
dominio.
Per aggiungere gli utenti al file, devo usare il comando
/usr/bin/smbpasswd nome_utente
e mi verrà chiesto di immettere la password dell'utente; questa può benissimo essere differente da quella di s.o.!! Comunque, nel caso
si decida che password di s.o. e di SAMBA devono coincidere, è possibile tenere allineate eventuali modifiche (che possono venire
effettuate dagli utenti direttamente tramite gli strumenti in Windows) settando a "yes" il parametro unix password sync.
Appendice D:
il file /etc/samba/smb.conf
# Global parameters
[global]
workgroup = DOMINIO
netbios name = SMBSERVER
server string = Samba PDC
encrypt passwords = Yes
update encrypted = Yes
allow trusted domains = No
min passwd length = 4
passwd program = /usr/bin/passwd %u
passwd chat debug = Yes
username map = /etc/samba/user.map
password level = 0
username level = 4
log file = /var/log/samba/log.%m
max log size = 50
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
add user script = /usr/sbin/useradd -d /dev/null -g 100 -s /bin/false -M %u
domain logons = Yes
os level = 65
preferred master = True
domain master = True
dns proxy = No
guest account = smbguest
load printers = Yes
[netlogon]
path = /share/netlogon
create mask = 0700
security mask = 0700
directory mask = 0700
directory security mask = 0700
[public]
comment = Cartella Condivisa
path = /share/public
read only = No
guest ok = Yes
[homes]
guest ok = no
read only = no
create mask = 0700
directory mask = 0700
browseable = No
