Laboratorio

Modulo 9 - Amministrazione, gestione e autenticazione in rete

Esperienza su Samba in multipla istanza

Per la realizzazione di questo modulo useremo Netkit4TIC con la connettività con la rete reale (leggere il file README).

La rete descritta dalla mappa (pdf, xml) è costituita dall'unione di una rete virtuale (192.168.50.0/24) realizzata tramite UML con una rete virtuale (192.168.76.0/24) realizzata tramite QEMU e con il nodo reale con funzione di routing tra le due.

L'esercitazione prende lo spunto da un caso di configurazione di un HA-cluster di tipo active-active dove uno dei due nodi fornisce autenticazione Samba (Domain Control) e l'altro fornisce filesystem Samba (Domain Member). Nel caso di fault di un nodo quello superstite deve prendersi incarico del servizio fornito dal nodo guasto e quindi in tale circostanza nel superstite sarebbero in esecuzione due specifiche e distinte istanze di Samba.
I componenti sono:

Il nodo ldap (192.168.50.1) fornisce il servizio DNS per il dominio istituto.it e il servizio LDAP database di back-end per il servizio Samba.
Il server ldap è connesso alla rete reale ed è quindi gateway per tutte le macchine della rete virtuale 192.168.50.0/24. Per la raggiungibilità della macchina reale con le macchine della rete virtuale occorre aggiungere questa regola di routing:
```
realHost# route add -net 192.168.50.0/29 gw 192.168.77.2
```
Uno o due nodi in funzione della richiesta allo startup: se non vengono passato parametri la chiamata verrà interpretata come la richiesta di generare un singolo nodo dualSamba (192.168.50.101 e 192.168.50.102) con installati i due specifici servizi Samba (in simulazione di fault di un nodo del cluster); nel caso in cui invece venga specificato il parametro nofault vengono generati due distinti nodi Core (192.168.50.101) e Home (192.168.50.102) con ognuno lo specifico servizio Samba (in simulazione di assenza di guasti nel cluster).
Il nodo client è un sistema Microsoft Windows XP Professional SP2 in esecuzione utilizzando QEMU presente nel live-{CD,USB}.

Scarica il file tarball contenente tutto il necessario e scompattalo in una sottodirectory della HOME dell'utente. Dopo aver settato correttamente l'ambiente Netkit lancia lo script:

realHost$ ./lab start [nofault]

ricordati che anche lo stop accetta un parametro opzionale:

realHost$ ./lab crash [nofault]

Questa sperimentazione si divide nelle seguenti sezioni:

Ricompilazione Samba
Configurazione del Domain Controller e del Domain Member
Configurazione QEMU
Configurazione XP
browsing
Join al dominio del client XP

Ricompilazione Samba

Per far coesistere due istanze dello stesso servizio sullo stesso nodo occorre che i "data base" dei due servizi siano distinti. Poichè non esiste nel file di configurazione smb.conf un metodo per controllarlo completamente occorre passare per una ricompilazione modificando "a mano" i path dei vari "data base".
Adottiamo quindi la strategia che l'istanza che controlla l'autenticazione sia quella immmutata proveniente dalla distribuzione Debian Sarge mentre l'istanza che gestisce lo spazio su disco sia quella modificata. Anzi cogliamo l'occasione per evidenziare che questa istanza potrebbe essere ancor più customizzata in modo da includere, ad esempio, il controllo autivirus.

Si scaricano i sorgenti (eventualmente anche con wget) aggiungendo anche le locazioni per i fix di sicurezza:

# /etc/apt/sources.list
[...]
deb-src http://security.debian.org/ stable/updates main contrib

vm# mkdir /tmp/samba; \
    cd /tmp/samba; \
    apt-get update; \
    apt-get --download-only source samba
Reading Package Lists... Done
Building Dependency Tree... Done
Need to get 15.7MB of source archives.
Get:1 http://ftp.de.debian.org stable/main samba 3.0.14a-3 (dsc) [1069B]
Get:2 http://ftp.de.debian.org stable/main samba 3.0.14a-3 (tar) [15.6MB]
Get:3 http://ftp.de.debian.org stable/main samba 3.0.14a-3 (diff) [113kB]
Fetched 15.7MB in 1m56s (135kB/s)
Download complete and in download only mode
vm# ls -l
total 15416
-rw-r--r--  1 root root   112894 May 27 15:17 samba_3.0.14a-3.diff.gz
-rw-r--r--  1 root root     1069 May 27 15:17 samba_3.0.14a-3.dsc
-rw-r--r--  1 root root 15605851 Apr 19  2005 samba_3.0.14a.orig.tar.gz

