Differences

This shows you the differences between two versions of the page.

--- samba4:configad [2025/09/20 12:51] – created - external edit 127.0.0.1
+++ samba4:configad [2025/09/21 16:58] (current) – kurgan
@@ Line 3: / Line 3: @@
 Configurazione di Samba 4 su Debian 13
-Il punto di partenza e` l'howto dal sito di Samba, qui: https://wiki.samba.org/index.php/Setting_up_Samba_as_an_Active_Directory_Domain_Controller
+Il punto di partenza e` l'howto dal sito di Samba, qui: [[https://wiki.samba.org/index.php/Setting_up_Samba_as_an_Active_Directory_Domain_Controller]]
 **Attenzione: usare il DC anche come file server non è supportato. Funziona ma non è una buona idea. Al giorno d'oggi non è certo un problema fare due virtuali una per il DC e una per il file server.**
 ===== Prerequisiti =====
   * Samba richiede l'uso delle ACL Posix e degli attributi estesi sul file system. Occorre quindi usare ext4 (che li supporta di default) oppure abilitarli sul file system che volete usare.
-  * Non ci deve essere un DNS server sulla macchina che fa da AD, perche` lo fa Samba e non si puo` fare diversamente. (Tecnicamente potremmo usare BIND assieme a Samba ma trovo assai  più comodo usare il DNS interno di Samba) Per impostare correttamente il DNS in modo da non avere problemi, se necessario, verificare prima come gestire dnsmasq con samba per non farli cozzare. E` importante avere il DNS di Samba funzionante senza che cozzi con altri programmi per l'uso della porta 53 perche` altrimenti poi anche il provisioning sembra funzionare ma fallisce, e i test non passeranno, a partire dal primo. Fare riferimento anche a: [[..[[/IntegrazioneSambaDnsmasq]]]]
+  * Non ci deve essere un DNS server sulla macchina che fa da AD, perche` lo fa Samba e non si puo` fare diversamente. (Tecnicamente potremmo usare BIND assieme a Samba ma trovo assai  più comodo usare il DNS interno di Samba) Per impostare correttamente il DNS in modo da non avere problemi, se necessario, verificare prima come gestire dnsmasq con samba per non farli cozzare. E` importante avere il DNS di Samba funzionante senza che cozzi con altri programmi per l'uso della porta 53 perche` altrimenti poi anche il provisioning sembra funzionare ma fallisce, e i test non passeranno, a partire dal primo. Fare riferimento anche a: [[IntegrazioneSambaDnsmasq]]
-  * I client che saranno joinati al dominio dovranno usare come DNS server quello contenuto in Samba (oppure un DNS che sappia appoggiarsi a quello contenuto in Samba). Fare riferimento anche a: [[..[[/IntegrazioneSambaDnsmasq]]]]
+  * I client che saranno joinati al dominio dovranno usare come DNS server quello contenuto in Samba (oppure un DNS che sappia appoggiarsi a quello contenuto in Samba). Fare riferimento anche a: [[IntegrazioneSambaDnsmasq]]
   * Usare NTP (o Chrony in particolare in Debian 12) perche` la sincronizzazione dell'ora e` importante (anche nei member server. Sui client windows si arrangia a chiedere NTP al DC)
 ===== Installazione di Samba =====
-  * Installare normalmente i pacchetti di Samba "ufficiali" (in Debian 13 abbiamo la 4.22.3) più alcuni pacchetti di contorno:
+  * Installare normalmente i pacchetti di Samba "ufficiali" (in Debian 13 abbiamo la 4.22.3) più alcuni pacchetti di contorno:<code ->
-<code>
 apt install  acl attr samba samba-dsdb-modules samba-vfs-modules winbind libpam-winbind libnss-winbind libpam-krb5 krb5-config krb5-user dnsutils smbclient
 </code>
   * ignorare le domande relative alla config di Kerberos, che tanto dovremo rifarla dopo.
   * **ATTENZIONE:** installando libpam-winbind si autorizzano di default gli utenti di Samba ad accedere in ssh. Questo potrebbe essere molto pericoloso. Se non volete che succeda, usate il comando ''pam-auth-update'' (dopo aver installato i pacchetti) e disattivate l'opzione "Winbind NT/Active Directory Authentication"
 ===== Scegliere un nome DNS per il dominio Samba =====
