14.3. Tipi di server Samba e file smb.conf

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.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:

root# kinit [email protected]

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.1. Primary Domain Controller (PDC) usando tdbsam

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.

14.3.3.2. Primary Domain Controller (PDC) usando 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.

14.3.3.3. Backup Domain Controller (BDC) usando LDAP

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.