Scompattiamo i sorgenti "alla Debian":

vm# dpkg-source -x samba_3.0.14a-3.dsc

Applichiamo la nostra customizzazione per sostituire alla parola samba la parola sambaHome sulla debian/patches/fhs.patch:

vm# cd samba-3.0.14a/
vm# cp fhs.patch debian/patches/fhs.patch

Compiliamo:

vm# fakeroot dpkg-buildpackage -b -uc

al termine, anche se in presenza di errori, nella directory source/bin troveremo i file binari.
Di questi sono di nostro interesse solo nmbd, smbd, winbindd, net, pdbedit, smbpasswd, wbinfo che provvediamo a rinominare in nmbdHome, smbdHome, winbinddHome, netHome, pdbeditHome, wbinfoHome, smbpasswdHome. Spostiamo nella directory /usr/sbin i primi tre e nella directory /usr/bin i restanti.

Discorso a parte occorre fare per la directory dove vengono mantenuti i pid dei processi in esecuzione. La radice è /var/run a cui si postpone /samba per il pacchetto originale e a cui postponiamo /sambaHome per il pacchetto modificato. Ne segue che anche gli script /etc/init.d/sambaHome e /etc/init.d/winbindHome debbano essere variati per adattarsi a tali modifiche.

Configurazione del Domain Controller e del Domain Member

Il documento che abbiamo seguito per la realizzazione di questa esperienza è "Samba-3 by Example" di John H. Terpstra. In particolare i capitoli "Making Users Happy", "A Distributed 2000-User Network" e "Adding UNIX/Linux Servers and Clients".
Diffido il lettore dalla lettura "senza pinze" della enorme quantità di documentazione sull'argomento in quanto l'autore della citata opera ha speso molto tempo per riportare tutti i particolari per una precisa e corretta configurazione. Un esempio per tutti è il join al dominio di una macchina Microsoft XP: non occorre più alcuna modifica con regedit e potete trovare in rete cosa ne pensa lo stesso John H. Terpstra.
Inoltre è stato essenziale l'aiuto fornito dalla mailing list italiana Samba-it@xsec.it dedicata a samba e in particolare da Simo Sorce che cogliamo l'occasione di ringraziare ancora.

La configurazione del Domain Controller non è dissimile alla classica configurazione di Samba con backend su LDAP.

# /etc/samba/smb-Core.conf
[global]

   workgroup = NetkitWG
   netbios name = Core
   server string = CoreServerString

   domain logons = Yes
   os level = 65
   preferred master = Yes
   domain master = Yes

   bind interfaces only = yes
   interfaces = 192.168.50.101, 127.0.0.1

[...]

   passdb backend = ldapsam:ldap://ldap/
   ldap admin dn = cn=samba,ou=DSA,dc=istituto,dc=it
   ldap suffix = dc=istituto,dc=it
   ldap group suffix = ou=Groups
   ldap user suffix = ou=Users
   ldap machine suffix = ou=Computers

[...]

Il Domain Member che fornisce il servizio di filesystem si appoggia al domain controller per le autorizzazioni e in particolare abbiamo fatto uso di winbind per la traduzione dei SID in uid/gid (eccone gli effetti).

# /etc/samba/smb-Home.conf
[global]

   workgroup = NetkitWG
   netbios name = Home
   server string = HomeServerString

   bind interfaces only = yes
   interfaces = 192.168.50.102

   admin users = Administrator
   security = domain

[...]

Per la risoluzione dei nomi delle entità amministrative entrambi si appoggiano al Name Service Switch (NSS).
Non abbiamo usato i roaming profiles.

Personalizziamo la popolazione del database con uid non inferiori a 2000 e gid non inferiori a 1500 in modo da non avere collisioni con il database su file (passwd, group):

core# smbldap-populate -u 2000 -g 1500

Per il test costruiamo il gruppo gtest

core# smbldap-groupadd -a gtest

e un utente utest (passwd: secret):

