Nel precedente articolo sono stati illustrati i metodi per effettuare delle interrogazioni ad un dominio Active Directory attraverso una macchina Linux al cui interno è configurato SAMBA. Nell’ultimo esempio illustrato l’esito dell’interrogazione presentava un elenco del tutto simile al contenuto del file /etc/passwd che in ogni sistema Linux contiene le informazioni di accesso degli utenti. La riflessione nata spontaneamente è quindi se si può fare in modo che il sistema sia configurato per supportare l’autenticazione via Active Directory in fase di login. La riposta è sì, ecco spiegato come.

Condividere una cartella

La configurazione illustrata nel primo articolo della serie consente di autenticare l’accesso a cartelle condivise mediante le credenziali presenti nel Active Directory.
Per condividere una cartella è sufficiente aggiungere al file di configurazione di SAMBA /etc/samba/smb.conf una dichiarazione come la seguente:

[Test]
        comment = Test
        path = /samba/test
        write list = DOMINIO.IT/user1
        read list = @"DOMINIO.ITgruop1"
        read only = Yes
        browseable = Yes
        create mask = 0775
        directory mask = 0775

dopo aver effettuato il reload del servizio attraverso il comando:

$ /etc/init.d/samba reload

la directory, supponendo che l’indirizzo IP della macchina sia 192.168.0.100, sarà disponibile per l’accesso dalla rete all’indirizzo //192.168.0.100/Test. L’utente DOMINIO.ITuser1 (così andrà digitato alla schermata di login) avrà il permesso di scrittura mentre tutti gli utenti del gruppo DOMINIO.ITgroup1 potranno accedere in lettura alla condivisione.

Ma questa è solo la punta dell’iceberg. Come già detto, la configurazione di SAMBA permette di sfruttare il metodo di autenticazione in modo che il sistema stesso in fase di login si riferisca al dominio Active Directory.

PAM, brevemente

PAM (Pluggable Authentication Modules) definisce un metodo standard ad alto livello per gestire l’autenticazione. Questo strato è comune a tutti i sistemi Linux (sebbene le varie versioni non operino tutte allo stesso modo) e consente a coloro i quali sviluppano servizi con autenticazioni proprie di creare moduli che rispettino l’interfaccia di programmazione relativa a PAM.
In questo modo, potenzialmente, qualunque sistema di autenticazione può essere integrato con il login di sistema.
Una panoramica dettagliata di quello che è PAM e di come funziona è disponibile presso Kernel.org, precisamente a questo link: http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html.

Integrazione di winbind con PAM per il login via Active Directory

La configurazione di PAM all’interno del sistema è contenuta in una serie di file, in Debian Lenny, la distribuzione utilizzata in questa serie di articoli, tali file si trovano nella cartella /etc/pam.d:

$ ls -1 /etc/pam.d/
chfn
chsh
common-account
common-auth
common-password
common-session
cron
login
omauth
other
passwd
samba
ssh
su

In particolare i file interessati nella fase di login sono common-account, common-auth e common-session.

La componente SAMBA che gestisce l’interfacciamento con Active Directory è, come già spiegato, winbind. Il pacchetto fornito con le maggiori distribuzioni fornisce, fra gli altri, quello che è il file base per l’introduzione di Active Directory nel login di sistema: pam_winbind.so. Tale file dovrà essere introdotto all’interno della configurazione del sistema di login.

Il primo file ad essere modificato dovrà essere /etc/pam.d/common-account il cui contenuto dovrà essere il seguente:

account sufficient      pam_winbind.so
account required        pam_unix.so

Questo file di default controlla che la password dell’utente non sia scaduta. Con l’aggiunta della riga relativa a winbind inoltre assume come sufficiente la credenziale verificata da Active Directory.

Il secondo file da considerare sarà /etc/pam.d/common-auth che di default impone l’utilizzo del meccanismo UNIX standard per l’autenticazione. Tale file dovrà assumere questo contenuto:

auth    sufficient      pam_winbind.so
auth    required        pam_unix.so nullok_secure use_first_pass

