Linux e Active Directory

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:

#server 0.fedora.pool.ntp.org
#server 1.fedora.pool.ntp.org
#server 2.fedora.pool.ntp.org
server 192.168.0.1

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:

nameserver 192.168.0.1

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:

192.168.0.1   server.miodominio.local   server

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.

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = MIODOMINIO.LOCAL
 dns_lookup_realm = false
 dns_lookup_kdc = false
 ticket_lifetime = 24h
 forwardable = yes

[realms]
 MIODOMINIO.LOCAL = {
  kdc = server.miodominio.local:88
  admin_server = server.miodominio.local:749
  default_domain = miodominio.local
 }

[domain_realm]
 .miodominio.local = MIODOMINIO.LOCAL
 miodominio.local = MIODOMINIO.LOCAL

[appdefaults]
 pam = {
   debug = false
   ticket_lifetime = 36000
   renew_lifetime = 36000
   forwardable = true
   krb4_convert = false
 }

Mi raccomando prestate molta attenzione all’uso corretto di maiuscole e minuscole pena il mancato funzionamento. A questo punto non ci resta che testare la nuova configurazione. Lo vedremo nella prossima pagina

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.

[global]

workgroup = MIODOMINIO
realm = MIODOMINIO.LOCAL
preferred master = no
server string = Server Linux
security = ADS
encrypt passwords = Yes
winbind enum users = Yes
winbind enum groups = Yes
winbind use default domain = Yes
winbind nested groups = Yes
winbind separator = +
idmap uid = 10000-20000
idmap gid = 10000-20000
;template primary group = "Domain Users"
template shell = /bin/bash


#i valori vanno da 0 a 10
log level = 3
# log suddivisi per macchina
log file = /var/log/samba/log.%m
# dimensione massima 50KB del file di log
max log size = 50

printcap name = cups
printing = cups


[homes]

comment = Home Direcotries
valid users = %S
read only = No
browseable = No

[printers]

comment = All Printers
path = /var/spool/cups
browseable = no
printable = yes
guest ok = yes

Con le prime due direttive, workgroup e realm, impostiamo rispettivamente il nome NetBIOS e DNS (kerberos realm) del Dominio Windows di cui farà parte la nostra macchina.

Ponendo a no il valore di preferred master facciamo in modo che il nostro server non si imponga come Master Browser della rete. Invece con server string indichiamo la stringa descrittiva che comparirà accanto al nome dell’host (sambaserver) in Risorse di Rete.

La direttiva security = ADS imposta la nostra Linux box come un Member Server del Dominio Active Directory, che utilizzerà Kerberos per l’autenticazione. Encrypt passwords non ha bisogno di commenti.

Assegnando il valore Yes a winbind enum users e winbind enum groups, consentiamo l’enumerazione di utenti e gruppi appartenenti all’AD. Il processo è piuttosto costoso in termini di risorse e non strettamente necessario all’autenticazione. Anzi potrebbe causare un timeout e far fallire l’operazione, per questo è solitamente sconsigliato se utenti e gruppi superano i 200.

Con winbind use default domain possiamo evitare di far precedere il nome di dominio al nome utente. Potremo autenticarci come username invece di MIODOMINIOusername (o MIODOMINIO+username come si chiarirà subito sotto).

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. Se enumeriamo gli utenti appariranno come MIODOMINIO+username.

Le direttive idmap uid ed idmap gid ci consentono di mappare nel sistema locale gli utenti dell’AD a partire da certi valori per uid e gid. Il numero di base indicato dovrà come minimo superare l’uid dell’ultimo utente inserito in /etc/passwd. Attenzione: l’utilizzo di valori bassi, in collisione con utenti di sistema, unito alla configurazione di nsswitch (che vedremo più avanti) possono bloccare il login come root. Il valore massimo specificato deve essere tale da permettere di mappare tutti gli utentigruppi presenti nell’AD.

La direttiva template primary group = “Domain Users”, nell’esempio commentata, imposta il gruppo di default per gli utenti che si autenticano sul sistema. Non è richiesta per i controllori Windows 2003 a meno che non funzionino in “mixed mode”.

Infine con template shell = /bin/bash richiediamo la shell di default per gli utenti che si loggano sul sistema.

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.

passwd:     files winbind
shadow:     files winbind
group:      files winbind

hosts:      files dns wins

bootparams: nisplus [NOTFOUND=return] files

ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:   files

netgroup:    nisplus

publickey:  nisplus

automount:  files nisplus
aliases:    files nisplus

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 ha lo scopo di segnalare come fonte di informazioni per l’autenticazione anche tale servizio. È consigliabile mantenere come prima voce il file locale per evitare di attendere una risposta dal Domain Controller quando si accede come root o quando viene utilizzato un utente di sistema. Inoltre, anche in caso di problemi con l’AD, l’account root ed i servizi continueranno a funzionare.

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:

auth        required      pam_env.so
auth        sufficient    pam_fprintd.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

# creazione home directory
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

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 e smartcard-auth. Anche questi andranno modificati per supportare Winbind, nel caso più semplice basterà 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.