KNOWLEDGE BASE

Knowledge Base
1Backup
Acronis
Antivirus
Email
Firewall
GFI Software
Mail
Monitoring
N-Able
Sicurezza
TSPlus
Diventa Autore per CoreTech | Scopri di più

Vai al Video

Ubuntu Server come AD domain controller

In questo corso vedremo l’utilizzo di Ubuntu Server in un caso specifico: il Domain Controller.
Vedremo per linee generali come integrare Ubuntu Server in una realtà di networking in un ambiente Windows-based; vedremo anche come Ubuntu Server possa sostituire un server Windows qualora, per esempio, si utilizzi esclusivamente da Primary Domain Controller (PDC).

La componente software principale è samba nella sua versione 4, giacché dalla versione 4.0 è stato integrato il supporto ad Active Directory


Samba 4

Qui stiamo parlando di Windows Active Directory, quindi di un servizio di Microsoft che che può essere considerato evoluzione dei domini NT 4; in pratica l'evoluzione dei domini di Windows ha portato alla centralizzazione di tutta una serie di servizi di rete (dell'infrastruttura di Windows) nel panorama delle reti Windows e l’immagine seguente ne riassume alcune.

In particolare, Identity Management e quindi la gestione centralizzata degli utenti dei nodi Windows, l’integrazione con servizio di mailing e con servizi Cloud, nonché, in generale, la centralizzazione di alcuni aspetti della gestione di sistema di nodi Windows in un ambiente prettamente windows-based quindi la gestione centralizzata di utenti di Policy di servizi di rete e quant'altro.

Ovviamente si tratta di un servizio che per sua natura normalmente viene implementato con delle istanze di Windows Server

Perché utilizzare Linux?

In questo corso scoprirete che esistono delle implementazioni parallele e alternative che in alcuni casi possono sostituire i servizi offerti da Windows Server e quindi la prima domanda che vi starete facendo è: “perché utilizzare Linux per implementare un servizio che per sua natura nasce in ambiente Windows”.

Sicuramente un primo motivo, quello più banale, è legato a una valutazione dei costi: per esempio se un’azienda ha una macchina Windows Server e una licenza del sistema operativo Windows Server utilizzati esclusivamente per fare da Active Directory Domain controller e magari sono a disposizione anche macchine Linux, è possibile consolidare e quindi spostare tale servizio su una macchina già esistente, riducendo, ad esempio, i costi di licenza legati all'utilizzo di una macchina Windows.

Altro caso può essere quello di un upgrade da un sistema basato su Windows NT4, che supporta Samba fino alla versione 3 e che quindi può fare da Primary Domain controller di un dominio NT4: se sorge la necessità di gestire ulteriori domini e sia già a disposizione un server Linux si può affidare a questo la gestione, invece di acquistare un sistema operativo Microsoft nuovo.

In generale si tratta di valutazioni che esulano dagli aspetti meramente tecnici e sconfinano in valutazioni in cui i costi e i costi di gestione di mantenimento entrano in gioco.

Non è comunque detto che integrare Linux significhi automaticamente abbandonare i costi di licenza, perché ci sono distribuzioni concesse con licenze commerciali, ovvero che malgrado il software sia gratuito, per qualche integrazione (come nel caso di RedHat) si paga il supporto commerciale e quindi si paga il servizio che ci consente di risolvere dei problemi chiedendo aiuto agli esperti.

Anche canonical offre supporto commerciale per Ubuntu Server, quindi, ad essere precisi va detto che quando si vuol fare integrazione su Linux bisogna tenere presente che ci sono quasi sempre due alternative:

  • quella commerciale, che prevede una contropartita in denaro al supporto tecnico;
  • quella completamente open, che ci lascia liberi di fare quello che vogliamo, però ci pone in balia di eventuali bug introdotti da aggiornamenti e della mancanza di upgrade per servizi.

Nel caso di Samba, chi non vuole assoggettarsi a una licenza commerciale Red Hat può pensare di utilizzare Samba attraverso Santos, che sarebbe la versione di Red Hat libera da tutte le integrazioni proprietarie; questo perché Santos e RedHat seguono uno sviluppo parallelo.

