Samba come membro di un domino

Rendere Samba membro di un dominio non ho ancora capito se e` un'arte arcana oppure e` assai facile. Qui di seguito ci sono i miei appunti, che sono assai poco collaudati, e scritti in un momento in cui mi serviva una cosa che funziona subito senza capire perche` funzioni. Questo e` un approccio pessimo, da utente di windows, non certo da sistemista serio. Perdonatemi, cerchero` di fare meglio.

Configurazione senza winbindd

Questa e` la configurazione quick&dirty. Il server Samba autentica i propri utenti sul dominio, e se serve crea i relativi username su Linux. Questo sistema consente di:

• Accedere agli share sul server samba membro del dominio usando username e password che sono contenuti nel domain controller per il dominio.
• Avere le password sincronizzate (in realta` la password e` una sola, e` sempre sul domain controller) quindi quando l'utente cambia la password, il server samba che e` membro del domino e` accessibile con la nuova password.
• Non dover aggiungere gli utenti in /etc/passwd a mano per gli utenti del dominio, samba li crea da solo la prima volta che questi accedono ad uno share sul server membro del dominio.

I limiti di questo sistema sono:

• Gli utenti del dominio possono accedere a Samba sul server membro, ma non alla shell o ad altri servizi che si autenticano su passwd o su PAM, perche` Samba crea si` gli utenti locali, ma li crea con la password disabilitata e non li gestisce in alcun modo. E in ogni caso samba crea gli utenti locali che sono copia di quelli del dominio solo quando un utente accede per la prima volta agli share smb, e non dal momento in cui un utente esiste nel dominio.
• Se esiste un utente locale con lo stesso username di uno del dominio (tipo che esiste su passwd un utente "pippo" e in seguito un altro utente "pippo" viene aggiunto al dominio) succede un casino: l'utente pippo del dominio viene confuso con l'utente pippo locale, quindi i due potranno vedere l'uno i files dell'altro, essendo in effetti per il file system di linux lo stesso utente. Ora, se i due sono davvero lo stesso utente, e` un vantaggio, ma se non lo sono, e` un casino.
• Se si cancella un utente dal domain controller, questo non potra` piu` accedere nemmeno al server samba membro del dominio, tuttavia i suoi files, la sua home, e la sua entry in passwd del server membro resteranno li` per sempre, a meno che non vengano cancellati a mano. Si noti il punto precedente: se cancello un utente pippo dal dominio e un anno dopo ne aggiungo un altro che ha lo stesso username, esso si trovera` i files del vecchio pippo sul server e potra` leggerli, se non sono stati cancellati.
• La gestione dei gruppi non e` allineata con il dominio, quindi eventuali gruppi con i relativi permessi di accesso sul file system vanno creati e gestiti interamente sulla macchina locale a livello di /etc/group. Il member server non ha idea di quali siano i gruppi sul domain controller e di quale utente appartenga a quale gruppo.

Per configurare Samba come member server occorre avere queste direttive in smb.conf (Se fate riferimento alla pagina ../ConfigDiBase, la sezione "Comandi relativi al dominio e al browsing" va tolta in toto e sostituita con la seguente)

#Comandi relativi al dominio e al browsing
  workgroup = KURGAN
  server string = %h server (Samba %v)
  encrypt passwords = true
  passdb backend = tdbsam
  time server = Yes
  enable privileges = yes
  security = domain
  password server = *

Vale la pena di notare che la direttiva "add user script" andra` eventualmente adattata alle proprie esigenze per quanto riguarda i parametri di creazione degli utenti locali, quali umask, permessi della home directory, appartenenza ad un gruppo, eccetera, che influenzano poi i limiti di accesso degli utenti ai dati sul file system.

Dopo aver configurato Samba, occorre rendere il server membro del dominio, con il comando:

net rpc join  -UAdministrator%password

Oppure, se occorre specificare il server che fa da primary domain controller:

net rpc join -S DOMPDC -UAdministrator%password

Oppure, per un dominio su windows 2000 / 2003 con Active Directory:

net ads join -UAdministrator%password

Configurazione con winbindd (Debian Squeeze, samba 3.6.5)

Questa configurazione consente, rispetto alla precedente, di integrare in Linux gli utenti del dominio Samba del quale il server membro fa parte. In pratica gli utenti del dominio non verranno creati come utenti locali (in passwd) ma verranno gestiti dentro ai files TDB di Samba, assegnando loro degli UID e GID "locali" che sono mappati su quelli del dominio. Lo stesso discorso vale per i gruppi. Gli utenti locali "veri", ovvero quelli in passwd, rimangono e restano utilizzabili.

Attenzione: se esiste un utente locale con lo stesso username di uno del dominio, il suo UID verra` mantenuto uguale (in pratica, se esiste l'utente locale "pippo" con UID 100, e nel dominio esiste un utente "pippo", che ovviamente non ha un UID locale su Unix sul member server, allora winbind mappera` "pippo" del dominio sullo stesso UID Unix (100) dell'utente "pippo" locale). Questo sistema permette di "mischiare" utenti locali realmente esistenti sulla macchina (in passwd) con utenti del dominio che esistono solo nel database di winbind (e nel PDC del dominio).

Prima di tutto occorre installare il pacchetto "winbind", poi si ferma Samba e si passa alla configurazione.

La configurazione di Samba e` la stessa dell'esempio senza winbind per quanto riguarda la parte della gestione del dominio. A questa si aggiunge un pezzo di configurazione specifico per winbind, che e` questo:

# Configurazione di winbindd (come membro del dominio)
idmap backend = tdb
idmap uid = 1000000-1999999
idmap gid = 1000000-1999999

idmap config SAMBA : backend  = nss
idmap config SAMBA : range = 1000-999999

winbind enum users = yes
winbind enum groups = yes
winbind nss info = template
winbind cache time = 60
template homedir = /home/%D/%U
template shell = /bin/bash

Dopo aver salvato la configurazione e verificata con testparm, occorre, come prima, fare un join del server membro (quello che stiamo creando) al dominio, cosa che si fa esattamente come e` indicato prima, nella configurazione senza winbind.

Fatto questo, per essere sicuri che tutto sia a posto, riavviamo (o avviamo) winbind, con un /etc/init.d/winbind restart

Ora possiamo verificare se winbind funziona, ovvero se legge dal PDC gli utenti. Dando il comando wbinfo -u dovremmo vedere una lista di utenti del PDC, elencati come "DOMINIO\utente". Dando il comando wbinfo -g vedremo una lista dei gruppi del PDC, elencato come "DOMINIO\gruppo". Vale la pena di notare che i gruppi che vediamo non sono tutti i gruppi Unix esistenti sul PDC (se il PDC e` Samba) ma solo quelli che sono stati mappati con "net groupmap". Questo e` normale, perche` usando winbind noi vediamo il PDC come se fosse Windows, e quindi le parti Unix ci sono invisibili. In effetti, anche gli utenti del PDC che non sono presenti in Samba ma solo in passwd non vengono elencati.

