Small Business Server (Italiano)/File Server Domain Controller

From ArchWiki
Revision as of 13:25, 29 January 2008 by Steno (Talk | contribs) (New page: Category:ArchLinux Small Business Server = Introduzione = Questa parte della guida è, personale opinione, la più importante. Un file server in una azienda è sicuramente lo scopo pri...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Introduzione

Questa parte della guida è, personale opinione, la più importante. Un file server in una azienda è sicuramente lo scopo principale per cui si installa un server (almeno inizialmente). Oramai nessuno può svolgere i compiti principali senza condivisione di dati tra utenti, e le soluzioni peer to peer di condivisione hanno limiti che non stò neanche a considerare qui. Prima di proseguire permettetemi di sintetizzare dei concetti di base che devono essere ben chiari prima di passare alla fase di implementazione della rete vera e propria.

Samba

Con GNU/Linux ho diverse possibilità di scelta, ma io considererò solo la soluzione Sambache mi permette di interagire ottimamente con dei clients Microsoft Windows che, volenti o dolenti, rappresentano il 98% del mercato desktop. Samba è un grande, complesso progetto. Scopo del progetto è l’ interoperabilità il più trasparente possibile tra il mondo Microsoft Windows e i sistemi Unix/Linux. Samba offre servizi di autenticazione e condivisione file e stampanti da una qualsiasi piattaforma TCP/IP enabled. Le piattaforme originali erano Unix e Linux,ma oggi vengono impiegati con successo anche altri tipi di sistemi.

Cos’e’ questa guida ?

Ricordo ancora che questa guida NON è una guida completa a Samba e OpenLDAP, oltre a quanto già ribadito presuppone anche che abbiate già una buona conoscenza di come funziona una rete Windows basata su un dominio. Lo scopo che ci prefiggiamo qui è quello di descrivere in modo abbastanza esteso un caso di reale implementazione di una rete che utilizzano Microsoft Windows sui loro desktop e Linux, Samba e OpenLDAP su lato server in sostituzione dei prodotti server di Microsoft. Essendo un progetto di una certa complessità non bisogna trascurare il fatto che leggere le guide “ufficiali” molto ben fatte e aggiornate che trovate sul sito è molto più di un consiglio: fare le cose senza capirle bene è una pessima abitudine.

Samba Server è meglio di Windows Server ?

Ad essere sinceri, secondo me, la risposta è NO. Samba è fantastico nel “mascherare” le evidenti differenze tra le piattaforme Windows e Linux/Posix, il risultato non è perfetto, ma essendo un prodotto il continua e veloce evoluzione queste “imperfezioni” sono sempre meno percettibili. Và comunque detto che queste “imperfezioni” non si riferiscono alle funzionalità nei servizi offerti da Samba (questi oramai hanno raggiunto un grado di affidabilità molto elevata, considerando il fatto che milioni di PC nel mondo usano questi servizi), ma bensì al fatto di far credere ai client Windows che dalla parte server non c’e’ Samba ma un “regolare” server Windows. Non tutte le funzionalità sono state implementate (ad esempio i gruppi nidificati e le utili Group Policy) e quindi se voglio usare Samba qualche caratteristica avanzata deve essere lasciata da parte. Queste “mancanze” saranno dei macigni per un fido Microsoft sponsor, dei sassolini per chi, come me, non ama le guerre di religione Microsoft/Linux, ma cerca di cavare il meglio dalle due piattaforme. Pane al pane, vino al vino: Windows sui Desktop (per ora) e, ove possibile e conveniente, Linux sui Server. Ricordiamoci, inoltre, che Samba NON puo’ agire come ADS (Active Directory) Domain Controller (Windows 2000/2003 server), ma puo’ efficacemente diventarne membro come server aggiuntivo. La funzionalità ADS domain controller sarà inclusa nella versione 4 di Samba ora in fase di sviluppo. Samba 3 puo’ “emulare” un Domain Controller stile Windows NT 4 anche se con notevoli miglioramenti nella scalabilità dovuti in gran parte alla adozione di OpenLDAP come possibile backend (repository) per utenti, gruppi e passwords. Naturalmente dei server Windows 2000 o 2003 possono efficacemente essere inseriti in un dominio controllato da Samba 3 come server membri.

Ma allora perché usare Samba ?

I motivi possono essere molti. Vi posso dire i miei personali. Ho optato per Samba perché :

  • Salute. Mi viene il mal di testa quando leggo le politiche licensing di Microsoft, non per i costi ma per il garbuglio di opzioni che cambiano ad ogni quando. Con Linux/Samba questi pensieri svaniscono per sempre.
  • Risparmio. Fate voi il conto di quanto costano le licenze per un dominio con il numero di PC nella vostra rete e il server. Attenzione però, inutile illudersi, generalmente i costi di manutenzione sono grossomodo gli stessi.
  • Sicurezza. Non voglio sindacare sul livello di sicurezza raggiunto da Windows (dipende naturalmente anche da chi lo installa), ma il fatto che Linux è molto meno preso di mira da virus e allegra brigata mi fa dormire sonni più tranquilli.
  • Single Signon. Con OpenLDAP riesco ad avere un unico repository dei dati utenti/password per tutti i servizi e server aziendali (posta, rete ecc.). Il cambio password di un utente non è più un incubo, ogni Desktop o Server, Windows o Linux che sia, viene autenticato centralmente nell’ albero OpenLDAP.

E’ più facile usare/amministrare Windows o Linux/Samba ?

Qui sarebbe difficile trovare due persone con la stessa opinione. Personalmente vi posso dire che Windows e il suo Active Directory Services (ADS è un LDAP pesantemente personalizzato da Microsoft per lo scopo) è un eccellente prodotto e capire come realizzare un dominio con esso vuol dire masticare argomenti disparati quali LDAP, DNS, DHCP, TCP/IP, KERBEROS, WINS, e tutti gli aspetti inerenti ad una rete Microsoft: Primary Domain Controller (PDC), Backup Domain Controller (BDC), Browsing della rete, Access Control List (ACL) alle share, Profili Roaming eccetera. Insomma l’argomento è complesso, e avventurarsi in una installazione di questo tipo senza padroneggiare questi concetti è una PESSIMA IDEA. E con Linux/Samba ? Stessa cosa, devo avere alba di cosa sia Linux, come si installa e come si amministra in modo almeno basilare, oltre a tutte le cose dette per Windows: LDAP, DNS, WINS, PDC, BDC, ACL, Profili Roaming ecc.. Ovviamente anche con Samba ci scontreremo con questi concetti basilari. Alla fine della fiera la differenza sarà che con Windows ho dei comodi (ma a parer mio a volte diseducativi) tools grafici per fare il tutto, con Linux un mix tra tools grafici e cari e vecchi (ma efficaci) tools da linea di comando.

Sostituisco i miei server Windows con Linux/Samba ?

Mah, dipende. Se ho già un dominio Windows 2000/2003 ADS funzionante significa che ho già investito in licenze ed ammennicoli vari e sostituirlo con Samba non è che porta a svolte miracolose. Io eviterei, ribadisco che ADS è un buon prodotto. Se invece devo aggiungere un file server al dominio ADS, Samba puo’ essere una valida opzione. Diverso il caso in cui dovessi aggiornare dei server Windows NT che ora Microsoft non segue più. Anche in questo caso la migrazione a Samba può essere una valida opzione.

N.B. Se ho più server ricordiamoci un concetto importante : Se il PDC è Windows il/i BDC devono essere Windows, i server membri aggiuntivi sia Samba che Windows. Se il PDC è Samba il/i BDC devono essere Samba, i server membri aggiuntivi sia Samba che Windows.

Bene, ora che è tutto chiaro (...) con possiamo iniziare :) .