core# smbldap-useradd -a -G gtest -c "Test user" -B 1 -m -P utest

Per verificare proviamo:

core# id utest
uid=2001(utest) gid=513(Domain Users) groups=513(Domain Users),1500(gtest)

Testiamo le ACL attive:

ldap# smbcacls //home/Administrator file-inHome -U administrator%not24get
REVISION:1
OWNER:NETKITWG\Administrator
GROUP:NETKITWG\Domain Admins
ACL:NETKITWG\Administrator:ALLOWED/0/RW
ACL:NETKITWG\Domain Admins:ALLOWED/0/R
ACL:\Everyone:ALLOWED/0/R
ldap# smbcacls //core/Administrator file-inCore -U administrator%not24get
REVISION:1
OWNER:NETKITWG\Administrator
GROUP:NETKITWG\Domain Admins
ACL:NETKITWG\Administrator:ALLOWED/0/RW
ACL:NETKITWG\Domain Admins:ALLOWED/0/R
ACL:\Everyone:ALLOWED/0/R
sambaCore# getfacl /home/Administrator/file-inCore
# owner: Administrator
# group: Domain Admins
user::rw-
group::r--
other::r--

Verifichiamo il join al dominio dei due servizi:

sambaCore# net rpc testjoin
Join to 'NETKITWG' is OK
sambaHome# netHome -s /etc/samba/smbHome.conf rpc testjoin
Join to 'NETKITWG' is OK

Listiamo le risorse nel dominio:

ldap# smbtree -U administrator%not24get
NETKITWG
        \\HOME                          HomeServerString
                \\HOME\ADMIN$           IPC Service (HomeServerString)
                \\HOME\IPC$             IPC Service (HomeServerString)
                \\HOME\profdata         Profile Data Share
                \\HOME\profiles         Profile Share
                \\HOME\netlogon         Network Logon Service
        \\CORE                          CoreServerString
                \\CORE\ADMIN$           IPC Service (CoreServerString)
                \\CORE\IPC$             IPC Service (CoreServerString)
                \\CORE\profiles         Profile Share
                \\CORE\netlogon         Network Logon Service

Configurazione QEMU

Il live-{CD,USB} (versione ≥ v2.1) contiene una versione di QEMU con abilitato il supporto per il modulo acceleratore. Per l'uso di QEMU rimandiamo al sito stesso e al nostro approfondimento.

Per caricarlo:

realHost$ sudo modprobe kqemu

A partire da un CD contenente una installazione per XP Pro SP2 regolarmente licenziato è possibile costruire una immagine per QEMU. Questa immagine vi verrà fornita durante il corso tramite NFS. A partire da questa immagine XPPSP2.img, rigorosamente in read-only, ci costruiamo un "delta":

realHost$ qemu-img create -b XPPSP2.img -f qcow delta-XPPSP2.img