Nel caso di Ubuntu Server, in generale chiunque può scaricare l'immagine del sistema operativo, installarla e configurarla senza alcuna limitazione, quindi non ci sono i costi di licenza associati alla sola esecuzione del sistema operativo con Windows, ma il fatto stesso di aver installato il sistema richiede l'acquisto di una licenza.

Samba 4 e Ubuntu Server

Il cuore dell'implementazione su Linux di un Domain controller è il famoso Samba, il quale è un’implementazione open source di smb (implementazione open source di SMB/CIFS) del  protocollo di rete di Windows; pur non condividendo alcuna riga di codice con l’implementazione proprietaria di Microsoft, ne è perfettamente compatibile.

Il progetto è attivamente mantenuto e sviluppato anche perché non è utilizzato esclusivamente su Linux ma è disponibile per molti sistemi pletora di sistemi Unix-like come Linux, Solaris e macOS.

Forse la maggior parte degli utenti conosce Samba per il supporto alle cosiddette “directory condivise di Windows” in ambiente Mac, ottenuto grazie alla parte client di Samba che Apple ha integrato nel proprio sistema operativo. Analogamente, quando si condivide da MacOS una directory utilizzando un protocollo compatibile con client Windows utilizzando smb, in realtà si sta utilizzando la componente server di Samba.

A riprova del fatto che Samba è costantemente aggiornato, le ultime versioni supportano l'ultima versione del protocollo smb (la 311) e quindi sono perfettamente compatibili con Windows 10.

Per quanto riguarda Samba 4 e l'integrazione con Active Directory, c’è la necessità di appoggiarsi a un server kerberos perché Active Directory utilizza Kerberos per l'autenticazione mutua di client e Server.

Samba è più sicuro di Windows?

Questa è una domanda che tutti si pongono la prima volta che pensano di sostituire una macchina Windows con una Linux e in generale un servizio basato su Windows con una basato su Linux.

La risposta è un po’ articolata e non univoca, perché non è detto che un’implementazione basata su Linux sia automaticamente più sicura di quella basata su un prodotto commerciale; citiamo ad esempio:

  • Badlock (del maggio 2016) che di fatto riguardava un errore concettuale nel protocollo smb1 tale da consentire un attacco Man in the Middle, quindi permetteva di mettersi a metà tra client server intercettare la comunicazione; questo è uno dei motivi per cui smb1 è stato completamente deprecato;
  • EternalRed (aprile 2017) cioè una vulnerabilità delle implementazioni Microsoft smb nota come eternalblue (il nome in codice assegnato a questa falla dalla NSA) che colpisce esclusivamente i sistemi operativi di casa Microsoft; gli attacchi informatici riescono a sfruttare un problema di sicurezza su Microsoft Server Message Block 1.0, ossia il protocollo di condivisione per i file di rete.

Eternalblue è stata sfruttata dagli attacchi per creare dei ramsonware diffusi tramite Samba: ricordiamo l'attacco Wanna Cry, che sfruttando la vulnerabilità consentiva l'esecuzione di codice remoto e quindi a un attaccante di eseguire codice senza alcun privilegio.

Esiste una vulnerabilità analoga per Samba, che consentiva anch’essa l'esecuzione di codice remoto e in quel caso è stata sfruttata per quasi un mese da un altro attacco virale, noto con il nome di Samba Cry, che però non installava un ramsonware su macchine Linux ma installava un Miner che utilizzava quindi risorse di calcolo del Server per minare.

Quindi, quando si parla di sicurezza informatica non si può mai dire se un prodotto è più sicuro di un altro, ma bisogna valutare i tempi di risposta degli sviluppatori alla comparsa delle vulnerabilità.

Qualcuno vede nei progetti open source una maggiore sicurezza perché il codice è liberamente disponibile, quindi in molti lo possono vedere e analizzare e c’è più possibilità che qualcuno si accorga se c'è un problema e che la community possa intervenire.