Installazione

Cominciamo con la configurazione del nostro file server domain controller basato su Samba e OpenLDAP. Come primo passo dedichiamoci all' installazione dei pacchetti necessari.

Operazioni preliminari

In questo tipo di configurazioni è bene concentrarci sul singolo problema, evitando di correr dietro a cause esterne dovute ad altri servizi. Tutto questo per dire che se per caso avete attivato il firewall è giunto il momento di disattivarlo momentaneamente. Quando tutto funzionerà a dovere lo ripristineremo con le rules aggiuntive opportune. Quindi:

sudo /etc/rc.d/shorewall stop

In più abilitiamo momentaneamente **tutti** i protocolli :

sudo nano /etc/hosts.allow

e aggiungiamo la riga

all: ALL : allow

Bene, ora che abbiamo eliminato eventuali cause esterne possiamo proseguire.

Il repository radioattivo

Durante l'installazione ho, purtroppo, constatato che i pacchetti necessari in questa impresa non sono tutti disponibili né sui repository ufficiali nè su AUR. Certo, essendo degli script perl e delle librerie dello stesso, avrei potuto usare CPAN ed installare gli script a mano, ma finché posso voglio evitare questa pratica e allora (rullo di tamburi:)) ho creato un piccolo e radioattivo repository personale con quello che ci serve. Creare un repository con Arch è veramente una operazione banale con il comando repo-add, un po' più complicati sono i PKGBUILD. Di grande aiuto mi è stata l'utility cpan4pacman installata nel primo capitolo di questa serie, che mi ha creato i PKGBUILD per le librerie perl mancanti, appena un po' più complesso il pacchetto smbldap-tools che ho dovuto fare da zero (o quasi). Perchè radioattivo ? Perchè ho ignorato tutte le opzioni di verifica delle dipendenze e i checksum MD5. Sono script in perl, di bassa pericolosità, ma naturalmente non mi assumo responsabilità.

