Le reti miste Linux/Windows/Apple sono oggigiorno abbastanza diffuse grazie allo sviluppo di software che consentono l'interoperabilità tra diversi sistemi operativi. In particolare non è raro trovare un server Linux all'interno di una rete Windows e talora, anche se con minor frequenza, client Linux che si integrano in domini Windows. Lo strumento fondamentale per collegare un host Linux ad una rete Microsoft è sicuramente Samba.
In queste pagine prenderemo in considerazione un particolare aspetto del problema, ovvero ottenere che sia il login sulla macchina Linux, che l'accesso alle condivisioni Samba avvengano mediante autenticazione sul database centralizzato Active Directory (AD). Risulta evidente il vantaggio di poter gestire le utenze senza dover creare account locali.
Partiremo dal presupposto di avere un Dominio Active Directory funzionante con un Domain Controller che lo gestisce chiamato server.miodominio.local. Tale server svolgerà anche la funzione di DNS all'interno della rete Microsoft. Ipotizzeremo che tale macchina abbia indirizzo IP 192.168.0.1 e, naturalmente, di essere in possesso delle credenziali di administrator.
Ad esso collegheremo una Linux box Fedora 11 a 64 bit, chiamata sambaserver.miodominio.local, cui possiamo accedere con i privilegi di root. Il ruolo assunto da questo host all'interno della rete potrebbe essere quello di file server o di print server, come accennato non ha molta rilevanza rispetto agli obbiettivi che ci proponiamo.
Gli strumenti che utilizzeremo saranno:
- Samba 3.3
- Kerberos 5
- NTP (Network Time Protocol)
- Nsswitch (Network Services Switch)
- Il sistema di autenticazione PAM (con molta, moltissima attenzione!)
Prima di iniziare è consigliabile disattivare Firewall e SELinux ovvero tutto ciò che possa eventualmente fuorviarci nei nostri test di comunicazione. Una volta terminata e verificata la configurazione potremo rialzare le barriere.
Sincronizziamo gli orologi
Poiché il funzionamento di Kerberos è strettamente legato al tempo, dobbiamo garantire che l'orologio del nostro host Linux sia sincronizzato con quello del server che gestisce l'Active Directory. Quest'operazione viene fatta in automatico dai client Windows, per ottenere un comportamento simile ricorreremo al Network Time Protocol, NTP. Il demone ntpd ha il compito di gestire tale protocollo client-server, nato proprio per sincronizzare gli orologi all'interno di una rete a commutazione di pacchetto. Ora assumiamo i privilegi di root, apriamo il file di configurazione /etc/ntp.conf e cerchiamo la sezione che riporta le direttive "server". Commentiamole ed aggiungiamo la riga: server <nome del server ad>. Al posto del nome potremmo tranquillamente usare il suo indirizzo IP:
A questo punto avviamo o riavviamo il servizio se era già attivo:
[root]# service ntpd start
Per attivarlo automaticamente al boot della macchina portiamolo a on nei run level che ci interessano, ad esempio:
[root]# chkconfig --level 345 ntpd on
Vediamo ora un paio di configurazioni che non hanno nulla a che fare con la sincronizzazione, ma utili al funzionamento del nostro sistema. Per utilizzare server.miodominio.local come DNS primario inseriamo in testa a /etc/resolv.conf la riga seguente:
Se poi vogliamo essere certi che eventuali cedimenti del sistema DNS non inficino la nostra connessione alla rete, possiamo inserire il server Windows anche all'interno del file /etc/hosts
Kerberos
Kerberos è un protocollo client/server nato per gestire l'autenticazione su una rete insicura. È stato originariamente sviluppato, ed è tuttora mantenuto, dal MIT che lo distribuisce con una licenza stile BSD. Nel tempo sono nate alcune implementazioni commerciali del protocollo: una variante viene utilizzata dai sistemi Windows come metodo predefinito di autenticazione.
Deve il suo nome al mitico cane a tre teste, Cerbero, che per gli antichi greci sorvegliava l'ingresso agli inferi. Il meccanismo di comunicazione tra due entità si basa, infatti, su una terza parte considerata affidabile e che ha il compito di Authentication Server e Ticket Granting Server.
Ogni entità sulla rete condivide con l'Authentication Server una propria chiave segreta che può così identificarla. I "biglietti", ticket, successivamente rilasciati dal server servono a provare l'identità degli utenti ed hanno una data di scadenza. Per questo come primo passo abbiamo fatto ricorso al protocollo NTP.
Per cifrare la comunicazione tra due entità, il server Kerberos genera una chiave di sessione, che viene utilizzata da ambo le parti. Questo, in forma molto semplificata, il meccanismo alla base del protocollo, per approfondimenti rimando al link ad inizio pagina ed alla documentazione presente in rete. In particolare segnalo un dialogo didattico semplice ma incisivo che descrive lo sviluppo del sistema di autenticazione.
Dopo questa breve premessa assicuriamoci che sulla nostra macchina Linux siano già installati i pacchetti krb5-libs e krb5-workstation, altrimenti facciamolo utilizzando YUM. Successivamente passiamo alla modifica del file /etc/krb5.conf...dopo averne fatta una copia di backup naturalmente.
Mi raccomando prestate molta attenzione all'uso corretto di maiuscole e minuscole
Per provare la nuova configurazione basta dare il seguente comando:
[root]# kinit administrator@MIODOMINIO.LOCAL
In risposta dovremmo ricevere la richiesta di password per l'account administrator. Digitiamola e, se tutto funziona correttamente, avverrà il collegamento. Con il comando:
[root]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: administrator@MIODOMINIO.LOCAL
Valid starting Expires Service principal
09/10/09 14:17:56 09/11/09 00:13:06 krbtgt/MIODOMINIO.LOCAL@MIODOMINIO.LOCAL
renew until 09/11/09 14:17:56
Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached
potremo visualizzare tutte le informazioni relative al ticket kerberos rilasciato dal server.
In caso di malfunzionamento controllate eventuali errori di digitazione in /etc/krb5.conf, specie l'uso delle maiuscole. Verificate inoltre la corretta sincronizzazione tra ora del server e del client.
Samba
Samba, come è noto, è una libera implementazione della suite di protocolli SMB/CIFS che consente di far interagire un host Linux (Unix-like in generale) con client o server Windows. Il software è costituito da un insieme di programmi che forniscono diverse funzionalità, tra questi spiccano in particolare tre moduli: smbd, nmbd e winbindd.
I primi due sostanzialmente consentono la condivisione dei file utilizzando il protocollo SMB: da una qualunque macchina Windows si potrà avere accesso ai file della macchina Linux in modo del tutto trasparente. Winbind, invece, consente la condivisione di account e l'autenticazione sulla rete. In pratica rende visibili ad un sistema Linux gli utenti del Dominio Windows.
Per elencare tutti i pacchetti rpm relativi a Samba digitiamo:
[root]# yum list samba-*
Tra questi installiamo almeno samba.x86_64, samba-winbind.x86_64, samba-common.x86_64 e samba-client.x86_64.
[root]# yum install samba.x86_64 samba-winbind.x86_64 samba-common.x86_64 samba-client.x86_64
Terminata l'operazione dobbiamo procedere alla configurazione del servizio, ma questo sarà oggetto della seconda parte dell'articolo.
La prima parte dell'articolo si era chiusa con l'installazione di Samba, procediamo ora alla sua configurazione.
Il file su cui agire è /etc/samba/smb.conf, ricordiamoci di fare la consueta copia dell'originale prima di apportare modifiche. Di seguito trovate una configurazione esemplificativa: esamineremo in dettaglio il primo gruppo di direttive della sezione "global", le rimanenti sono generiche e non verranno prese in considerazione. Ricordo infatti che l'obbiettivo primario è autenticarci sull'AD, mentre la configurazione delle condivisioni è, in questa sede, del tutto marginale.
Con le prime due direttive, workgroup realm
Ponendo a no il valore di preferred master server string
La direttiva security = ADS Encrypt passwords
Assegnando il valore Yes a winbind enum users winbind enum groups
Con winbind use default domain username MIODOMINIOusername MIODOMINIO+username
In situazioni complesse in cui nell'AD siano definiti gruppi annidati dobbiamo ricorrere all'opzione winbind nested groups = Yes
Per impostare il carattere "+" come separatore tra dominio e username ricorriamo alla direttiva winbind separator MIODOMINIO+username
Le direttive idmap uid idmap gid
La direttiva template primary group = "Domain Users"
Infine con template shell = /bin/bash
Per verificare la sintassi del file di configurazione ricorriamo al comando:
[root]# testparm
Correggiamo eventuali errori segnalati, ignorando il warning relativo all'uso del carattere "+". Quando tutto è a posto facciamo partire i demoni:
[root]# service smb start [root]# service nmb start [root]# service winbind start
Join al Dominio
A questo punto tutto è pronto per effettuare il collegamento della Linux box con Samba al Dominio Windows. Al prompt dei comandi digitiamo:
[root]# net ads join -U Administrator
Inseriamo la password per l'utente administrator e riceveremo un messaggio che conferma l'avvenuto "join".
Per sicurezza è consigliabile effettuare alcune verifiche. Possiamo accedere al Domain Controller e controllare che, sfogliando l'AD, sotto la voce "Computers" compaia la nostra macchina Linux denominata sambaserver.
Digitando:
[root]# net ads testjoin
possiamo testare la connessione all'Active Directory. Con:
[root]# wbinfo -u [root]# wbinfo -g
proviamo ad enumerare utenti e gruppi del Dominio. Ricordo le considerazioni fatte in precedenza rispetto alla numerosità di utenti e gruppi. Per verificare l'autenticazione di un particolare utente possiamo usare il comando:
[root]# wbinfo -a nomeutente%password
Nsswitch e Winbind
Dobbiamo fare in modo che, al momento dell'autenticazione, venga controllata la lista degli utenti e gruppi fornita da Winbind. Onde evitare problemi è vivamente consigliato che non esistano omonimie tra utenti dell'AD ed utenti locali. Andremo dunque a modificare il file /etc/nsswitch.conf, ma solo dopo la consueta copia di backup. Tale file, Network Services Switch, indica dove e con che ordine effettuare le ricerche quando viene richiesta una certa informazione.
Le prime tre righe sono fondamentali per i nostri scopi mentre le rimanenti possono variare a seconda della configurazione del proprio sistema. L'aggiunta della parola chiave winbind
Per terminare verifichiamo che che nella directory /lib64 (stiamo usando una versione a 64 bit del sistema operativo altrimenti sarebbe /lib) siano presenti i seguenti file e corrispondenti symlink:
libnss_winbind.so.2 libnss_wins.so.2 libnss_winbind.so libnss_wins.so
Con i seguenti comandi dovremmo ora vedere utenti e gruppi dell'AD subito dopo utenti e gruppi locali:
[root]# getent passwd [root]# getent group
Modifichiamo PAM
Quella che segue è in assoluto la parte più delicata e pericolosa della configurazione: un errore potrebbe impedire l'accesso alla macchina. Procedete a vostro rischio e pericolo!
Per sicurezza colleghiamoci da un altro Pc via ssh alla Linux box con due console ed in ciascuna assumiamo i privilegi di root. Questo serve a garantirci la possibilità di ripristinare le modifiche effettuate in caso di malfunzionamenti, la seconda console rappresenta il paracadute di riserva. Durante tutta la fase di configurazione e test evitiamo assolutamente di riavviare la macchina.
Il file che dovremo modificare è /etc/pam.d/system-auth, in realtà un link a /etc/pam.d/system-auth-ac di cui facciamo subito una copia di backup. Anzi per maggiore tranquillità possiamo copiare l'intera directory pam.d. Di seguito una possibile configurazione adatta ai nostri scopi:
Chiaramente le direttive su cui principalmente puntare l'attenzione sono quelle che si riferiscono a pam_winbind.so. La terzultima direttiva consente la creazione automatica della home directory al momento del login, che sarà /home/MIODOMINIO/username
Se stessimo lavorando con una precedente versione di Fedora, ad esempio la 10, potremmo fermarci qui. Con la 11 avremo invece dei problemi con GDM (GNOME Display Manager), il programma per la login grafica di Gnome, pur potendo autenticarci senza problemi da una console. L'introduzione dei plug-in che permettono l'autenticazione mediante fingerprint e smartcard, oltre a username/password, ha originato nuovi file in /etc/pam.d fingerprint-auth password-auth smartcard-auth password-auth
auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_winbind.so use_first_pass auth required pam_deny.so account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_winbind.so account required pam_permit.so password requisite pam_cracklib.so try_first_pass retry=3 password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_winbind.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_mkhomedir.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so
A questo punto facciamo quanti più test possiamo usando utenti dell'AD, ma prima di tutto assicuriamoci di poter accedere con i privilegi di root. Se qualcosa andasse storto possiamo sempre ripristinare la situazione antecedente, da una delle console aperte, utilizzando le copie di backup. Mi raccomando azzardate un riavvio solo se siete sicuri che il meccanismo di login funzioni correttamente.
Come ultimo passo ricordiamoci di attivare nei run level d'interesse l'avvio automatico dei servizi Samba. A questo punto il nostro server Linux sarà a tutti gli effetti integrato nel Dominio Active Directory.