Quanto inserito comunica al sistema di considerare sufficiente l’avvenuta autenticazione con winbind. Nella seconda riga viene aggiunto il parametro use_first_pass in modo che venga utilizzata la prima password inserita per autenticare l’utente e prevenire una doppia richiesta di inserimento per la parola d’ordine.

L’ultimo file che andrà modificato è /etc/pam.d/common-session che contiene le informazioni relative alle sessioni interattive e non che l’utente potrà avviare:

session required        pam_unix.so
session required        pam_mkhomedir.so skel=/etc/skel umask=0022

rispetto al default viene aggiunta la riga relativa al modulo pam_mkhomedir.so per fare in modo che il sistema per ogni utente identificato che non possiede una home directory ne crei una ex-novo partendo dalle specifiche presenti nel file di /etc/skel con i permessi di scrittura relativi.

Prova di login

A questo punto il sistema è pronto a permettere il login alle utenze Active Directory, relativamente a tutti i servizi, compreso ssh:

$ ssh "DOMINIO.IT\user1"@192.168.0.100
DOMINIO.ITuser1@192.168.0.100's password: 
Creating directory '/home/DOMINIO.IT/user1'.
Linux anomalia 2.6.26-1-686 #1 SMP Fri Mar 13 18:08:45 UTC 2009 i686
 
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
 
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
DOMINIO.IT\user1@anomalia:~$

Essendo il primo tentativo di login effettuato e data la configurazione PAM precedentemente illustrata, il sistema ha creato la directory /home/DOMINIO.IT/user1.
Nella cartella /home/DOMINIO.IT verranno pertanto registrate tutte le home directories relative agli utenti:

$ ls -la /home/DOMINIO.IT/
totale 12
drwxr-xr-x 3 root                    root                             4096  9 apr 17:32 .
drwxr-xr-x 3 root                    root                             4096  9 apr 17:32 ..
drwxr-xr-x 2 DOMINIO.IT\user1 DOMINIO.IT\domain users 4096  9 apr 17:32 user1

L’accesso al sistema degli utenti Active Directory è garantito nella stessa medesima forma degli utenti di sistema standard.

Conclusioni

Questa panoramica di SAMBA ha voluto illustrare quello che è lo stato dell’arte dell’integrazione tra SAMBA e Microsoft Active Directory ad oggi, ma moltissime sono le novità che bollono in pentola dal team di sviluppo del progetto Samba. La versione 4 è ormai una realtà e sebbene la strada verso la prima release stabile sia lunga, le aspettative in merito sono altissime. Questa versione sarà la prima ad integrare la completa gestione di Active Directory ed un’altra serie di importanti novità che potranno, perché no, essere argomento di un prossimo articolo.

Articoli della serie

Samba e Active Directory (1 di 3): diventare parte di un Dominio
Samba e Active Directory (2 di 3): interrogare il dominio
Samba e Active Directory (3 di 3): configurare pam per l’autenticazione locale

Dopo aver introdotto Active Directory ed aver configurato SAMBA per l’integrazione con un dominio vengono affrontati in questa seconda puntata i metodi per l’interrogazione dei domini: come ricavare le informazioni sugli utenti ed i gruppi, come accedere ad un computer di dominio ed eseguirvi un comando.
Il tutto attraverso gli strumenti offerti da SAMBA, dalla linea di comando.

Interrogazioni

Tra gli strumenti che samba mette a disposizione dalla linea di comando per l’interrogazione delle varie componenti del dominio ne verranno analizzati tre: net, già utilizzato nel precedente articolo per aggiungere la macchina al dominio, smbclient, un’interfaccia simile a quella di FTP ma utilizzabile per accedere a condivisioni Microsoft Windows e wbinfo, programma che interroga il demone winbind, la componente si SAMBA che si interfaccia con il servizio Active Directory.

net

l’opzione user del comando net associata alla specifica di -l consente di ricavare l’elenco utenti del dominio specificato nel file di configurazione di SAMBA:

$ net -U Administrator ads user -l
Enter Administrator's password:
 