Attiviamo il repository

sudo nano /etc/pacman.conf

aggiungiamo in fondo :

[stenoweb]
Server = http://www.stenoweb.it/repo/i686

e per finire aggiorniamo la lista dei pacchetti "risucchiando" la lista anche dal repo stenoweb:

sudo pacman -Sy

Bene ! Non dovreste ottenere errori.

Installazione pacchetti

Samba

Ma come diavolo si installerà Samba ? io proverei con un:

sudo pacman -S samba

Funziona ! Scusate non ho resistito ...

LDAP Tools

E qui interviene il mio repository. Gli LDAP Tools sono degli script realizzati in perl che permettono di gestire utenti e gruppi Samba/Unix salvando i dati sull'albero LDAP anziché sui file /etc/passwd e /etc/group. In pratica sostituiscono i vari comandi standard linux di gestione degli utenti. Iniziamo con installare le librerie perl necessarie :

sudo pacman -S perl-digest-sha1 perl-crypt-smbhash perl-jcode perl-unicode-map perl-unicode-map8 perl-unicode-maputf8 perl-unicode-string perl-ldap perl-io-socket-ssl 

e poi il pacchetto vero e proprio con gli scripts:

sudo pacman -S smbldap-tools

Gli script sono stati copiati/installati in /usr/local/bin e i file di configurazione in /etc/smbldap-tools. I comandi sono nella forma (ad esempio per aggiungere un utente) :

sudo /usr/local/bin/smbldap-useradd nomeutente

ma non provateci adesso, mancando la necassaria configurazione otterrete solo un errore. Ho fatto qualcosa in più: data la lunghezza del comando lo script di installazione del pacchetto crea anche dei link simbolici di più agevole forma in /bin. Il comando di prima diventerà il più semplice:

sudo netuseradd nomeutente

Prolunghiamo la vita alle nostre tastiere! :)

Samba LDAP Schema

Per ultimo abbiamo bisogno del file di schema da applicare a OpenLDAP per memorizzare i dati di cui ha bisogno Samba. Cos'e' un file di schema ? LDAP in buona sostanza è un database, lo schema non è altro che il tracciato record che descrive, dichiara e crea i campi nel database LDAP. Nello schema Samba ci sono i campi per il nome utente, la password, la home, i gruppi ecc. che servono a memorizzare i nostri dati nell'albero LDAP. Il file samba.schema di cui abbiamo bisogno è fornito con i sorgenti di Samba: anziché scaricare i 17MB, scompattare e recuperare il file ve lo fornisco io direttamente. Spostiamoci nella cartella degli schemi di OpenLDAP :

cd /etc/openldap/schema

e scarichiamoci lo schema:

sudo wget http://www.stenoweb.it/repo/noarch/samba.schema

Configurazione

Dopo aver installato tutti i pacchetti necessari cominciamo con la configurazione di OpenLDAP e la inizializzazione del suo database con gli utenti e gruppi di default richiesti da un dominio stile Microsoft.

OpenLDAP server

Abbiamo già configurato in modo basilare OpenLDAP in un precedente articolo, ora rimettiamo mano alla configurazione per includere ciò di cui ha bisogno samba.

sudo nano /etc/openldap/slapd.conf

Includiamo gli schemi necessari all'inizio (nis e samba):

include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/samba.schema

Impostiamo le regole di accesso :

access to dn.base=""
               by self write
               by * auth