che avrà dimensioni proporzionali al numero di variazioni fatte a partire dalla immagine iniziale XPPSP2.img (infatti all'inizio è di 8 KB).
Siamo ora pronti a far partire Microsoft XP Pro SP2:

realHost$ sudo modprobe kqemu
realHost$ ifname=`sudo tunctl -b -u knoppix`; \
          export QEMU_SW="-usb -usbdevice tablet -kernel-kqemu"; \
          export QEMU_NET="-net nic -net tap,ifname=$ifname"; \
          qemu -m 140 -hda delta-XPPSP2.img $QEMU_SW $QEMU_NET

Configurazione XP

In questa sezione faremo riferimento al prodotto Microsoft Windows XP Professional versione 2002 Service Pack 2.

Configuriamo per prima cosa la connessione alla rete (screenshot) inserendo l'IP address, il default gateway e il DNS (screenshot). In seguito configuriamo il server WINS e abilitiamo il NetBIOS su TCP/IP (screenshot).

Un'altra cosa da fare per non incontrare messaggi che segnalano in maniera intermittente l'indisponibilità del dominio è quella di inserire l'IP address e il nome del controllore di dominio nel file C:\\WINDOWS\\system32\\drivers\\etc\\hosts.

In seguito è meglio configurare il browser della macchina host che allo startup mostri la pagina vuota e non utilizzi il server proxy.

Disabilitiamo il firewall andando nella sezione servizi e cambiamo il metodo di attivazione del firewall da "automatico" in "manuale".

Carichiamo uno sfondo omogeneo (grigio per esempio) e disabilitiamo il save screen.

Browsing

È interessante notare come funziona il browsing della rete. Se ad esempio, dal nodo ldap chiediamo la risoluzione del nome qemu-XP con il broadcast:

ldap# nmblookup qemu-xp
querying qemu-xp on 192.168.50.255
name_query failed to find name qemu-xp

se invece utilizziamo il WINS server (e indifferentemente dall'uso del DNS) si utilizza l'unicast e il nome viene risolto:

ldap# nmblookup -U core -R qemu-xp
querying qemu-xp on 192.168.50.101
192.168.76.2 qemu-xp<00>

ldap# nmblookup -U 192.168.50.101 -R qemu-xp
querying qemu-xp on 192.168.50.101
192.168.76.2 qemu-xp<00>

Interessante anche la query:

ldap# nmblookup netkitwg#1c
querying netkitwg on 192.168.50.255
192.168.50.101 netkitwg<1c>

All'interno della macchina XP le cose sono analoghe. Avendo impostato il WINS server il comando:

XP C:> nbtstat -n
Connessione alla rete locale (LAN):
Indirizzo IP nodo: [192.168.76.2] ID ambito: []

                Tabella nomi locali NetBIOS

       Nome               Tipo         Stato
    ---------------------------------------------
    QEMU-XP        <00>  UNICO       Registrato
    NETKITWG       <00>  GRUPPO      Registrato
    QEMU-XP        <20>  UNICO       Registrato
    NETKITWG       <1E>  GRUPPO      Registrato
    NETKITWG       <1D>  UNICO       Registrato
    ..__MSBROWSE__.<01>  GRUPPO      Registrato

Per avere i nomi nella cache:

XP C:> nbtstat -c
Connessione alla rete locale (LAN):
Indirizzo IP nodo: [192.168.76.2] ID ambito: []

                  Tabella nomi cache remota NetBIOS

        Nome              Tipo       Indirizzo host    Durata [sec]
    -------------------------------------------------------------------
    NETKITWG       <1C>  GRUPPO          192.168.50.101      227
    NETKITWG       <1B>  UNICO           192.168.50.101      25
    CORE           <20>  UNICO           192.168.50.101      227
    HOME           <20>  UNICO           192.168.50.102      37
    HOME           <00>  UNICO           192.168.50.102      25

Join al dominio del client XP

Il join di una macchina al dominio avviene attraverso la rinomina della macchina (screenshot) scegliendo di aggiungerlo ad un dominio (screenshot) seguito dall'inserimento delle credenziali (screenshot).

Per motivi a noi sconosciuti il join al dominio non si conclude sempre positivamente a meno che non lo facciamo precedere da un accesso ad una share del server di autentica (seguito dalla disconessione). Solo in questo caso avviene sempre al primo tentativo.

Per simulare un contesto più reale abbiamo costruito l'utente jadmin specializzato per l'aggiunta di macchine al dominio (aggiungere enable privileges = Yes in smb.conf):

sambaCore# smbldap-useradd -a -g 512 -c "Join Administrator" \
             -B 1 -m -P jadmin

e poi abbiamo impostato Samba in modo da aggiungere l'autorizzazione in questione:

sambaCore# net rpc rights grant 'Netkitwg\jadmin' \
  SeMachineAccountPrivilege -S CORE -U Administrator%not24get
Successfully granted rights.

verifichiamo:

sambaCore# net rpc rights list 'Netkitwg\jadmin' \
  -S CORE -U Administrator%not24get
SeMachineAccountPrivilege

Mostriamo una sequenza di screenshot dell'intero desktop: (screenshot), (screenshot), (screenshot). Al successivo login il dominio NetkitWG risulta selezionabile (screenshot). Non sempre il dominio risulta disponibile e nel caso pessimo occorre aspettare anche 15 minuti!
Al terminte il dominio NetkitWG sarà browsable (screenshot).

Passwd

Per il controllo della complessit&agrav; della password è disponibile nei sorgenti di samba un prototipo da customizzare nella directory examples/auth/crackcheck.

Sandro Doro (email me)
Ultima modifica: $Date: 2007-10-31 16:22:10 $