Però non è scontato, perché anche su progetti Open Source e ci sono dei bug perché sono lì da da anni e poi soltanto all'ultimo si scopre che c'è una vulnerabilità.

I limiti di Samba

Samba 4 presenta alcune limitazioni: la prima è che non è ancora presente il supporto al Cloud di Azur, quindi quando parliamo di Active Directory intendiamo come è su Windows Server 2008.

Quello è un servizio che al momento non può essere implementato con Samba 4, almeno non si può fare un Primary Domain Controller con Samba 4. Però è possibile, ad esempio, creare un nodo ridondato e quindi creare un secondo nodo con samba4 che fa il John che si unisce a un dominio gestito da una macchina Windows.

Un’altra limitazione riguarda la configurazione del servizio: per quanto riguarda il back-end, il database sul quale vengono memorizzati lo schema e i profili utente, non è possibile utilizzare Open LDAP come invece accadeva per Samba 3; questo significa che in caso di migrazione da un server Samba 3 che faceva da Primary Domain controller NT4 a un Server Samba 4 (che invece implementa Active Directory) sarà necessario migrare prima il database degli utenti da Open LDAP all'implementazione LDAP integrata di Samba 4.

Non c’è alcun problema, invece, per chi comincia da zero a fare un nuovo nodo, anzi in questo caso il compito è semplificato perchè è già tutto integrato.

Un discorso analogo si applica a Kerberos: inizialmente Samba 4 supportava solo l’implementazione del MIT, mentre adesso supporta anche Heimdal; non è possibile, al momento, integrare altre.

Samba 4: prerequisiti

Detto questo, però, per procedere la maggior parte della configurazione in realtà non si fa tanto su Samba, quanto sul nodo, nel senso che la macchina deve possedere tutta una serie di prerequisiti, prima di poter effettivamente configurare Samba; la maggior parte di questi riguarda la configurazione di rete, dato che è necessario che la macchina sia raggiungibile dall'esterno è l’IP pubblico sia statico.

Riportiamo qui il caso di Ubuntu Server perché dalla versione 18.04 la configurazione della rete si esegue attraverso Netplan. Fondamentalmente la configurazione di rete adesso si esegue editando un file YAML; per default Ubuntu 18.04 utilizza cloud-init perché spesso non si utilizza su macchina fisica ma va su un'istanza virtuale e quindi il file da configurare è in realtà quello di cloud-init, che si trova al percorso:

/etc/cloud/cloud.cfg.d/50-curtin-networking.cfg

Come vedete qui di seguito, la sintassi è molto semplice, perché basta indicare che si vuole utilizzare networkd e che l'interfaccia di rete (in questo caso ens33) non utilizza il DHCP ma ha un indirizzo IP statico:

network:

 version: 2

 renderer: networkd

 ethernets:

   ens33:

     dhcp4: no

     dhcp6: no

     addresses: [192.168.1.2/24]

     gateway4: 192.168.1.1

     nameservers:

       Addresses: [192.168.1.2]

Va ricordato che per utilizzare Samba 4 sul Domain Controller dobbiamo disattivare il ring del DNS, quindi come vedete qui sopra, come indirizzo del nameserver e come indirizzo del DNS abbiamo messo lo stesso del nodo, perché utilizzeremo le definizioni statiche dei nomi che adesso vedremo, per risolvere il nome di dominio del controller. Quindi la cosa importante è non lasciare qui un indirizzo di un server pubblico, ma mettere lo stesso indirizzo del nodo.

A questo punto bisogna configurare l’host name della macchina (questo vale praticamente per tutte le distribuzioni Linux) e allo scopo in:

/etc/hostname

mettiamo il nome host della macchina, che può essere ad esempio dc1.

C'è un'altra particolarità che dipende dal file system che stiamo utilizzando sul nostro server: per default Ubuntu 18.04 utilizza EXT4 ma alcune distribuzioni come Fedora Server e Santos utilizzano XFS, quindi per XFS non c'è nulla di aggiuntivo da fare, ma per tutte quelle distribuzioni che utilizzano EXT4 è necessario modificare la tabella del file system aggiungendo queste opzioni, in particolare l'opzione ACL, che attiva il supporto alle ACL a livello di file system.