User name             Comment
-----------------------------
user1                 Utente di test #1
Guest                 Built-in account for guest access to the computer/domain
...
...

Allo stesso modo specificando l’opzione group è possibile ottenere l’elenco gruppi:

$ net -U Administrator ads group -l
Enter Administrator's password:
 
Group name            Comment
-----------------------------
Exchange Servers      This group contains all the Exchange servers. This group should not be deleted.
Exchange Organization Users in this group will have permission to read and modify all Exchange configuration. This group should not be deleted.
Exchange Recipient Ad Users in this group can manage Exchange user attributes in the Active Directory and perform select mailbox operations. This group should not be deleted.
...
...

net permette anche di creare, cancellare e rinominare utenti e gruppi, ad esempio per creare il gruppo test_group il comando sarà:

$ net -U Administrator ads group ADD test_group
Administrator's password: 
Group test_group added

Parallelamente un utente potrà esser creato come segue:

$ net -U Administrator ads user ADD test_user
Administrator's password: 
User test_user added

Purtroppo net non consente ancora di operare sull’appartenenza dei gruppi, che è prevista nelle versioni future di SAMBA. Tutti le opzioni disponibili possono essere visionate nella man page del comando accessibile digitando man net.

smbclient con il ticket KERBEROS

Il tool smbclient offre un’interfaccia testuale con comandi simili a quelli ftp attraverso i quali è possibile interrogare ed agire su cartelle relative a condivisioni di tipo SMB/CIFS (cioè Microsoft Windows). Se già da questo punto di vista lo strumento appare subito utilissimo esiste un ulteriore vantaggio che lo rende indispensabile per le architetture Linux integrate con Active Directory: infatti smbclient può utilizzare l’autenticazione KERBEROS descritta nel precedente articolo per connettersi ai servizi remoti.
Prima di presentare gli esempi di utilizzo è quindi necessario fare acquisire al sistema il ticket KERBEROS attraverso il comando kinit:

$ kinit -V Administrator@DOMINIO.IT
Password for Administrator@DOMINIO.IT:
Authenticated to Kerberos v5

Il sistema è quindi in possesso della verifica necessaria per presentarsi ai servizi remoti. Utilizzando l’opzione -k di smbclient è possibile ad esempio sfogliare un computer di dominio del quale si conosce l’indirizzo IP o il nome. Nel nostro caso il sistema si chiama Test-win03 e l’invocazione di smbclient con i parametri utilizzati elencherà tutte le condivisioni disponibili sul server pubblico Microsoft:

$ smbclient -k -L Test-win03
OS=[Windows Server 2003 3790 Service Pack 2] Server=[Windows Server 2003 5.2]
 
       Sharename           Type      Comment
       ---------           ----       -------
       print$              Disk       Driver della stampante
       C$                  Disk       Condivisione predefinita
       IPC$                IPC        IPC remoto
       ADMIN$              Disk      Amministrazione remota
       HPLaserJ            Printer   HP LaserJet 4100 Series PS
       musica              Disk      
OS=[Windows Server 2003 3790 Service Pack 2] Server=[Windows Server 2003 5.2]
 
	Server               Comment
	---------            -------
 
	Workgroup            Master
	---------            -------

L’output del comando mostra quali condivisioni sono disponibili sul server remoto, su queste è quindi possibile eseguire dei comandi. Ad esempio per effettuare il listato del contenuto della cartella musica è possibile invocare smbclient in questa forma:

$ smbclient -k //Test-win03/musica -c "ls"
OS=[Windows Server 2003 3790 Service Pack 2] Server=[Windows Server 2003 5.2]
  .                                   D        0  Mon Feb 16 17:13:06 2009
  ..                                  D        0  Mon Feb 16 17:13:06 2009
  Cartoni Animati                     D        0  Mon May 19 13:39:51 2008
  Collaborazioni                      D        0  Mon Feb 16 11:17:12 2009
  Cover                               D        0  Thu Dec 18 16:04:02 2008
...
...

