Laboratorio

Modulo 9 - Amministrazione, gestione e autenticazione in rete

Esperienza su Samba (SMB)

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 da tre nodi collegati allo stesso dominio di collisione 192.168.50.0/24. Il nodo ldap (192.168.50.1) fornisce il servizio DNS per il dominio istituto.it e il servizio database di back-end per il servizio Samba. Il nodo SRV (192.168.50.10) fornisce il servizio Samba. Il nodo CLNT (192.168.50.11) infine viene utilizzato come macchina client per il test. Faremo riferiremo alla release di Samba del tipo 3.0.x presente nella distribuzione Debian Sarge.
Il server ldap è connesso alla rete reale ed è quindi gateway per tutte le macchine della rete virtuale. Per la raggiungibilità della macchina reale con le macchine della rete virtuale occorre aggiungere questa regola di routing:

root@realHost# route add -net 192.168.50.0/29 gw 192.168.77.2

La documentazione di eccellente qualità si può ottenere installando il pacchetto samba-doc che mette a disposizione Samba-HOWTO-Collection, Samba-Guide e Samba-Developers-Guide parzialmente consultabili anche all'interno di swat.

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:

user@realhost$ ./lab start

Questa sperimentazione si divide nelle seguenti sezioni:

Integrazione di Samba e LDAP

Questa configurazione viene gestita automaticamente dallo script e quindi al termine dello stesso tutti i passaggi sono già stati eseguiti. Noi li ripercorriamo solo per poterli commentare.
Per prima cosa occorre avere un sistema LDAP specializzato per dare "supporto" a Samba. In pratica specializziamo il master server dell'esperienza su LDAP con lo schema specializzato samba.schema presente nel pacchetto samba-doc o presso la home page:

root@ldap# export help=/usr/share/doc/samba-doc/examples
root@ldap# gzip -dc $help/LDAP/samba.schema.gz > \
                /etc/ldap/schema/samba.schema
root@ldap# chown root:root /etc/ldap/schema/samba.schema
root@ldap# chmod 440 /etc/ldap/schema/samba.schema

In seguito occorre fare due modifiche al file slapd.conf:

Passiamo ora al server Samba: prima di far partire samba occorre configurarlo. Per chi preferisce farlo attraverso la modifica del file di testo deve procedere editando il file /etc/samba/smb.conf. Per chi preferisce uno strumento grafico WEB esiste swat che è parte integrante della suite di Samba e che può essere usato dal momento che è configurata la connettività alla rete virtuale attraverso il nodo SRV.
Per attivare il browser che mostrerà il menù principale di Swat occorre specificare il seguente URL (swat lavora sulla porta 901/tcp) come segue:

user@realHost$ firefox http://192.168.50.10:901/

specificando utente root e password root (screenshot). Noi non sceglieremo mai questo metodo.

Dal momento che abbiamo configurato Samba per utilizzare LDAP occorre passargli la password che autorizzerà Samba allo scorrimento e alla modifica dell'albero LDAP. Tale informazione viene memorizzata nel file /var/lib/samba/secrets.tdb. Mostriamo un metodo per compiere questa operazione evitando che rimanga traccia della password nella history della shell:

root@SRV# read -s -p "Digita la password di samba " LDAP_BINDPW
root@SRV# smbpasswd -w $LDAP_BINDPW
Setting stored password for "cn=samba,ou=DSA,dc=istituto,dc=it" in secrets.tdb

In seguito per generare il Windows Security Identifier (SID), che varrà memorizzato nel file secrets.tdb basta far partire samba e poco dopo lanciare i comandi:

root@SRV# /etc/init.d/samba start; sleep 5

root@SRV# smbclient -L localhost -U%
root@SRV# net getlocalsid
SID for domain SRV is: S-1-5-21-3840722988-1065274203-713729200
root@CLNT# net rpc getsid netkitwg
Storing SID S-1-5-21-3840722988-1065274203-713729200 for Domain NETKITWG in secrets.tdb

Esiste anche il comando di set, utile nel nostro laboratorio, per assegnare un predefinito SID:

root@SRV# net setlocalsid 'S-1-5-21-3840722988-1065274203-713729200'

Con la partenza di samba si attivano i due "daemon" smbd e nmbd. Il file di configurazione usato è smb.conf.

Configurazione e uso di smbldap-tools