Infatti in Ubuntu 18.04 il supporto alle ACL nel files ystem:

  • in EXT4 è disattivato per default;
  • in XFS è attivo per default.

La tabella del file system si trova in:

/etc/fstab

e va modificata aggiungendo le parti in grassetto nella sezione seguente:

UUID=xyzxyzxy-xyzx-xyzx-xyzx-xyzxyzxyzxyzxy /ext4 user_xattr,acl,barrier=1,errors=remount-ro

Senza questa opzione, Samba non riesce a gestire le ACL.

Ovviamente per tutti i prerequisiti indicati si possono modificare i file di configurazione, quindi si deve riavviare il nodo e a quel punto procedere con la configurazione di Samba

La risoluzione del nome di dominio deve avvenire in modo statico senza utilizzare un dominio di un server DNS, ma utilizzando direttamente il file /etc/hosts; in questo caso metteremo le due entry:

127.0.0.1     dc1.miodominio.com    dc1

127.0.0.1     miodominio.com     miodominio

che risolvono su localhost, perché Samba utilizzerà utilizzerà il file hosts localmente per risolvere i nomi di dominio.

Tutti gli altri nodi sulla rete, invece, faranno capo a un server DNS che farà puntare miodominio.com all’IP pubblico della macchina; ecco perché abbiamo rimosso indirizzo IP di un server DNS dalla configurazione di rete, per far sì che il Domain Controller possa risolvere localmente mio dominio.com.

Configurazione di Samba

Soddisfatti i prerequisiti si può passare a configurare Samba, compito che viene semplificato da un tool che permette di farlo in modo interattivo: il tool in questione si chiama samba-tool e il suo utilizzo, pur passando dalla shell, è molto semplice.

Configurazione interattiva

Per procedere con la configurazione attraverso samba-tool è necessario riavviare il nodo dopo aver effettuato le configurazioni precedenti.

Samba su Ubuntu include una configurazione predefinita accessibile dal percorso:

/etc/samba/smb.conf

quindi facciamo prima il backup di questo file di configurazione utilizzando il comando move e rinominando il file in samba.conf.old:

 # mv /etc/samba/smb.conf

     /etc/samba/smb.conf.old

e poi, a quel punto, procediamo con il comando samba-tool.

Il comando samba-tool seguito da domain ci consente di configurare Samba per l'utilizzo di Active Directory; esiste una serie di comandi successivi che dipendono dal tipo di nodo che vogliamo configurare. Nel nostro caso vogliamo configurare un Primary Domain controller per Active Directory e quindi dovremmo usare:

# samba-tool domain provision

che crea la struttura del database di Active Directory su questo nodo, la configurazione di kerberos e ci consente di abilitare, come in questo caso, le estensioni NDS che permettono di scrivere sul database dell'Active Directory anche tutti anche tutti i metadati degli utenti Unix.

A questo punto va chiarito un concetto: in realtà non è strettamente necessario fare il backup del file di Samba, nel senso che si potrebbe semplicemente cancellarlo; tale operazione va fatta perché se samba-tool trova un file di configurazione esistente prova a utilizzare quello e quindi il comando di provision fallisce perché la configurazione predefinita di Samba non è quella di Active Directory Domain Controller, ma è quella di semplice nodo della rete che condivide directory e stampanti, per cui se provate a dare questo comando senza quantomeno eliminare smb.conf, il comando fallisce.

In genere e buona norma, piuttosto che cancellare i file di configurazione predefinito in Samba, farne un backup, perché non si sa mai che potrebbe tornare utile.

Il comando di creazione appena visto può essere impartito anche con un flag che è interessante spiegare:

 # samba-tool domain provision

  --use-rfc2307 –interactive