smbclient dispone inoltre di una shell, in tutto e per tutto simile ad una shell di tipo ftp. Per accedervi è sufficiente invocare smbclient senza altri paramente che il già citato -k ed il nome della macchina seguito dalla cartella:

$ smbclient //Test-win03/musica -k
OS=[Windows 5.1] Server=[Windows 2000 LAN Manager]
smb: >

I comandi disponibili nell’interfaccia si ottengono digitando help:

smb: >help
?              altname        archive        blocksize      cancel         
case_sensitive cd             chmod          chown          del            
dir            du             exit           get            getfacl        
hardlink       help           history        lcd            link           
lowercase      ls             mask           md             mget           
mkdir          more           mput           newer          open           
print          prompt         put            pwd            q              
queue          quit           rd             recurse        reget          
rename         reput          rm             rmdir          showacls       
setmode        stat           symlink        tar            tarmode        
translate      volume         vuid           logon          listconnect    
showconnect    !

Altre informazioni utili su smbclient sono ottenibili attraverso la man page (man smbclient) del programma.

wbinfo

L’ultimo comando illustrato è wbinfo che come anticipato permette di interrogare il demone winbind responsabile delle comunicazione tra SAMBA ed Active Directory e l’integrazione dei due sistemi. In particolare il demone si occupa di effettuare il mapping delle utenze, di associare cioè l’identificativo univoco presente sul dominio ad un identificativo univoco LOCALE alla macchina SAMBA.
Per capire quanto illustrato, si osservi il seguente comando:

$ for i in `wbinfo -u --domain=DOMINIO.IT`; do wbinfo -i "$i"; done
DOMINIO.ITuser1:*:10000:10004:User 1:/home/DOMINIO.IT/user1:/bin/bash
DOMINIO.ITuser2:*:10001:10004:User 2:/home/DOMINIO.IT/user2:/bin/bash
DOMINIO.ITuser3:*:10002:10004:User 3:/home/DOMINIO.IT/user3:/bin/bash
DOMINIO.ITuser4:*:10003:10004:User 4:/home/DOMINIO.IT/user4:/bin/bash
...
...

L’elenco ricavato dal comando è del tutto simile a quanto contenuto nel file /etc/passwd di sistema, ad ogni utenza è infatti associato un identificativo univoco, un gruppo, una home dir ed una shell di login.
Anche in questo caso tutte le opzioni disponibili per il comando wbinfo sono disponibili nella man page (man wbinfo).

Conclusioni

L’esito dell’ultimo comando illustrato introduce quello che sarà l’argomento della prossima ed ultima puntata di questa serie: l’integrazione di Active Directory con il login di sistema attraverso la configurazione di PAM.

Articoli della serie

Samba e Active Directory (1 di 3): diventare parte di un Dominio
Samba e Active Directory (2 di 3): interrogare il dominio
Samba e Active Directory (3 di 3): configurare pam per l’autenticazione locale

In questa serie di tre articoli verrà affrontata l’integrazione tra Samba ed Active Directory: Come aggiungere un sistema Linux ad un dominio Active Directory configurando opportunamente Samba, come effettuare interrogazioni relative ai dati del dominio attraverso i tool messi a disposizione dal pacchetto ed infine come configurare le librerie PAM del sistema affinché le autenticazioni per l’accesso vengano effettuate attraverso il dominio.
Nella prima parte oltre ad un’introduzione su Active Directory verrà trattata la configurazione di SAMBA per l’integrazione con un dominio.

Cos’è Active Directory

Active Directory di Microsoft Windows è ormai l’insieme di servizi standard per i sistemi che accentrano i dati relativi alle risorse di un dominio, siano queste utenti, computer o periferiche, tutti fanno capo al direttorio centralizzato che è disponibile nel sistema operativo Microsoft Windows dalla versione 2000 in poi.
Molti sono i servizi che entrano in gioco in un dominio Active Directory ad esempio le informazioni relative alle risorse sono registrate in un direttorio LDAP opportunamente personalizzato da Microsoft, la risoluzione dei nomi è affidata al servizio DNS interno ai server Active Directory.
La componente base di Active Directory è il protocollo Kerberos, che permette di autenticarsi in maniera cifrata.
Una volta che la propria identità viene riconosciuta, è quindi possibile accedere in maniera sicura a tutte le risorse per le quali si possiedono i permessi. Tale peculiarità è definita SSO o Single Sign-On.

