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:
# /etc/ldap/slapd.conf [...] include /etc/ldap/schema/samba.schema [...]
access to attribute=userPassword, sambaLMPassword, sambaNTPassword by dn="cn=admin,ou=DSA,dc=istituto,dc=it" writePer separare meglio l'amministrazione degli utenti samba abbiamo definito un utente
cn=samba,ou=DSA,dc=istituto,dc=it
(con password samba) con delle particolari ACL. La prima delle
quali:
access to attribute=userPassword, sambaLMPassword, sambaNTPassword by dn="cn=samba,ou=DSA,dc=istituto,dc=it" write
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/:
smbldap.conf:
pemette di configurare parametri globali che sono accessibili a
chiunque;smbldap_bind.conf:
definisce due utenze amministrative per connettersi ai server ldap
slave e master. Questo file deve essere leggibili solo dall'utente
root.
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
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>
|
|
Sandro Doro (email me)