@@ Line 32: / Line 26: @@
 Prima di partire, occorre ricordare che il dominio AD funziona con il DNS, ergo e` esigente e invadente al riguardo. Occorre controllare che l'hostname fully qualified (con anche il dominio) del server dove stiamo installando Samba sia congruente con quello che sara` il nome del dominio AD (per esempio, "dc1.dominio.internal"), e sia risolvibile correttamente sia dal server stesso che dai client che poi aggiungeremo, sia a dritto che a rovescio.
-Qui le best practice sono tante e non tutte concordano, ma la cosa importante e` che il nome del dominio AD **NON SI CAMBIA MAI PIU`** dopo averlo impostato. La best practice al 2025 (vedi https://wiki.samba.org/index.php/Active_Directory_Naming_FAQ) dice di usare un subdomain di un nome di dominio ufficiale e registrato (tipo ad esempio dominiosamba.example.com) ma io preferisco normalmente usare un dominio non registrato pubblicamente, tipo "nomeazienda.internal". (Vedi: https://en.wikipedia.org/wiki/.internal)  Badate bene di NON usare ".local" che e` stato "rubato" da Avahi (Bonjour) e quindi ci sarebbero problemi nella risoluzione dei nomi. Se si prevede di avere una "foresta" (come la chiama MS) di domini correlati, allora occorre considerare bene la scelta dei nomi, ma questo va oltre lo scopo attuale del sottoscritto, che e` di avere un dominio AD e basta. Qui si parla di una installazione in una piccola azienda o in un setup casalingo.
+Qui le best practice sono tante e non tutte concordano, ma la cosa importante e` che il nome del dominio AD **NON SI CAMBIA MAI PIU`** dopo averlo impostato. La best practice al 2025 (vedi [[https://wiki.samba.org/index.php/Active_Directory_Naming_FAQ]]) dice di usare un subdomain di un nome di dominio ufficiale e registrato (tipo ad esempio dominiosamba.example.com) ma io preferisco normalmente usare un dominio non registrato pubblicamente, tipo "nomeazienda.internal". (Vedi: [[https://en.wikipedia.org/wiki/.internal]])  Badate bene di NON usare ".local" che e` stato "rubato" da Avahi (Bonjour) e quindi ci sarebbero problemi nella risoluzione dei nomi. Se si prevede di avere una "foresta" (come la chiama MS) di domini correlati, allora occorre considerare bene la scelta dei nomi, ma questo va oltre lo scopo attuale del sottoscritto, che e` di avere un dominio AD e basta. Qui si parla di una installazione in una piccola azienda o in un setup casalingo.
-Se usiamo un dominio "interno" tipo appunto "nomeazienda.internal" potremo usare direttamente questo come dominio per l' Active Directory. Se usiamo un dominio pubblico esistente (per dire, nomeazienda.it) allora DOBBIAMO usare un sottodominio, tipo "AD.nomeazienda.it" o "samba.nomeazienda.it", e NON usare direttamente "nomezienda.it" come dominio per Active Directory. Chiaramente nessuno ci vieta di usare un sottodominio di un dominio interno, tipo "AD.nomeazienda.internal". Alla fine è tutta una questione legata al fato che il DNS autoritativo per questo dominio che useremo per AD deve essere il nostro domain controller e nessun altro. Per questo motivo se usiamo un dominio interno possiamo serenamente usare il nostro DC come DNS autoritativo per l'interno dominio "nomeazienda.internal" mentre se usiamo un dominio pubblico ufficiale a noi registrato il DNS autoritativo non può essere il nostro interno ma deve essere quello pubblico su internet, tuttavia non c'e` nessun problema a usare il nostro DC come DNS autoritativo per un sottominio (AD.nomeazienda.it ad esempio) che chiaramente deve non esistere sul DNS esterno autoritativo per "nomeazienda.it". Chiaro? Per niente? Andate a rileggere https://wiki.samba.org/index.php/Active_Directory_Naming_FAQ
+Se usiamo un dominio "interno" tipo appunto "nomeazienda.internal" potremo usare direttamente questo come dominio per l' Active Directory. Se usiamo un dominio pubblico esistente (per dire, nomeazienda.it) allora DOBBIAMO usare un sottodominio, tipo "AD.nomeazienda.it" o "samba.nomeazienda.it", e NON usare direttamente "nomezienda.it" come dominio per Active Directory. Chiaramente nessuno ci vieta di usare un sottodominio di un dominio interno, tipo "AD.nomeazienda.internal". Alla fine è tutta una questione legata al fato che il DNS autoritativo per questo dominio che useremo per AD deve essere il nostro domain controller e nessun altro. Per questo motivo se usiamo un dominio interno possiamo serenamente usare il nostro DC come DNS autoritativo per l'interno dominio "nomeazienda.internal" mentre se usiamo un dominio pubblico ufficiale a noi registrato il DNS autoritativo non può essere il nostro interno ma deve essere quello pubblico su internet, tuttavia non c'e` nessun problema a usare il nostro DC come DNS autoritativo per un sottominio (AD.nomeazienda.it ad esempio) che chiaramente deve non esistere sul DNS esterno autoritativo per "nomeazienda.it". Chiaro? Per niente? Andate a rileggere [[https://wiki.samba.org/index.php/Active_Directory_Naming_FAQ]]
 In questo esempio useremo **ad.sambalab.internal** come dominio AD
@@ Line 42: / Line 36: @@
 Essendo una nuova installazione, partiamo da zero con il provisioning di un dominio "vergine". Prima di farlo, mi assicuro di non avere configurazioni pregresse o di default che non mi siano gradite.
-  * Fermare samba e winbind (notare che samba-ad-dc non è avviato in quanto non è configurato ancora)
+  * Fermare samba e winbind (notare che samba-ad-dc non è avviato in quanto non è configurato ancora)<code>
-<code>
 systemctl stop smbd nmbd winbind
 </code>
   * Assicurarsi che sia fermo. Se ci sono processi smbd, nmbd, o winbindd, killarli senza pietà.
   * Cancellare o rinominare il file ''/etc/samba/smb.conf''
-  * Se ci sono, cancellare tutti i files tdb e ldb. Un metodo per sapere dove cercarli è questo:''smbd -b | egrep "LOCKDIR|STATEDIR|CACHEDIR|PRIVATE_DIR"''. Un metodo (pericoloso?) per rimuoverli tutti in blocco è questo:
+  * Se ci sono, cancellare tutti i files tdb e ldb. Un metodo per sapere dove cercarli è questo:''smbd -b | egrep "LOCKDIR|STATEDIR|CACHEDIR|PRIVATE_DIR"''. Un metodo (pericoloso?) per rimuoverli tutti in blocco è questo:<code>
-<code>
 smbd -b | egrep "LOCKDIR|STATEDIR|CACHEDIR|PRIVATE_DIR" | awk -F\: {'system("find "$2" -type f -name \"*.[t|l]db\" -delete")'}
 </code>
   * Cancellare o rinominare, se c'è, il file ''/etc/krb5.conf''
-  * Verificare in ''/etc/hosts'' che ci sia una riga che contiene il nome del nostro server che punta al suo IP e non a localhost, tipo:
+  * Verificare in ''/etc/hosts'' che ci sia una riga che contiene il nome del nostro server che punta al suo IP e non a localhost, tipo:<code>
-<code>
 .168.1.100 dc1.ad.sambalab.internal dc1
 </code>
   * Verificare che il comando ''hostname -f'' riporti "dc1.ad.sambalab.internal" ovvero il nome host con il dominio che abbiamo deciso di usare corretto.
-  * Effettuare il provisioning del dominio con il comando samba-tool (Se il server ha piu` di una NIC, scegliere quella giusta per Samba a mezzo delle due option relative alle interfacce. Se ne ha una sola non e` necessario)
+  * Effettuare il provisioning del dominio con il comando samba-tool (Se il server ha piu` di una NIC, scegliere quella giusta per Samba a mezzo delle due option relative alle interfacce. Se ne ha una sola non e` necessario)<code ->
-<code>
 samba-tool domain provision --use-rfc2307 --interactive
 </code>
-  * Rispondere alle domande (e ricordarsi la password impostata per administrator). Attenzione alla policy di default per la password: almeno 8 caratteri con almeno un simbolo o un numero e una maiuscola e una minuscola se ricordo bene. Qui ho un esempio dove tutte le risposte sono default (vuote) tranne la password.
+  * Rispondere alle domande (e ricordarsi la password impostata per administrator). Attenzione alla policy di default per la password: almeno 8 caratteri con almeno un simbolo o un numero e una maiuscola e una minuscola se ricordo bene. Qui ho un esempio dove tutte le risposte sono default (vuote) tranne la password.<code ->
-<code>
 Realm [AD.SAMBALAB.INTERNAL]:
 Domain [AD]:
@@ Line 74: / Line 63: @@
 Il tool di provisioning avra` creato una serie di cose:
   * un file /var/lib/samba/private/krb5.conf che useremo dopo
   * un file /etc/samba/smb.conf (guardateci dentro)
@@ Line 80: / Line 70: @@
   * Tre utenti in Samba: administrator, krbtgt e nobody.
   * Un servizio DNS locale (integrato in Samba) che risolve i nomi necessari per il funzionamento del dominio AD. Vedremo poi come usarlo.
 ===== Configurazione di Kerberos =====
@@ Line 86: / Line 75: @@
 Samba usa kerberos internamente per autenticare utenti, macchine, ecc. (Sono ignorante per cui non so esattamente come, quando, e perché. Tuttavia, è opportuno che kerberos funzioni localmente, quindi provvediamo a copiare (non symlinkare, ma copiare!) la configurazione autogenerata da Samba durante il provisioning dentro a /etc, come segue)
-<code>
+<code ->
 cp /var/lib/samba/private/krb5.conf /etc/krb5.conf
 </code>
@@ Line 96: / Line 85: @@
   * Installare il pacchetto "chrony" (che disinstalla, nel caso, sntp e systemd-timesyncd)
   * Creare la directory ''/var/lib/samba/ntp_signd'', la quale deve poter essere letta dal server Chrony, che gira con user e group "_chrony" (notare l'underscore all'inizio)
-  * Se questa directory esiste già, vuole dire che abbiamo già lanciato Samba almeno una volta. Non è un problema, basta mettere a posto i permessi.
+  * Se questa directory esiste già, vuole dire che abbiamo già lanciato Samba almeno una volta. Non è un problema, basta mettere a posto i permessi.<code ->
-<code>
 mkdir /var/lib/samba/ntp_signd
 chgrp _chrony /var/lib/samba/ntp_signd
 chmod 750 /var/lib/samba/ntp_signd
 </code>
-  * Modificarela config di chrony per leggere questo socket. Per farlo possiamo creare un nostro file di conf dentro {{{/etc/chrony/conf.d/}}}. Per esempio possiamo fare ''/etc/chrony/conf.d/samba.conf'' contenente queste righe:
+  * Modificare la config di chrony per leggere questo socket. Per farlo possiamo creare un nostro file di conf dentro ''/etc/chrony/conf.d/''. Per esempio possiamo fare ''/etc/chrony/conf.d/samba.conf'' contenente queste righe:<code ->
-<code>
 ntpsigndsocket  /var/lib/samba/ntp_signd
 allow all
@@ Line 110: / Line 97: @@
   * Verificare nel syslog che Chrony riporti questo messaggio: ''chronyd[xxxx]: MS-SNTP authentication enabled''
-  * Per verificare se un client joinato al dominio legge correttamente NTP, eseguire un CMD come amministratore e usare il comando
+  * Per verificare se un client joinato al dominio legge correttamente NTP, eseguire un CMD come amministratore e usare il comando<code ->
-<code>
 w32tm /resync
 </code>
 ===== Reimpostare il resolver DNS =====
@@ Line 123: / Line 108: @@
 Quindi, la cosa piu` facile da fare e` impostare sul nostro domain controller in ''/etc/resolv.conf'' il dns per essere localhost (127.0.0.1) oppure l'ip della nostra interfaccia alla quale abbiamo bindato Samba
-<code>
+<code ->
 search ad.sambalab.internal
 nameserver 127.0.0.1
 </code>
 Di default il DNS interno di Samba è autoritativo per il nostro dominio AD (in questo esempio **ad.sambalab.internal**) e passa ad un altro DNS, configurato in smb.conf, tutte le altre richieste.
 Quando configureremo i client potremo farli puntare al nostro DC Samba oppure farli puntare ad un altro DNS purché questo altro DNS inoltri le richieste per il nostro dominio AD (**ad.sambalab.internal**) al dns che gira su Samba sul DC.
 Notare che di default il DNS in Samba non contiene una zona "reverse" ma solo una zona "forward" per i nomi interni al dominio: funziona bene lo stesso, ma se volete potete anche configurare una zona reverse e popolarla con gli host statici (se ho capito bene non viene auto-popolata).
 ===== Avviare Samba =====
-Dal momento che abbiamo modificato la config in resolv.conf, ora il nostro server DC non risolve più i nomi, quindi per poter lavorare senza problemi possiamo avviare Samba (e se vogliamo verificare che la risoluzione dns funzioni di nuovo)
+Dal momento che abbiamo modificato la config in resolv.conf, ora il nostro server DC non risolve più i nomi, quindi per poter lavorare senza problemi possiamo avviare Samba (e se vogliamo verificare che la risoluzione dns funzioni di nuovo) Notare che vengono avviati automaticamente anche smbd e winbindd in questa configurazione.
-Notare che vengono avviati automaticamente anche smbd e winbindd in questa configurazione.
+<code ->
-<code>
 systemctl start samba-ad-dc
 host google.it
 </code>
 ===== Configurare nsswitch  (non più necessario in Debian 13) =====
 Per poter vedere correttamente gli utenti di Samba dal sistema (sulla macchina stessa del DC AD),e` sufficiente verificare che winbindd stia girando (ps ax) e poi modificare il file ''/etc/nsswitch.conf'' come segue: (potrebbe essere che troviate "compat" al posto di "files", in quel caso mettete "compat winbind")
-<code>
+<code ->
 passwd:         files winbind
 group:          files winbind
 </code>
 (occorre che le librerie libnss-winbind libpam-winbind siano installate)
 ** Questa impostazione non è più necessaria, è già configurato in modo corretto**
 ===== Test =====
@@ Line 163: / Line 145: @@
 Prima di tutto il test con smbclient, che si fa cosi`:
-<code>
+<code ->
 smbclient -L localhost -N
 </code>
@@ Line 169: / Line 152: @@
 L'output e` tipo questo:
-<code>
+<code ->
 Anonymous login successful
@@ Line 182: / Line 165: @@
 Poi l'accesso a uno share:
-<code>
+<code ->
 smbclient //localhost/netlogon -UAdministrator -c 'ls'
 </code>
@@ Line 188: / Line 171: @@
 L'output e` tipo questo:
-<code>
+<code ->
 Enter Administrator's password: Otto88@88
 Domain=[SAMDOM] OS=[Unix] Server=[Samba 4.x.y]
@@ Line 198: / Line 181: @@
 Passo successivo il test del DNS. Queste query devono dare tutte risposte sensate e mai un not found.
-<code>
+<code ->
 host -t SRV _ldap._tcp.ad.sambalab.internal.
 host -t SRV _kerberos._udp.ad.sambalab.internal.
@@ Line 207: / Line 191: @@
 La procedura di test per Kerberos richiede due comandi, kinit e klist:
-<code>
+<code ->
 kinit administrator@AD.SAMBALAB.INTERNAL
 </code>
 Notare che il dominio deve essere in maiuscolo (e può essere omesso, dovrebbe risolverlo da solo)
-<code>
+<code ->
 klist
 </code>
 Viene mostrato un output tipo questo:
-<code>
+<code ->
 Ticket cache: FILE:/tmp/krb5cc_0
 Default principal: administrator@AD.SAMBALAB.INTERNAL
@@ Line 224: / Line 213: @@
 </code>
+===== Test dell'integrazione con il sistema =====
+  * Verificare se Winbind vede il domain controller:<code ->
-===== Test dell'integrazione con il sistema  =====
-  * Verificare se Winbind vede il domain controller:
-<code>
 wbinfo --ping-dc
 </code>
+  * Verificare se Winbind legge correttamente i dati da Samba (devi vedere i gruppi e gli utenti di Samba come output). Nelle versioni più recenti di Samba si possono trovare ulteriori gruppi oltre quelli elencati qui.<code ->
-  * Verificare se Winbind legge correttamente i dati da Samba (devi vedere i gruppi e gli utenti di Samba come output). Nelle versioni più recenti di Samba si possono trovare ulteriori gruppi oltre quelli elencati qui.
-<code>
 wbinfo -u
@@ Line 255: / Line 239: @@
 read-only domain controllers
 dnsupdateproxy
 </code>
-  * Verificare se NSS vede utenti e gruppi di Samba
+  * Verificare se NSS vede utenti e gruppi di Samba<code ->
-<code>
 id administrator
    uid=0(root) gid=0(root) groups=0(root)
@@ Line 294: / Line 276: @@
 default:other::---
 </code>