Anche per questa sezione lo script ha spianato la strada: avviseremo quando occorrerà intervenire per configurare a mano.
La release dei smbldap-tools utilizzata è quella della distribuzione Debian Sarge che nel caso reale si installa con il comando apt-get install smbldap-tools. La documentazione si trova in /usr/share/doc/smbldap-tools/html/index.html. Per la configurazione occorre modificare i seguenti file nella directory /etc/smbldap-tools/:

Dopo aver configurato i smbldap-tools possiamo popolare il database LDAP:

root@SRV# smbldap-populate

Per controllare il risultato in termini di gruppi costruiti:

root@SRV# net rpc group -l -U Administrator%not24get -S SRV

Group name            Comment
-----------------------------
Domain Admins         Netbios Domain Administrators                     
Domain Users          Netbios Domain Users                              
Domain Guests         Netbios Domain Guests Users                       
Domain Computers      Netbios Domain Computers accounts                 
Administrators        Netbios Domain Members can fully administer the computer/sambaDomainName
Print Operators       Netbios Domain Print Operators                    
Backup Operators      Netbios Domain Members can bypass file security to back up files
Replicators           Netbios Domain Supports file replication in a sambaDomainName

Ora si cambia la password di Administrator (not24get) e poi è possibile il fare il join al dominio di entrambe le macchine:

root@SRV# smbldap-passwd Administrator
root@SRV# net rpc join netkitwg -U Administrator%not24get
Joined domain NETKITWG.
root@CLNT# net rpc join netkitwg -U Administrator%not24get
Joined domain NETKITWG.

A questo punto controlliamo gli account nella forma come dovrebbero essere visibili se fossero memorizzati nel file smbpasswd:

root@SRV# pdbedit -Lw
Administrator:998:84B0D8E14D158FF8417EAF50CFAC29C3:
  AF6DD3FD4E2EA8BDE1695A3F05EFBF52:[U          ]:LCT-42B064A9:
nobody:65534:NO PASSWORDXXXXXXXXXXXXXXXXXXXXX:
  NO PASSWORDXXXXXXXXXXXXXXXXXXXXX:[NU         ]:LCT-00000000:
srv$:1000:6CAD4C79FB00B66C2E82CC1D3441B8D2:
  4C00C837D1BBFB3DC60785CA85F4B8CB:[S          ]:LCT-42B064B0:
clnt$:1001:6597264A7989423B3FD32363B4BA19FE:
  403EDF405CF421B6E826E3381C0D98A0:[S          ]:LCT-42B064E4:

Da questo momento inizia l'attività aggiuntiva allo script. Supponiamo ora di costruire un nuovo utente di nome user_admin con le seguenti caratteristiche:

il comando è:

root@SRV# smbldap-useradd -a -g 512 -m -s /bin/false \
            -d /dev/null -F "" -P user_admin

Verifichiamo la situazione del database visualizzando l'albero LDAP con il programma gq di cui forniamo il file di inizializzazione .gq da copiare nella HOME directory. Attenzione che l'accesso avviene come cn=samba,ou=DSA,dc=istituto,dc=it e quindi con password samba.

Per testare l'account Samba appena creato basta digitare:

root@CLNT# smbclient  //SRV/public -Uuser_admin%not24get
Domain=[NETKITWG] OS=[Unix] Server=[Samba 3.0.14a-Debian]
smb: \>

o anche:

root@SRV# pdbedit -Lv user_admin
Unix username:        user_admin
NT username:          user_admin
Account Flags:        [U          ]
User SID:             S-1-5-21-3840722988-1065274203-713729200-3004
Primary Group SID:    S-1-5-21-3840722988-1065274203-713729200-512
Full Name:            System User
Home Directory:       \\SRV\home\user_admin
HomeDir Drive:        K:
Logon Script:         user_admin.cmd
Profile Path:         
Domain:               NETKITWG
Account desc:         System User
Workstations:         
Munged dial:          
Logon time:           0
Logoff time:          Fri, 13 Dec 1901 21:45:51 GMT
Kickoff time:         Fri, 13 Dec 1901 21:45:51 GMT
Password last set:    Sun, 10 Oct 2004 23:05:09 GMT
Password can change:  0
Password must change: Mon, 17 Jan 2005 22:05:09 GMT
Last bad password   : 0
Bad password count  : 0

questo comando può essere dato sul ogni macchina client dove sia stata settata la password di cn=samba,ou=DSA,dc=istituto,dc=it con il comando smbpasswd -w.

Data la recente normativa sulla policy dobbiamo cambiare le policy sull'history, sulla age e sulla lunghezza:

root@SRV# pdbedit -P "password history" -C 5
account policy value for password history was 0
account policy value for password history is now 5
root@SRV# pdbedit -P "maximum password age" -C 180
account policy value for maximum password age was 4294967295
account policy value for maximum password age is now 180
root@SRV# pdbedit -P "min password length" -C 6
account policy value for min password length was 5
account policy value for min password length is now 6

Condivisione di file attraverso filesystem Samba

La prova di mount sarà realizzata attraverso una funzionalità implementata in parte dal lato "kernel space" da un modulo che appunto si chiama smbfs e in parte dal lato "user space" dal pacchetto che si chiama ancora smbfs. Il kernel che usiamo ha già all'interno il modulo per smb ma nel caso dovessimo caricare il modulo nel kernel sarebbe necessario dare il comando:

root@CLNT# modprobe smbfs

Anche per quanto riguarda il pacchetto smbfs vale la stessa cosa: è già installato ma nel caso non lo fosse occorrerebbe dare il comando:

root@CLNT# apt-get install smbfs

Ora proviamo a montare come utente user_adm lo share public sulla directory /mnt/smb:

root@CLNT# smbmount //SRV/public /mnt/smb -o username=user_admin

Al termine per liberare lo share il comando è:

root@CLNT# umount /mnt/smb

Abbiamo tracciato sia l'attività di rete di questo comando (File ACP) che quella generata dal comando ls sulla directory (File ACP) che quella generata dal comando umount. (File ACP). Abbiamo notato delle differenze nei tempi di esecuzione in dipendenza da come ci si riferisce al server. Questa è la traccia nel caso in cui si usa un nome non conosciuto a livello di DNS (File ACP) e questa è la traccia nel caso si usi direttamente l'indirizzo IP (File ACP). .

Una configurazione come quella descritta è stata sperimentata nell'A.S. 2002/2003 nel laboratorio di sistemi abacus per permettere agli studenti che sperimentavano Linux di accedere alle loro cartelle nel server M$.

Automagico mount di share SMB

Ora vogliamo provare dal nodo CLNT ad accedere ad uno share SMB senza dover dare il comando di mount che è un comando utilizzabile solo da root. Il pacchetto che contiene il software è autofs. Per impostarlo occorre configurare il file:

# /etc/auto.master
/auto /etc/auto.smb

e quindi il file:

# /etc/auto.smb
smb    -fstype=smbfs,rw,guest    ://SRV/public

Ora basta far partire il autofs o farlo ripartire:

root@CLNT# /etc/init.d/autofs start

Il test si effettua cercando, ad esempio, di posizionarsi sulla cartella /auto/smb e attendere qualche attimo che il mount dello share public avvenga nel mount point specificato.

root@CLNT# cd /auto/smb
root@CLNT:/auto/smb# mount | grep public
//SRV/public on /auto/smb type smbfs (rw)
root@CLNT:/auto/smb# cd
CLNT:/# umount /auto/smb

(screenshot).

Risoluzione dei nomi con Samba

Prima che esistesse il NetBIOS Name Server (NBNS), la risoluzione dei nomi era affidata completamente al broadcast. Quando si voleva conoscere l'indirizzo di una macchina bastava mandare in broadcast sulla rete il suo nome e la macchina stessa rispondeva. Questo approccio è ancora possibile.

Comunque il broadcast non passa facilmente tra subnet e inoltre occupa una certa parte della banda della rete. Per risolvere questo problema M$ ha ideato il Windows Internet Naming Service (WINS) che risulta essere un NBNS che attraversa le subnet e che è implementato anche da Samba. L'amministratore quindi decide che una certa macchina agisce come WINS server e quindi tutta la rete M$ richiede direttamente la registrazione e la risoluzione a tale macchina.

Per configurare Samba come WINS server basta valorizzare due opzioni della parte global:

[global]
    wins support = yes
    name resolve order = wins lmhosts hosts bcast

Questo è tutto. Se proviamo a inserire le righe appena citate sulla configurazione di Samba del paragrafo precedente possiamo testarne il funzionamento. Il comando per chiedere la risoluzione di un nome ad un WINS server di nome SRV è nmblookup -U SRV ed ecco il comando e il risultato:

root@CLNT# nmblookup -U 192.168.50.10 -R srv
querying srv on 192.168.50.10
192.168.77.2 srv<00>

Creative Commons License FREE THE MOUSE Valid HTML! Sandro Doro (email me)
Ultima modifica: $Date: 2005-11-26 13:43:34 $