La configurazione di Samba � molto semplice, Tutte le modifiche di Samba sono fatte nel file di configurazione /etc/samba/smb.conf. Anche se il file di default smb.conf � documentato molto bene, esso non risolve le problematiche pi� complesse come ad esempio LDAP, Active Directory, e le numerose implementazioni del controller del dominio.
Le seguenti sezioni descrivono i vari modi per configurare un server Samba. Tenete presente le vostre esigenze e le varie modifiche del file smb.conf necessarie per effettuare una configurazione corretta.
14.3.1. Server di tipo Stand-alone
Un server di tipo stand-alone pu� essere sia un server di tipo workgroup oppure un membro di un ambiente workgroup. Un server stand-alone non rappresenta un domain controller, e non partecipa in un dominio in alcun modo. I seguenti esempi mostrano diverse configurazioni di sicurezza 'share-level' anonime, ed una configurazione sicura 'user-level'. Per maggiori informazioni sulle modalit� di sicurezza share-level e user-level consultate la Sezione 14.4.
14.3.1.1. Read-Only Anonimo
Il file smb.conf mostra un esempio di configurazione necessaria per implementare un file sharing di sola lettura anonimo. Il parametro security = share rende una condivisione anonima. Nota bene, il livello di sicurezza per un server Samba singolo non pu� essere diversificato. La direttiva security rappresenta un paramentro Samba globale, e si trova nella sezione di configurazione [global] del file smb.conf.
[global]
workgroup = DOCS
netbios name = DOCS_SRV
security = share
[data]
comment = Documentation Samba Server
path = /export
read only = Yes
guest only = Yes
14.3.1.2. Lettura/Scrittura anonima
Il file smb.conf mostra un esempio di configurazione necessaria per implementare un file sharing di lettura/scrittura anonimo. Per abilitare il file sharing di lettura/scrittura anonimo, impostare la direttiva read only su no. Le direttive force user e force group vengono aggiunte per rinforzare l'ownership di qualsiasi nuovo file specificato nella condivisione.
Nota Bene
Anche se � possibile avere un server di lettura/scrittura anonimo, questo non � consigliato. A qualsiasi file che si trova nello spazio di condivisione, senza tener conto dell'utente, viene assegnato una combinazione utente/gruppo, come specificato da un utente generico (force user) e gruppo (force group), nel file smb.conf.
[global]
workgroup = DOCS
netbios name = DOCS_SRV
security = share
[data]
comment = Data
path = /export
force user = docsbot
force group = users
read only = No
guest ok = Yes
14.3.1.3. Server di stampa anonimo
Il file smb.conf mostra un esempio di configurazione necessario per implementare un server di stampa anonimo. Impostando browseable su no, non viene elencata la stampante in Windows Risorse di Rete 'Network Neighborhood'. Anche se nascosto dal browsing, � possibile configurare la stampante. Collegandosi a DOCS_SRV usando NetBIOS, il client pu� accedere alla stampante se lo stesso client f� parte del workgroup DOCS. Si presume anche che il client abbia installato il corretto driver della stampante locale, in quanto la direttiva use client driver � impostata su Yes. In questo caso, il server Samba non ha alcuna responsabilit� per la condivisione dei driver di stampa col client.
[global]
workgroup = DOCS
netbios name = DOCS_SRV
security = share
printcap name = cups
disable spools= Yes
show add printer wizard = No
printing = cups
[printers]
comment = All Printers
path = /var/spool/samba
guest ok = Yes
printable = Yes
use client driver = Yes
browseable = Yes
14.3.1.4. File sicuri Read/Write e server di stampa
Il file smb.conf mostra un esempio di configurazione necessaria per implementare un server di stampa di lettura/scrittura sicuro. Impostando la direttiva security su user, si forza Samba all'autenticazione dei collegamenti client. Notate che la condivisione [homes] non possiede una direttiva force user o force group al contrario della condivisione [public]. La condivisione [homes] utilizza le informazioni dell'utente autenticato, per qualsiasi file creato in contrapposizione a force user e force group in [public].
[global]
workgroup = DOCS
netbios name = DOCS_SRV
security = user
printcap name = cups
disable spools = Yes
show add printer wizard = No
printing = cups
[homes]
comment = Home Directories
valid users = %S
read only = No
browseable = No
[public]
comment = Data
path = /export
force user = docsbot
force group = users
guest ok = Yes
[printers]
comment = All Printers
path = /var/spool/samba
printer admin = john, ed, @admins
create mask = 0600
guest ok = Yes
printable = Yes
use client driver = Yes
browseable = Yes
14.3.2. Server del Membro del Dominio
Un membro del dominio, anche se simile ad un server di tipo stand-alone, viene registrato nel domain controller (Windows o Samba), ed � soggetto alle regole di sicurezza del dominio. Un esempio di server del membro del dominio � rappresentato da un server dipartimentale in grado di eseguire Samba, il quale possiede un account della macchina sul Primary Domain Controller (PDC). Tutti i department client eseguono l'autenticazione con il PDC, includendo i profili desktop e tutti i file della policy di rete. La differenza � che il server dipartimentale possiede l'abilit� di controllare le condivisioni di rete e di stampa.
14.3.2.1. Active Directory Domain Member Server
Il file smb.conf mostra un esempio di configurazione necessaria per implementare un Active Directory domain member server. In questo esempio, Samba esegue l'autenticazione degli utenti per i servizi eseguiti in modo locale, esso rappresenta anche un client dell'Active Directory. Assicuratevi che i vostri parametri realm di kerberos siano mostrati in modo completo (per esempio realm = EXAMPLE.COM). Poich� Windows 2000/2003 ha bisogno di Kerberos per l'autenticazione dell'Active Directory, � necessaria la direttiva realm. Se Active Directory e Kerberos sono in esecuzione su diversi server, potrebbe essere necessaria la direttiva password server per aiutare la suddetta distinzione.
[global]
realm = EXAMPLE.COM
security = ADS
encrypt passwords = yes
# Optional. Use only if Samba cannot determine the Kerberos server automatically.
password server = kerberos.example.com
Per poter unire un member server su di un Active Directory domain, � necessario completare le seguenti fasi:
Configurazione del file smb.conf sul member server
Configurazione di Kerberos, incluso il file /etc/krb5.conf sul member server
Creazione dell'account della macchina sull'Active Directory domain server
Associazione del member server sull'Active Directory domain
Per creare l'account della macchina e ottenere il Windows 2000/2003 Active Directory, � necessario inizializzzare prima Kerberos per i member server che desiderano unirsi all'Active Directory domain. Per creare un ticket amministrativo di Kerberos, digitare il seguente comando come utente root sul member server:
Il comando kinit � uno script di inizializzazione di Kerberos che f� riferimento all'Active Directory administrator account e al realm di Kerberos. Poich� l'Active Directory ha bisogno dei ticket di Kerberos, kinit ottiene e conserva il ticket proveniente dal kerberos ticket-granting per l'autenticazione del client/ server. Per maggiori informazioni su Kerberos, sul file /etc/krb5.conf e sul comando kinit, consultate il Capitolo 19.
Per far parte di un Active Directory server (windows1.example.com), digitare il seguente comando come utente root sul member server:
root# net ads join -S windows1.example.com -U administrator%password
Poich� la macchina windows1 � stata trovata automaticamente nel realm del kerberos corrispondente (Il comando kinit successivo), il comando net si collega all'Active Directory server utilizzando l'account dell'amministratore e la password. Ci� crea l'account corretto della macchina sull'Active Directory e garantisce i permessi al server del membro di dominio Samba in modo da unirsi al dominio.
Nota Bene
Poich� viene utilizzato security = ads e non security = user, � necessario una password backend locale come ad esempio smbpasswd. I client pi� vecchi che non supportano security = ads, vengono autenticati come se security = domain sia stato impostato. Questa modifica non influenza la funzionalit� e abilita gli utenti locali all'interno del dominio.
14.3.2.2. Domain Member Server basato su Windows NT4
Il file smb.conf mostra un esempio di configurazione necessaria per implementare un domain member server basato su Windows NT4. Diventare un member server di un dominio basato su NT4, � simile ad un collegamento ad una Active Directory. La differenza sostanziale � che i domini basati su NT4 non utilizzano Kerberos nei loro metodi di autenticazione, rendendo il file smb.conf pi� semplice. In questo esempio, il Samba member server serve da pass fino al domain server basato su NT4.
[global]
workgroup = DOCS
netbios name = DOCS_SRV
security = domain
[homes]
comment = Home Directories
valid users = %S
read only = No
browseable = No
[public]
comment = Data
path = /export
force user = docsbot
force group = users
guest ok = Yes
Avere Samba come domain member server, pu� essere utile in molte situazioni. Ci sono momenti dove il server Samba pu� essere utile in determinate circostanze oltre al file sharing e al printer sharing. Potrebbe risultare utile fare di Samba un domain member server in casi dove solo le applicazioni Linux sono necessarie per un loro utilizzo nell'ambiente di dominio. Gli amministratori preferiscono avere informazioni su tutte le macchine presenti nel dominio, anche se non sono basate su Windows. Nel caso in cui non viene consigliato un server hardware basato su Windows, risulta semplice modificare il file smb.conf per convertire il server in un PDC basato su Samba. Se i server basati su Windows NT vengono migliorati ad una versione di Windows 2000/2003, il file smb.conf � facilmente modificabile in modo da integrare la modifica dell'infrastruttura in Active Directory se necessario.
Importante
Dopo aver configurato il file smb.conf, registratevi nel dominio prima di avviare Samba, potete fare questo digitando il seguente comando come utente root:
root# net rpc join -U administrator%password
Notate che l'opzione -S, la quale specifica il domain server hostname, non ha bisogno di essere presente nel comando net rpc join. Samba utilizza l'hostname specificato dalla direttiva workgroup nel file smb.conf, invece di essere esplicitamente mensionato.
14.3.3. Controller del Dominio
Un controller del dominio di Windows NT � simile in termini funzionali ad un server Network Information Service (NIS) in un ambiente Linux. I controller del dominio ed i server NIS, ospitano entrambi i database per le informazioni user/group ed i servizi relativi. Tali controller vengono usati principalmente per motivi di sicurezza, incluso per l'autenticazione degli utenti che hanno accesso alle risorse del dominio. Il servizio che mantiene l'integrit� del database user/group viene chiamato Security Account Manager (SAM). Il database SAM viene conservato in modo diverso tra i sistemi basati su Windows e quelli basati su Linux Samba, per questo motivo la replica di SAM non pu� essere eseguita, e le piattaforme non possono essere mischiate in un ambiente PDC/BDC.
In un ambiente Samba, ci pu� essere solo un PDC e zero o pi� BDC.
Importante
Samba non � in grado di esistere in un ambiente del tipo domain controller Samba/Windows misto (Samba non pu� essere un BDC di un PDC di Windows o viceversa). Alternativamente, i PDC ed i BDC di Samba possono coesistere.
L'implementazione pi� semplice e comune di un Samba PDC utilizza la password database backend tdbsam. Ideato per sostituire smbpasswd backend, tdbsam presenta numerosi miglioramenti, affrontati in dettaglio nella Sezione 14.5. La direttiva passdb backend controlla quale backend deve essere usato per il PDC.
[global]
workgroup = DOCS
netbios name = DOCS_SRV
passdb backend = tdbsam
security = user
add user script = /usr/sbin/useradd -m %u
delete user script = /usr/sbin/userdel -r %u
add group script = /usr/sbin/groupadd %g
delete group script = /usr/sbin/groupdel %g
add user to group script = /usr/sbin/usermod -G %g %u
add machine script = \
/usr/sbin/useradd -s /bin/false -d /dev/null \
-g machines %u
# The following specifies the default logon script
# Per user logon scripts can be specified in the user
# account using pdbedit
logon script = logon.bat
# This sets the default profile path.
# Set per user paths with pdbedit
logon path = \\%L\Profiles\%U
logon drive = H:
logon home = \\%L\%U
domain logons = Yes
os level = 35
preferred master = Yes
domain master = Yes
idmap uid = 15000-20000
idmap gid = 15000-20000
[homes]
comment = Home Directories
valid users = %S
read only = No
browseable = No
writable = Yes
[public]
comment = Data
path = /export
force user = docsbot
force group = users
guest ok = Yes
[netlogon]
comment = Network Logon Service
path = /var/lib/samba/netlogon/scripts
admin users = ed, john, sam
guest ok = No
browseable = No
writable = No
# For profiles to work, create a user directory under the
# path shown. mkdir -p /var/lib/samba/profiles/john
[Profiles]
comment = Roaming Profile Share
path = /var/lib/samba/profiles
read only = No
browseable = No
guest ok = Yes
profile acls = Yes
# Other resource shares
...
...
Nota Bene
Se avete bisogno di pi� di un controller del dominio o se avete pi� di 250 utenti, non utilizzate una autenticazione tdbsam backend. Vi consigliamo in questo caso LDAP.
L'implementazione pi� potente e versatile di un Samba PDC � rappresentata dalla sua abilit� di avere un LDAP password backend. LDAP � molto scalabile. I server del database di LDAP possono essere utilizzati per ridondanza e per fail-over, replicando ad un Samba BDC. Gruppi di LDAP PDC e BDC con un bilanciamento del carico, sono ideali per un ambiente enterprise. D'altro canto le configurazioni LDAP sono complesse da impostare e gestire. Se SSL deve essere incorporato con LDAP, la complessit� si raddoppia. Nonostante questo, con una pianificazione attenta e precisa, LDAP rappresenta la soluzione ideale per gli ambienti enterprise.
Notate la direttiva passdb backend insieme alle specificazioni del suffisso LDAP specifico. Anche se la configurazione Samba per LDAP � molto semplice, l'installazione di OpenLDAP non � semplice. LDAP dovrebbe essere installato e configurato prima di ogni configurazione Samba. Da notare anche che Samba e LDAP non hanno bisogno di essere sullo stesso server per poter funzionare. � consigliato separare i due in un ambiente enterprise.
[global]
workgroup = DOCS
netbios name = DOCS_SRV
passdb backend = ldapsam:ldap://ldap.example.com
username map = /etc/samba/smbusers
security = user
add user script = /usr/sbin/useradd -m %u
delete user script = /usr/sbin/userdel -r %u
add group script = /usr/sbin/groupadd %g
delete group script = /usr/sbin/groupdel %g
add user to group script = /usr/sbin/usermod -G %g %u
add machine script = \
/usr/sbin/useradd -s /bin/false -d /dev/null \
-g machines %u
# The following specifies the default logon script
# Per user logon scripts can be specified in the
# user account using pdbedit
logon script = scripts\logon.bat
# This sets the default profile path.
# Set per user paths with pdbedit
logon path = \\%L\Profiles\%U
logon drive = H:
logon home = \\%L\%U
domain logons = Yes
os level = 35
preferred master = Yes
domain master = Yes
ldap suffix = dc=example,dc=com
ldap machine suffix = ou=People
ldap user suffix = ou=People
ldap group suffix = ou=Group
ldap idmap suffix = ou=People
ldap admin dn = cn=Manager
ldap ssl = no
ldap passwd sync = yes
idmap uid = 15000-20000
idmap gid = 15000-20000
...
# Other resource shares
...
...
Nota Bene
Per poter implementare un LDAP all'interno del file smb.conf, �necessario installare correttamente un server LDAP funzionante su ldap.example.com.
BDC rappresenta una parte integrale di qualsiasi soluzione Samba/LDAP. I file smb.conf tra PDC e BDC sono virtualmente identici, ad eccezione della direttiva domain master. Assicuratevi che PDC abbia il valore Yes e che BDC abbia un valore No. Se avete BDC multipli per un PDC, la direttiva os level risulta essere utile nell'impostazione della priorit� di elezione di BDC. Pi� alto risulta essere il valore, e pi� alto � la priorit� del server per i client che si collegano.
Nota Bene
Un BDC � in grado di utilizzare il database LDAP del PDC, oppure il proprio database LDAP. Questo esempio utilizza il database LDAP del PDC come mostrato dalla direttiva passdb backend.
[global] workgroup = DOCS
netbios name = DOCS_SRV2
passdb backend = ldapsam:ldap://ldap.example.com
username map = /etc/samba/smbusers
security = user
add user script = /usr/sbin/useradd -m %u
delete user script = /usr/sbin/userdel -r %u
add group script = /usr/sbin/groupadd %g
delete group script = /usr/sbin/groupdel %g
add user to group script = /usr/sbin/usermod -G %g %u
add machine script = \
/usr/sbin/useradd -s /bin/false -d /dev/null \
-g machines %u
# The following specifies the default logon script
# Per user logon scripts can be specified in the
# user account using pdbedit
logon script = scripts\logon.bat
# This sets the default profile path.
# Set per user paths with pdbedit
logon path = \\%L\Profiles\%U
logon drive = H:
logon home = \\%L\%U
domain logons = Yes
os level = 35
preferred master = Yes
domain master = No
ldap suffix = dc=example,dc=com
ldap machine suffix = ou=People
ldap user suffix = ou=People
ldap group suffix = ou=Group
ldap idmap suffix = ou=People
ldap admin dn = cn=Manager
ldap ssl = no
ldap passwd sync = yes
idmap uid = 15000-20000
idmap gid = 15000-20000
...
# Other resource shares
...
...
14.3.3.4. Primary Domain Controller (PDC) con una Active Directory
Anche se risulta possibile per Samba essere membro di una Active Directory, non risulta possibile operare come un Active Directory domain controller.