access to attrs=userPassword,sambaNTPassword,sambaLMPassword
       by dn="cn=Manager,dc=mede,dc=it" write
       by anonymous auth
       by self write
       by * none
access to *
               by * read
               by anonymous auth

Soffermiamoci su di un aspetto: il rootdn cn=Manager,dc=mede,dc=it ha comunque accesso ai dati in lettura scrittura anche se non specifico nulla, ma di particolare importanza è la regola di accesso access to attrs=userPassword,sambaNTPassword,sambaLMPassword che di fatto permette ai singoli utenti di cambiare la propria passaword direttamente da Windows. Per ultima cosa definiamo gli indici di ricerca per velocizzare gli accessi all'albero ldap (eliminate le voci "index" già presenti e sostituitele con queste) :

# Indices
index objectClass           eq
index cn                    pres,sub,eq
index sn                    pres,sub,eq
index uid                   pres,sub,eq
index displayName           pres,sub,eq
index uidNumber             eq
index gidNumber             eq
index memberUID             eq
index sambaSID              eq
index sambaPrimaryGroupSID  eq
index sambaDomainName       eq
index default               sub

Per attivare le nuove impostazioni riavviamo il servizio:

sudo /etc/rc.d/slapd restart

Il nostro albero è pronto.

LDAP Tools

Gli LDAP tools sono necessari per gestire utenti e gruppi, per poterli utilizzare dobbiamo configurarli a dovere. Per prima cosa diamo un file di configurazione di base a Samba :

sudo nano /etc/samba/smb.conf

e inseriamo :

[global]
       unix charset = LOCALE
       workgroup = MEDE
       netbios name = ARCHI
       server string = %h PDC (%v)
       interfaces = eth1, lo
       bind interfaces only = Yes
       enable privileges = yes
       guest account = guest
       domain logons = Yes
       domain master = yes
       preferred master = Yes
       os level = 65
       wins support = Yes
       security = user
       ldap suffix = dc=mede,dc=it
       ldap user suffix = ou=Users
       ldap machine suffix = ou=Computers
       ldap group suffix = ou=Groups
       ldap idmap suffix = ou=Idmap
       ldap admin dn = cn=Manager,dc=mede,dc=it
       idmap backend = ldap:ldap://archi.mede.it
       idmap uid = 10000-20000
       idmap gid = 10000-20000
       ldap passwd sync = Yes
      #ldap ssl = start tls
       ldap ssl = no

Come si può notare al momento (ricordo che il servizio samba non è stato ancora avviato) forniamo sono i dati essenziali, quali il dominio (workgroup = MEDE), il nome del server (netbios name = ARCHI), il suo ruolo di Domain Controller (domain logons = Yes) e i parametri LDAP. Sugli altri parametri consiglio una buona guida di Samba o le sue manpage :). Come secondo passo prendiamo nota del SID del nostro server:

sudo net getlocalsid

dovrei ottenere qualcosa del tipo:

SID for domain ARCHI is: S-1-5-21-1491279793-2809991009-2777690449

Ora editiamo i file di configirazione dei smbldap-tools:

nano /etc/smbldap-tools/smbldap.conf

e scorrendo i parametri impostamoli così:

#Il SID ricavato con il comando precedente
SID="S-1-5-21-1491279793-2809991009-2777690449"
sambaDomain="MEDE"
suffix="dc=mede,dc=it"
hash_encrypt="MD5"
defaultMaxPasswordAge="180"
userSmbHome=""
userProfile=""
userHomeDrive="K:"
userScript="%U.bat"
mailDomain="mede.it"

Gli altri lasciamoli con i valori di default. Salviamo e editiamo il file:

sudo nano /etc/smbldap-tools/smbldap_bind.conf

e facciamo diventare così:

slaveDN="cn=Manager,dc=mede,dc=it"
slavePw="archimede"
masterDN="cn=Manager,dc=mede,dc=it"
masterPw="archimede"

Ricordo che "archimede" è la password che ho deciso per l'amministratore LDAP, la stessa che ho messo in /etc/openldap/slapd.conf in formato MD5. Finito questo proteggiamo i file da occhi indiscreti:

sudo chmod 0644 /etc/smbldap-tools/smbldap.conf
sudo chmod 0600 /etc/smbldap-tools/smbldap_bind.conf

Ora non ci resta che dire anche a Samba la password da utilizzare per accedere a LDAP:

sudo smbpasswd -w archimede