Il flag   --use-rfc2307 –interactive abilita le estensioni NIS specifiche di Samba, che permettono di mappare tutti i metadati degli utenti Unix di questo server nella directory di Active Directory, il che permette di memorizzare gli User ID e i Group ID degli utenti Unix nella Active Directory. Ciò può essere molto utile se vogliamo integrare nella Directory anche dei client Linux, perché ci consente di centralizzare anche quella parte di gestione degli utenti, mettendola tutta “sotto lo stesso ombrello”. È anche possibile attivare le estensioni NIS in un secondo momento, dopo aver configurato il nodo, però in tal caso è necessario agire manualmente modificando lo schema del database; quindi è preferibile abilitarle fin da subito.

Ad ogni modo, impartendo il solito comando # samba-tool domain provision, il tool samba-tool comincia a fare all'utente tutta una serie di domande: questa è la modalità interattiva. Come appare nello screenshot riportato qui di seguito, chiede quale sarà il nome di dominio, il nome del Realm (di solito coincide con nome di dominio).  

Ottenute le risposte alle varie domande, quindi una volta che abbiamo definito il ruolo del server (Domain Controller, nodo stand-alone o membro di dominio esistente) il tool procede con la creazione della configurazione di Samba, ovverò creerà:

  • un nuovo file Samba smb.conf con il nuovo ruolo del nodo e del server Samba;
  • la configurazione per il server kerberos installata insieme a Samba.

Non dovete preoccuparvi di installarlo separatamente perché installando Samba, questo si porta dietro come dipendenze la sua implementazione di LDAP di kerberos, tuttavia per evitare di entrare in conflitto con configurazioni già esistenti su kerberos, la configurazione di quest’ultimo non viene sovrascritta, ma piuttosto viene creato un file che possiamo rivedere ed eventualmente integrare con il nostro.

Tale file viene creato da samba-tool nel percorso:

/varlib /samba /primeknit

e si chiama krb5.conf.

Nel caso della configurazione di un nodo vergine non c'è nulla di interessante nella configurazione predefinita di kerberos, quindi possiamo semplicemente copiare il file di configurazione di Samba;

piuttosto che copiarlo, possiamo creare un link simbolico impartendo il comando di link:

# ln -sf /var/lib/samba/private/krb5.conf /etc/krb5.conf

il quale fa puntare il file /etc/krb5.conf al file di configurazione generato da samba-tool (/var/lib/samba/private/krb5.conf). Questo va bene quando serva utilizzare kerberos esclusivamente con Samba 4.

Linkare il file permette, nel caso in futuro si dovesse riconfigurare il nodo, di ricollegare automaticamente il file di configurazione in /var/lib/samba/private/krb5.conf.

Notate che nel momento in cui l’Active Directory Domain Controller è attivo, è possibile utilizzare gli strumenti di amministrazione di Windows su qualsiasi client Windows con sufficienti privilegi per gestire la directory, quindi alla stregua di quanto si fa con un Domain controller Windows è possibile utilizzare la Windows Management console per collegarsi a un dominio e per esempio configurare policy, utenti e gruppi da remoto.

Ciò è possibile anche se il Domain controller è un nodo Samba 4, quindi possiamo “mettere in piedi” il dominio utilizzando samba-tool e poi procedere con il resto della configurazione utilizzando dei tool Windows.

Configurazione tramite Webmin

Un'alternativa degna di nota è Webmin, ossia un tool che permette di configurare e di automatizzare una serie di processi di configurazione su una macchina Linux utilizzando un'interfaccia grafica fruibile dal web tramite browser che punta al server.

Da Webmin è possibile effettuare una serie di operazioni di amministrazione tra cui la configurazione di Samba. Di seguito vedete lo screenshot del modulo della pagina di amministrazione di Samba dopo che il nodo è stato configurato con samba-tool.

 

Come vedete, due condivisioni che sono state create da samba-tool sono netlogon e sysvol; su Windows le vedreste come $netlogon e $sysvol, che sono le condivisioni che permettono di condividere, in questo caso con netlogon, i profili degli utenti.

I pulsanti in basso sotto Global Configuration permettono di controllare ogni aspetto della configurazione del server Samba e ci permettono anche di creare delle directory condivise, di editare gli oggetti contenuti nelle directory; quelli sotto Samba Users permettono anche di gestire gli utenti, perché essendo questo il Primary Active Directory Domain controller, il profilo degli utenti risiede qui, quindi è possibile gestirlo direttamente da questa comoda interfaccia web, oltre che da una Windows Management console che gira su un nodo della rete.