Configurazione del sistema

Il sistema che viene configurato nell’esempio parte da questi presupposti: il dominio Active Directory è DOMINIO.IT ed è erogato da tre server adserver1.dominio.it, adserver2.dominio.it ed adserver3.dominio.it. Si parte dal presupposto che si disponga di un’utenza amministrativa (Administrator) o comunque di un’utenza che abbia i permessi di aggiungere computer al dominio. Il server SAMBA configurato sarà appunto un computer aggiunto al dominio DOMINIO.IT.

Installazione KERBEROS

Per far funzionare Kerberos su un sistema Linux (in questo caso, come detto, Debian Lenny) è sufficiente il pacchetto krb5-user. Tale pacchetto contiene tutti gli eseguibili necessari all’interfacciamento con i server di autenticazione. Inoltre, per completezza, è conveniente installare anche il pacchetto krb5-config contenente un template relativo ai file di configurazione e krb5-doc che contiene la documentazione completa del funzionamento di Kerberos sotto Linux:

$ apt-get install krb5-user krb5-config krb5-doc

Il file di configurazione /etc/krb5.conf contiene le impostazioni necessarie al collegamento con il (o “i”) server di autenticazione e, pertanto, dovrà contenere le informazioni ad essi associate:

[libdefaults]
        default_realm = DOMINIO.IT
 
[realms]
        DOMINIO.IT = {
                kdc = adserver1.dominio.it
                kdc = adserver2.dominio.it
                kdc = adserver3.dominio.it
                admin_server = adserver1.dominio.it
                  }

Nella sezione libdefaults sono definite le informazioni di default per la libreria krb5, la sezione realms contiene le definizioni specifiche relative ai vari domini dichiarati, nel caso sopra descritto vi sono definiti i tre server kdc (acronimo che sta per Key Distribution Server) ai quali vengono richiesti i permessi di accesso alle risorse ed il parametro admin_server che indica il Master Kerberos server ossia il principale erogatore del servizio.
La configurazione illustrata è minimale e permette i test che verranno effettuati, ma molte altre sono le opzioni relative a Kerberos e sono disponibili nella man page consultabile attraverso questo comando:

$ man krb5.conf

A completamento della configurazione sono necessarie due ulteriori operazioni, la prima è l’aggiunta dei server dichiarati nel file krb5.conf nel file hosts:

# ADs Servers
192.168.0.1    adserver1.dominio.it
192.168.0.2    adserver2.dominio.it
192.168.0.3    adserver3.dominio.it

In questo modo malfunzionamenti nel sistema di risoluzione dei nomi (e cioè del server DNS dichiarato in /etc/resolv.conf) non comporteranno l’interruzione del servizio.
La seconda operazione riguarda l’orario del sistema che deve essere assolutamente esatto per potersi interfacciare con un server Active Directory, installando quindi il pacchetto ntpdate è possibile sistemare l’orario automaticamente, puntando un servizio ntp pubblico come time.ien.it:

$ apt-get install ntpdate
$ ntpdate time.ien.it
 9 Apr 16:44:53 ntpdate[2806]: step time server 193.204.114.105 offset -7226.860681 sec

Sebbene l’argomento non sia trattato in questo articolo, ideale sarebbe avere un sistema automatizzato che costantemente sistemi l’orario, come ad esempio openntpd.
A questo punto, terminata la configurazione, è tempo di richiedere il primo ticket al server attraverso il comando kinit. La richiesta dovrà essere fatta da un utente privilegiato (quindi Administrator o chi per esso):

$ kinit -V Administrator@DOMINIO.IT
Password for Administrator@DOMINIO.IT:
Authenticated to Kerberos v5