se ottenete una risposta del tipo:

Setting stored password for "cn=Manager,dc=mede,dc=it" in secrets.tdb

Significa che fino ad ora tutto và per il verso giusto, e possiamo proseguire.

Popolare LDAP

Per il funzionamento corretto SAMBA ha bisogno di diversi gruppi predefiniti e 2 utenti: Administrator e guest. Inoltre, affinché si riesca ad aggiungere computer al dominio in modo automatico (da macchine Windows), deve esistere un utente con uid = 0 da utilizzare per questa operazione. Tale utente può essere un utente root (da aggiungere a mano) o lo stesso Administrator cambiandogli l'uid. Quest'ultima è la scelta presa in questa configurazione, in modo da avere un utente Administrator che è Administrator per Samba e root per il "dominio" UNIX. Gli ldap tools forniscono un comodo comando per svolgere questa operazione: smbldap-populate. Lanciamolo così con questi parametri:

sudo /usr/local/bin/smbldap-populate -a Administrator -u 5001 -g 5001 -r 5001 -b guest -l 5000

al termine ci viene chiesta la password di "Administrator", mettiamo la stessa di root per non fare confusione. Dovrei vedere qualcosa del genere :

Populating LDAP directory for domain MEDE (S-1-5-21-1491279793-2809991009-2777690449)
(using builtin directory structure)
 
adding new entry: dc=mede,dc=it
adding new entry: ou=Users,dc=mede,dc=it
adding new entry: ou=Groups,dc=mede,dc=it
adding new entry: ou=Computers,dc=mede,dc=it
adding new entry: ou=Idmap,dc=mede,dc=it
adding new entry: uid=Administrator,ou=Users,dc=mede,dc=it
adding new entry: uid=guest,ou=Users,dc=mede,dc=it
adding new entry: cn=Domain Admins,ou=Groups,dc=mede,dc=it
adding new entry: cn=Domain Users,ou=Groups,dc=mede,dc=it
adding new entry: cn=Domain Guests,ou=Groups,dc=mede,dc=it
adding new entry: cn=Domain Computers,ou=Groups,dc=mede,dc=it
adding new entry: cn=Administrators,ou=Groups,dc=mede,dc=it
adding new entry: cn=Account Operators,ou=Groups,dc=mede,dc=it
adding new entry: cn=Print Operators,ou=Groups,dc=mede,dc=it
adding new entry: cn=Backup Operators,ou=Groups,dc=mede,dc=it
adding new entry: cn=Replicators,ou=Groups,dc=mede,dc=it
adding new entry: sambaDomainName=MEDE,dc=mede,dc=it
 
Please provide a password for the domain Administrator:
Changing UNIX and samba passwords for Administrator
New password:
Retype new password: 

Come possiamo notare smbldap-populate ha creato utenti e gruppi predefiniti in una installazione di windows server. Per vedere se tutto funziona proviamo a creare un utente user1:

sudo netuseradd -a -m user1

e diamogli una password :

sudo netpasswd user1

ora controlliamo se l'utente c'e':

sudo getent passwd

Dovrei ottenere la lista degli utenti tra cui :

Administrator:x:0:0:Netbios Domain Administrator:/home/Administrator:/bin/false
guest:x:5000:514:guest:/dev/null:/bin/false
user1:x:5001:513:System User:/home/user1:/bin/bash

per le opzioni complete digitiamo netuseradd senza parametri e diamo una occhiata. Nell'esempio il parametro -a crea sia l'utente unix che samba e -m crea la home (/home/user1) dell'utente.

Pianificazione condivisioni

E' (quasi) giunto il momento di avviare Samba, ma prima dobbiamo pianificare un po' COSA andremo a condividere e COME impostare gli accessi al file system (ACL). Quello che propongo qui è solo un esempio, i casi possono essere innumerevoli, ma secondo me questa rappresenta comunque una buona base di partenza.

Gruppi

Definiamo e creiamo un insieme di gruppi di utenti a cui poi assegnare una condivisione "privata". I nomi sono di fantasia (anche se non proprio :)):

Gruppo Descrizione
commerciale utenti ufficio commerciale
tecnico utenti ufficio tecnico
Domain Users gruppo che contiene tutti gli utenti

Domain Users è già stato creato con smbldap-populate. Ogni nuovo utente viene assegnato in modo automatico a questo gruppo.

Creiamo gli altri gruppi

