Esperienza su Enterprise Samba
Esperienza su Enterprise Samba |
|
|
|
Per la realizzazione di questo modulo useremo
Netkit4TIC
con la
connettività
con la rete reale (leggere il file README).
Questo modulo consiste nella Configurazione e uso di un Primary Domain Controller (PDC) con workgroup in altre due sottoreti dove sono presenti Backup Domain Controller (BDC) uno per segmento.
Scarica il file tarball
contenente tutto il necessario e scompattalo in una sottodirectory della
HOME dell'utente. La release Samba di riferimento è
la 3.0.x presente nella distribuzione Debian Sarge.
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.
Configurazione e uso di un PDC con workgroup in sottoreti |
|
In questa esercitazione viene simulata una azienda con dominio Internet
istituto.it con un workgroup SMB di nome NetkitWG
distribuito parte su una rete
192.168.10.0/24 che chiameremo Area A1 con un
PDC
(NetBIOS name istituto-PDC) e un
client
(NetBIOS name ACLNT-A1) di test,
una seconda parte su una rete 192.168.20.0/24
che chiameremo Area A2 con un
BDC
(NetBIOS name istituto-BDC-A2) e un
client
(NetBIOS name ACLNT-A2) di test e una terza parte
su una rete 192.168.30.0/24 che chiameremo Area A3
con un
BDC
(NetBIOS name istituto-BDC-A3) e un
client
(NetBIOS name ACLNT-A3) di test.
Le tre reti sono connesse
da un router che a sua volta è connesso con la rete reale (pdf,
xml).
Nell'area A1
è installato il server ldap.istituto.it
che offre servizio LDAP come backend per i Domain Controller e il servizio DNS
con alias ns.istituto.it
per la risoluzione dei nomi nel dominio istituto.it.
Un PDC è una macchina in grado di rispodere alle richieste
di logon dalle macchine in un dominio Windows NT. Infatti quando un
utente si autentica su una macchina questa contatta il controllore
del dominio per verificare la correttezza della coppia (utente, password).
In seguito il controllore di dominio risponde con una serie di informazioni
quali il path del profilo dell'utente e altro.
Ogni PDC che controlla un dominio, ad esempio NetkitWG, deve
registrare il nome NetBIOS NETKITWG#1c nel server WINS. Per
verificarlo basta digitare il comando: nmblookup -A nome-server
o in una macchina M$ il comando: nbtstat -a nome-server.
A livello di specifiche all'interno del file smb.conf:
# /etc/samba/smb.conf [global] workgroup NetkitWG domain master = yes domain logons = yes encrypt passwords = yes security = user [...]
Un BDC è una macchina pensata per sopperire ad un eventuale
guasto del PDC o un suo sovraccarico o addirittura per sostituirlo.
Anche il BDC registra sul server WINS l'entry NetBIOS NETKITWG#1c
ma non l'entry NETKITWG#1b caratteristica del PDC.
In molte situazioni il BDC sopporta tutto il carico dei logon e solo
alcune funzioni, quali ad esempio il cambio di password, vengono gestite
dal PDC.
A livello di specifiche all'interno del file smb.conf:
# /etc/samba/smb.conf
[global]
workgroup NetkitWG
domain master = no
domain logons = yes
encrypt passwords = yes
security = user
[...]
Al file di realizzare un unico workgroup occorre che in tutti i segmenti ci sia lo stesso Security ID (SID) ed essere uguale a quello del PDC. Il comando per reperire il SID dal PDC e memorizzarlo localmente:
root@istituto-BDC-AX# net rpc getsid
Una stazione M$ trova il proprio controllore di dominio lanciando
un'interrogazione NetBIOS per il nome NETKITWG#1c e
assume che ogni macchina che risponde sia un controllore di dominio
e quindi possa rispondere alle richieste di logon.
Se vogliamo rendere indipendenti i segmenti della rete occorre
che vengano installati almeno un WINS server per segmento (e anche
un LDAP slave server). È quindi necessario che ogni WINS
server abbia una entry statica sul database WINS (questo si ottiene
inserendo una entry con TTL a zero nel file
/var/lib/samba/wins.dat) con gli indirizzi dei
WINS server negli altri segmenti.
Per la documentazione riguardante il browsing può essere
utile consultare i documenti
/usr/share/doc/samba-doc/htmldocs/howto/NetworkBrowsing.html.
L'esperienza virtuale viene attivata come al solito dal lancio del
comando ./lab start che oltre alla costruzione
dei nodi della rete configurerà i servizi necessari.
Per quanto riguarda il servizio LDAP si utilizzano quattro account
specializzati ragruppati nella ou=DSA,dc=istituto,dc=it:
cn=admin,ou=DSA,dc=istituto,dc=it per l'amministratore,cn=replicator,ou=DSA,dc=istituto,dc=it per il
servizio di replica del database LDAP,cn=nssuser,ou=DSA,dc=istituto,dc=it per il
servizio Name Service Switch,cn=samba,ou=DSA,dc=istituto,dc=it per Samba.
Per il PDC viene settato il SID
S-1-5-21-3840722988-1065274203-713729200
e questo
viene replicato e memorizzato dalle stazioni sullo stesso segmento di
rete con il comando:
# net rpc getsid netkitwg
mentre per le stazioni su segmenti esterni:
# net rpc getsid netkitwg -S istituto-PDC
Inoltre prima di far partire il servizio samba sono impostate
nel file /var/lib/samba/wins.dat
le entry
statiche NetBIOS per i server WINS di PDC, BDC1 e BDC2.
In seguito occorre per prima cosa impostare sul
istituto-PDC la password di Administrator (not24get):
root@istituto-PDC# smbldap-passwd Administrator
e successivamente uniamo al dominio tutte le macchine:
root@istituto-PDC# net rpc join -U Administrator%not24get root@ACLNT-A1# net rpc join -U Administrator%not24get root@istituto-BDC-A2# net rpc join -U Administrator%not24get -S istituto-PDC root@ACLNT-A2# net rpc join -U Administrator%not24get -S istituto-PDC root@Bistituto-DC-A3# net rpc join -U Administrator%not24get -S istituto-PDC root@ACLNT-A3# net rpc join -U Administrator%not24get -S istituto-PDC
Al termine dello script lab
la situazione dell'albero LDAP visualizzato da gq
è la
seguente ed
ecco uno
screenshot
del desktop.
Ora costruiamo un gruppo di prova g-prova e un
utente u-prova del gruppo appena costruito:
root@istituto-PDC# smbldap-groupadd -a -r 600 g-prova root@istituto-PDC# smbldap-useradd -a -G g-prova -c "Utente di Prova" \ -B 1 -m -P -F \\\\istituto-PDC\\profiles\\foo u-prova
Per trovare l'IP address del master browser per il workgroup
NetkitWG:
root@ACLNT-A1# nmblookup -M netkitwg querying Netkitwg on 192.168.10.255 192.168.10.1 Netkitwg<1d> root@ACLNT-A2# nmblookup -M netkitwg querying Netkitwg on 192.168.20.255 192.168.20.1 Netkitwg<1d> root@ACLNT-A3# nmblookup -M netkitwg querying Netkitwg on 192.168.30.255 192.168.30.1 Netkitwg<1d>
Per quanto riguarda il servizio NSS per poter visualizzare
le password occorre che il servizio faccia il bind come
utente abilitato nelle ACL di ldap.
Abbiamo scelto di abilitare questa funzionalità solo
sui server ldap ed istituto-PDC.
Il file che contiene la password in chiaro è
/etc/ldap.secret e
ovviamente il proprietario è root e
i permessi sono 600. Sconsigliamo l'uso di questa configurazione
su macchine accessibili fisicamente da personale non autorizzato.
Verifichiamo la configurazione appena descritta in tre macchine
distinte:
root@istituto-PDC# smbldap-passwd toni Changing password for toni New password : not24get Retype new password : not24get root@ldap# getent shadow | grep toni toni:LPldZpPhmwaYE:::::::0 root@istituto-PDC# getent shadow | grep toni toni:LPldZpPhmwaYE:::::::0 root@istituto-BDC-A2# getent shadow | grep toni toni:x:::::::0
Aggancio con la macchina reale |
|
In aggiunta se
configuriamo
la macchina reale come server Samba che accetta
e compie announce remote dalla rete virtuale allora le eventuali macchine
Samba della rete reale possono avere servizio dalle macchine Samba virtuali.
Per ottenere questo funzionamento procediamo come segue:
da utente root ci
posizioniamo sulla directory dove abbiamo
scompattato il file compresso Samba.tgz e diamo i seguenti comandi:
root@realHost# cp r-smb.conf /etc/samba/smb.conf root@realHost# /etc/init.d/smb start
Nel caso di una Knoppix dove non abbiamo la possibilità di
modificare i file della directory /etc diamo invece i comandi:
root@realHost# /usr/sbin/nmbd -s r-smb.conf root@realHost# /usr/sbin/smbd -s r-smb.conf
infine aggiungiamo tre regole di routing una per rete:
root@realHost# route add -net 192.168.10.0/24 gw 192.168.77.2 root@realHost# route add -net 192.168.20.0/24 gw 192.168.77.2 root@realHost# route add -net 192.168.30.0/24 gw 192.168.77.2
Ora dalla macchina reale è possibile ottenere servizio e/o sfogliare le risorse del virtuale:
user@realHost$ smbclient -L ISTITUTO-PDC -N user@realHost$ nmblookup -U 192.168.10.1 -R ISTITUTO-BDC-A2
o nel caso usiamo Knoppix:
user@realHost$ smbclient -s r-smb.conf -L ISTITUTO-PDC -N user@realHost$ nmblookup -s r-smb.conf -U 192.168.10.1 -R ISTITUTO-BDC-A2
|
|
Sandro Doro (email me)