Se il messaggio restituito dal comando è “Authenticated to Kerberos v5″, allora tutto è andato come da pronostico. In alternativa sarà necessario controllare la bontà dei dati inseriti e rilanciare il comando.

Installazione SAMBA e Winbind

Il secondo componente da configurare per l’attuazione del progetto è SAMBA insieme alla parte che si occupa di interfacciarsi con i server Microsoft Windows per il reperimento delle informazioni di dominio:

$ apt-get install samba smbclient smbfs winbind

Il contenuto del file di configurazione di SAMBA, /etc/samba/smb.conf, dovrà essere simile al seguente:

[global]
        realm = DOMINIO.IT
        server string = %h : Samba %v
        security = ADS
        auth methods = guest, sam, winbind
        password server = adserver1.dominio.it, adserver2.dominio.it, adserver3.dominio.it
        log level = 3 passdb:10 auth:10 winbind:10
        max log size = 50
        load printers = No
        show add printer wizard = No
        preferred master = No
        ldap ssl = no
        idmap uid = 10000-200000
        idmap gid = 10000-200000
        template shell = /bin/bash
        create mask = 0770
        directory mask = 0770
        reset on zero vc = yes

La configurazione al di là delle opzioni ininfluenti per il progetto, prevede i seguenti parametri:

1. realm: il dominio active directory DOMINIO.IT;
2. security: il tipo di funzionamento che SAMBA deve assumere, che è “ADS” (Active Directory);
3. auth methods: i metodi di autenticazione che sono guest (ospite), sam (il database standard delle utenze SAMBA) e winbind (attraverso Microsoft Windows);
4. password server: i server presso i quali autenticarsi (identici a quelli dichiarati per Kerberos);
5. idmap uid e idmap gid: gli identificativi di partenza con cui mappare le utenze lette dai server Windows, in modo che a queste utenze possano essere assegnati permessi locali;
6. reset on zero vc: indica al sistema di resettare una connessione se ne subentra un’altra dallo stesso indirizzo IP. Quest’opzione è utile quando le connessioni di rete non sono stabili e Microsoft Windows riapre una nuova connessione sebbene la precedente abbia ancora dei file allocati;

Prima di avviare il servizio SAMBA è necessaria una variazione al file /etc/nsswitch.conf in modo da indicare al sistema che i dati per le autenticazioni possono essere ricercati oltre che nei file locali, anche nel server winbind, pertanto le righe corrispondenti a queste informazioni andranno variate come indicato di seguito:

passwd:         compat winbind
group:          compat winbind
...
hosts:          files dns wins

A questo punto dopo il riavvio dei servizi appena configurati:

$ /etc/init.d/samba restart
Stopping Samba daemons: nmbd smbd.
Starting Samba daemons: nmbd smbd.
$ /etc/init.d/winbind restart
Stopping the Winbind daemon: winbind.
Starting the Winbind daemon: winbind.

Si potrà includere il server all’interno del dominio utilizzando il comando net per eseguire l’operazione di join:

$ net ads join -U Administrator
Enter Administrator's password:
Using short domain name -- DOMINIO
Joined 'ANOMALIA' to realm 'dominio.it'

L’output del comando conferma che il server ora è parte del dominio. Un’ulteriore verifica è effettuabile sempre attraverso il comando net mediante l’utilizzo dell’opzione info:

$ net ads info
LDAP server: 192.168.0.1
LDAP server name: adserver1.dominio.it
Realm: DOMINIO.IT
Bind Path: dc=DOMINIO,dc=IT
LDAP port: 389
Server time: gio, 09 apr 2009 17:07:33 CEST
KDC server: 192.168.0.1
Server time offset: 2

Conclusioni

Nella prossima puntata verranno illustrate le tecniche per interrogare le risorse ed accedervi.

Articoli della serie

Samba e Active Directory (1 di 3): diventare parte di un Dominio
Samba e Active Directory (2 di 3): interrogare il dominio
Samba e Active Directory (3 di 3): configurare pam per l’autenticazione locale