sudo netgroupadd -a Commerciale
sudo netgroupadd -a Tecnico

Creiamo gli utenti

sudo netuseradd -a -m commerciale1
sudo netpasswd commerciale1
sudo netuseradd -a -m tecnico1
sudo netpasswd tecnico1

se abbiamo fatto tutto correttamente non dovrei vedere errori, controlliamo con:

sudo getent passwd

Alla fine dovrei vedere gli utenti appena creati:

commerciale1:x:5001:513:System User:/home/commerciale1:/bin/bash
tecnico1:x:5002:513:System User:/home/tecnico1:/bin/bash

Nota: come possiamo vedere ad ogni utente viene concesso l'accesso shell (/bin/bash). Se vogliamo togliere questo privilegio basta modificare l'utente (ad esempio tecnico1) così:

sudo netusermod -s /bin/false tecnico1  

Assegniamo gli utenti ai gruppi

sudo netgroupmod -m commerciale1 Commerciale
sudo netgroupmod -m tecnico1 Tecnico

Anche qui possiamo controllare con :

sudo getent group

e ottenere qualcosa del genere:

Commerciale:*:5001:commerciale1
Tecnico:*:5002:tecnico1

I comandi net* li trovo in /bin: è utile prendere dimestichezza con questi per amministrare utenti e gruppi.

Condivisioni

Vediamo ora cosa andremo a condividere, ho deciso di mettere tutto (tranne le home directory) in /samba:

Condivisione Percorso Descrizione
public /samba/public Cartella pubblica. Contiene una cartella per ogni gruppo (vedi dopo)
netlogon /samba/netlogon Cartella di sistema necessaria in un domain controller. Contiene gli script di login utente.
profiles /samba/profiles Cartella di sistema. Mi serve se uso i Profili Roaming di windows.
rootdir /samba Condivisione ad uso backup. Contiene anche i symlink ai file più importanti del mio server
apps /samba/apps Cartella applicazioni. Sola lettura
homes /home Cartelle home per gli utenti. Ognuno la sua.

public

Questa condivisione è la principale, anziché creare una condivisione per ogni gruppo ho deciso di mettere tutto dentro a public e di "giocare" poi con i permessi sulle cartelle. Per capirci meglio :

/samba/public di proprietà di root/Administrator solo leggibile dagli altri
/samba/public/commerciale Cartella per gruppo "Commerciale"
/samba/public/tecnico Cartella per gruppo "Tecnico"
/samba/public/comune Cartella condivisa di tutti ("Domain Users")

Poi andremo a mappare una unità L: (a scelta) sulla condivisione "public" e gli utenti del gruppo "Commerciale" vedranno L:\COMUNE e L:\COMMERCIALE, gli utenti del gruppo "Tecnico" vedranno solo L:\COMUNE e L:\TECNICO. Nessuno (tranne i membri del gruppo "Domain Admins", off course) possono creare files o cartelle nella root di L:. Tengo a precisare che questa non è una regola ma una mia personale idea su come organizzare le condivisioni. Quando abbiamo a che fare con molti gruppi ritengo abbastanza noioso e confusionario fare condivisioni separate. Un utente membro di diversi gruppi si troverebbe con molte mappature diverse che esauriscono in breve l'alfabeto. In questo modo ho una unica mappatura (L:\) e ognuno vedrà le sottocartelle a cui avrà accesso. Molto più ordinato e comodo. Questo tipo di organizzazione è la stessa che usavo quando installavo Novell Netware 10-15 anni fà, e quindi non ha niente di specifico di Samba o di Windows. Quindi creiamo la struttura :

sudo mkdir /samba/public
sudo mkdir /samba/public/commerciale
sudo mkdir /samba/public/tecnico
sudo mkdir /samba/public/comune

e sistemiamo i permessi e la proprietà :

sudo chmod 770 /samba/public/commerciale
sudo chgrp Commerciale /samba/public/commerciale
sudo chmod 770 /samba/public/tecnico
sudo chgrp Tecnico /samba/public/tecnico
sudo chmod 770 /samba/public/comune
sudo chgrp "Domain Users" /samba/public/comune

Controlliamo cosa abbiamo combinato:

ls -al /samba/public

e dovrei vedere qualcosa del genere:

drwxr-xr-x 5 root root         4096 17 dic 16:24 .
drwxr-xr-x 7 root root         4096 12 dic 16:11 ..
drwxrwx--- 2 root Commerciale  4096 17 dic 16:24 commerciale
drwxrwx--- 2 root Domain Users 4096 17 dic 16:24 comune
drwxrwx--- 2 root Tecnico      4096 17 dic 16:24 tecnico

La "rogna" dei permessi utente

Ora che abbiamo dato i permessi alle cartelle ci troviamo di fronte ad un problema inaspettato. Quando gli utenti creano nuovi files o cartelle nelle condivisioni questi vengono flaggati con utente=UtenteCreatore e gruppo=GruppoDefaultUtente. Il gruppo di default è "Domain Users", quindi tutti i nuovi files vengono impostati con questo gruppo. Dunque i nuovi files creati in "commerciale" sono potenzialmente a disposizione anche degli utenti del gruppo "Tecnico", essendo anche questi membri del gruppo "Domain Users". In questo caso sono protetti dai permessi della cartella stessa, ma potrebbe non essere così in un altro caso. L'utente "Administrator" ha come gruppo di default "Domain Admins", quindi ogni file creato/copiato/ripristinato dall'amministratore risulta non accessibile dagli utenti "normali". Indubbiamente una bella rottura di scatole dover ogni volta reimpostare a mano i permessi sui files manipolati dall'amministratore ... Ma non disperate ! :) Ci viene in aiuto il flag SETUID di unix. Se leggete l'articolo linkato sembra non centrare una benemerita fava con l'argomento in questione, ma in questo caso l'effetto del flag è quello da noi voluto. In pratica abilitiamo il flag sul gruppo in questo modo :

sudo chmod g+s /samba/public/commerciale
sudo chmod g+s /samba/public/tecnico
sudo chmod g+s /samba/public/comune

se ricontrollo ora con ls -al dovrei vedere che la tripletta dei permessi sul gruppo è cambiata da rwx a rws che indica, appunto, che è attivo il setuid. Cosa provoca questo ? Questo trucchetto fà si che ogni file creato nelle cartelle avrà come gruppo proprietario il guppo della cartella e non quello dell'utente. Quindi ogni file, ad esempio, creato in "commerciale" avrà come gruppo proprietario "Commerciale" che corrisponde al gruppo proprietario della cartella. Ora potete usare anche "Administrator" per ripristinare o creare files che saranno accessibili agli utenti normali. Fiuuuuuu. Andiamo avanti.

netlogon & profiles

Queste sono due condivisioni di sistema, necessarie quando si configura un domain controller. In netlogon si saranno gli script di login degli utenti (che vedremo come creare al "volo" in modo dinamico), in profiles ci saranno i profili utente nel caso avessimo deciso di usare i profili roaming di Microsoft (utili i certi casi, ma a me, idea personalissima, non piacciono). Creiamo le certelle e diamo i permessi :

sudo mkdir /samba/netlogon
sudo mkdir /samba/profiles
chmod 777 /samba/profiles

rootdir

Questa è una condivisione di "comodo" accessibile solo all'amministratore. Creiamo anche una cartella system con i link simbolici alle cartelle o ai file che poi potremmo salvare via condivisione samba da un altro PC per fare dei veloci backup.

sudo ln -s /home /samba/home

In questo modo l'amministratore accedendo alla condivisione "rootdir" potrà vedere e manipolare tutte le home degli utenti

sudo mkdir /samba/system
sudo ln -s /etc /samba/system/etc
sudo ln -s /var/lib/openldap/openldap-data /samba/system/ldap

Ora l'amministratore trova nella cartella "system" anche i file di configurazione del server e il database utenti/gruppi di OpenLDAP. Molto comodo, e potrei anche aggiungere altri link senza inventarmi condivisioni "esotiche".

apps

In questa condivisione mettiamo i programmi condivisi nella rete. Solo "Administrator" può scrivere nella cartella, gli altri utenti possono solo leggere e eseguire i file contenuti. creiamo la cartella e settiamo i permessi:

sudo mkdir /samba/apps
sudo chmod 750 /samba/apps
sudo chgrp "Domain Users" /samba/apps
sudo chmod g+s /samba/apps

homes

Questa condivisione è creata automaticamente (o quasi) da Samba. Le home degli utenti saranno mappate con K: e sarà privata ad ogni utente.

Bene, dovremmo esserci. Ora siamo pronti a completare la configurazione di samba ed ad avviare (finalmente) il servizio.