Quindi cliccando su Samba Users, sul browser si apre una pagina (illustrata qui di seguito) che consente addirittura di migrare e di copiare i profili degli utenti Linux direttamente nel database LDAP dei profili degli utenti della directory.

In questa operazione, che si può fare comodamente dall'interfaccia grafica, ci sono opzioni che permettono di restringere un po' il campo d’azione: ad esempio quella predefinita che evita che gli utenti speciali (in ambiente Linux e Unix ci sono utenti che vengono in realtà utilizzati per dei servizi) vengano esportati nella directory di Active Directory, quindi soltanto gli utenti della macchina, ossia quelli che hanno disposizione login, possono essere emigrati sulla directory LDAP.

A parte la gestione degli utenti e dei gruppi, è possibile gestire anche se in modo semplificato alcune Policy, anche se per le Policy specifiche di Windows, per le Group Policy, è decisamente più comodo utilizzare direttamente un nodo Windows connesso al server di Active Directory; questo servirà anche a mostrare come dopo l'esecuzione di samba-tool il server di Active Directory sia immediatamente attivo e funzionante, per cui si può già passare alla configurazione del client della connessione a dominio.

Tuttavia il processo che abbiamo seguito finora richiede la creazione di un nuovo nodo Linux, quindi nel caso di Ubuntu Server, l'installazione di Ubuntu server sul nuovo nodo; come sapete l'installazione predefinita non installa praticamente alcun servizio al di fuori di SSH e il firewall e quindi bisogna installare Samba ed eventualmente installare Webmin, configurarlo e poi procedere con la configurazione sul client.

In alcuni casi questo può essere proibitivo, perché magari non vogliamo scontrarci con tutte le dinamiche legate alla configurazione all'installazione di un sistema Linux-based, oppure abbiamo la necessità di fare il deploy di questa soluzione in diversi siti e su diversi server; in questi casi può essere comodo partire da un immagine preconfigurata per un ambiente di virtualizzazione o per un container.

In questo è d’aiuto un progetto open che si chiama Turnkey Linux (accessibile sul web all’indirizzo https://www.turnkeylinux.org/domain-controller) che distribuisce delle immagini pre-configurate in OVA, ISO, VMDK, Xen, Docker.

Il suo repository offre quindi immagini preconfigurate di sistemi Linux-based per particolari ruoli, compresa una per l'utilizzo di Samba 4 (come riporta la figura seguente) come Active Directory Domain controller.

Quindi tutti quei requisiti descritti in precedenza sono già messi in atto nella stessa immagine, con il sistema opportunamente configurato, l'interfaccia di rete preconfigurata su un IP statico e così via.

E in più, la prima volta che l'immagine si avvia parte uno script che propone in modo interattivo la configurazione dei parametri di Samba e dei parametri di rete.

Inoltre c’è una serie di moduli che vengono preinstallati tra i quali per esempio Webmin.

Le immagini sono disponibili in vari formati, quindi c'è:

  • il formato OVA, che ci permette di caricarle su un qualsiasi hypervisor perché è un formato open ormai supportato da tutti che consente di importare nei nostri hypervisor un’immagine virtuale;
  • il formato ISO, che permette di avviare l'immagine come se fosse un’immagine avviabile su CD;
  • il formato VMDK;
  • il formato Xen;
  • il formato per container docker.

Magari Webmin non è una soluzione utile per un server da mettere in produzione, dove casomai sarebbe meglio procedere con un’installazione da zero per avere il massimo controllo sulla configurazione del sistema, però è sicuramente un metodo molto interessante per poter fare delle prove al fine di studiare meglio la soluzione prima di passare in produzione. Quindi, piuttosto che installare tutto da zero la prima volta, si parte con un'immagine Turnkey, la Configura e vede se effettivamente consente di lavorare in base alle proprie esigenze.

Turnkey è utile non soltanto nel caso di Samba 4, ma in generale per altri servizi.