A questo punto occorre integrare winbind nel sistema Unix, ovvero dentro a NSS, in modo che le chiamate del sistema che ricercano informazioni su utenti e gruppi "vedano" anche gli utenti e i gruppi del PDC, altrimenti ci troviamo in una situazione dove Samba vede gli utenti del PDC, ma Unix no, e sappiamo che i permessi del file sytem possono essere applicati solo agli utenti Unix, non agli utenti Samba. In pratica, rendiamo "fintamente locali" gli utenti del PDC.

Per farlo occorre modificare il file /etc/nsswitch.conf come segue. Lasciando INALTERATO tutto quanto, aggiungere la parola "winbind" in fondo alle righe "passwd" e "group", in questo modo:

• passwd:         compat winbind
  group:          compat winbind
  
  # facoltativo, dipende se il dns non risolve bene:
  hosts:          files dns wins

Debian e` cosi` gentile da aver modificato la parte PAM per noi, il che significa di fatto che per default, dopo aver installato e configurato winbind, gli utenti del dominio possono accedere anche via SSH (o a qualsiasi altro servizio che usi PAM) autenticandosi con la password del dominio. Attenzione perche` per accedere come utente del dominio occorre indicare il dominio nello username, ovvero faremo login come "DOMINIO\utente" e non come "utente" e basta.

Un problema noto e` che con questa configurazione ci viene dato accesso come utente, ma NON ci vengono create le home per gli utenti del dominio.