== Update da Samba3 NT a Samba 4 AD ==

Questa procedura e` lunga e complessa, e non solo, ma non si torna indietro a meno di non avere un backup dei client. Quando un client "vede" il dominio AD, poi non torna piu` al dominio NT.

Leggetevi BENE anche il wiki di Samba.org, qui: https://wiki.samba.org/index.php/Samba_Classic_Upgrade_(NT4-style_domain_to_AD)


=== Situazione di partenza ===

Questa procedura e` stata provata in virtuale (laboratorio creato apposta) come segue:
 * Server Samba 3.6.6 Debian 7
 * Client Windows 7 pro 64 joinato al dominio NT
 * nome dominio netbios: MBUTI
 * nome FQDN server: samba4.mbuti.locale
 * netbios name del server: samba4
 * dominio locale (nel dns): mbuti.locale
 * backend di autenticazione di samba3: dtbsam (niente LDAP)


=== Situazione di arrivo ===

All'arrivo mi aspetto di avere Samba 4.2 (da Sernet) installata sullo stesso server di partenza, con lo stesso nome di dominio, e di avere il client win7 ancora in dominio senza doverlo togliere e rimettere nel dominio.

Una eventuale configurazione con un cambio di server fisico non dovrebbe differire di molto da questa, se non perche` ci si trova con un eventuale cambio di hostname del domain controller (vedi il wiki di Samba.org).


=== Check preliminari ===

Facendo riferimento al Wiki di samba.org, occorre controllare alcune cose:
 * Che nessun RID/SID sia duplicato (usando pdbedit -L -v e net groupmap list e qualche script per fare il confronto dei vari SID)
 * Che non esista un gruppo con un nome uguale a un utente (nel caso occorre rinominare / cancellare il gruppo o l'utente)
 * Che non esistano gruppi, seppure diversi, che abbiano lo stesso "Display Name"
 * assicurarsi che tutti i client siano SPENTI prima di iniziare

Occorre anche che il server dove installiamo samba4 abbia i seguenti requisiti:

 * 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 (o almeno e` cosi` di default).
 * Usare NTP perche` la sincronizzazione dell'ora e` importante (anche nei client!)


=== Backup configurazioni di samba3 ===

Per fare la migrazione dobbiamo togliere samba3 e installare samba4, ma prima di farlo dobbiamo assicurarci di salvare tutto quanto ci servira` dopo.

 * Fermare samba
 * Esportare, per sicurezza, un elenco di utenti e gruppi, e gli ID del dominio:
  {{{
pdbedit -L -v > users.txt
net groupmap list > gruppi.txt
net getdomainsid > sid.txt
}}}
 * copiare da qualche parte tutta /etc/samba 
 * copiare da qualche parte tutta /var/lib/samba (i files tdb,ldb, ecc)
 * copiare da qualche parte tutta /run/samba


=== Eliminazione di Samba3 e installazione di Samba4 ===

Usiamo samba 4.2 presa da Sernet, perche` Samba4 in Debian e` troppo vecchia (4.1.x) ed e` piena di bug e limitazioni. Ovviamente se stiamo installando samba4 su una macchina diversa non c'e` nessun bisogno di cancellare samba3 dalla macchina di partenza, basta essere sicuri che non sia in esecuzione.

 * Esegui {{{aptitude purge samba}}} per eliminare il vecchio samba
 * Elimina o sposta {{{/etc/samba}}} e {{{/var/lib/samba}}} in modo che l'installazione nuova sia PULITA
 * Vai su https://portal.enterprisesamba.com/ e segui le istruzioni per installare samba piu` moderno (al momento 4.2.x)
 * Installa il pacchetto {{{sernet-samba-ad}}} che si porta dietro le dipendenze richieste
 * Installa il pacchetto {{{acl}}} che verra` utile
 * Modifica il file /etc/default/sernet-samba per impostare {{{SAMBA_START_MODE="ad"}}}
 * Ricorda che gli script di init si chiamano sernet-samba-qualcosa, e che quello che ti interessa usare e` {{{/etc/init.d/sernet-samba-ad}}}

Il vantaggio di usare Samba 4.2.x e` che si puo` fare un file server facilmente sul DC, cosa che e` sconsigliatissima prima della 4.2.

Per poter vedere correttamente gli utenti di Samba dal sistema (sulla macchina stessa del DC AD), usando samba 4.2 o superiore, e` sufficiente verificare che winbindd stia girando (ps ax) e poi modificare il file {{{/etc/nsswitch.conf}}} come segue:

{{{
passwd:         compat winbind
group:          compat winbind
}}}


=== Configurazione di NTP ===

Fare riferimento al paragrafo "Configurazione di NTP" in [[../ConfigAD]]



=== Provisioning del dominio AD ===

Il passo successivo e` la migrazione vera e propria dei dati, ovvero il provisioning iniziale del dominio AD basandosi sui dati che abbiamo salvato dal vecchio samba 3.

Per eseguire il provisioning, ci servono i seguenti files del vecchio Samba:
 * Da /etc/samba:
  * smb.conf 
 * Da /var/lib/samba: (e relative sottodirectory, che non sono sempre le stesse a seconda delle versioni di Samba 3)
  * secrets.tdb 
  * schannel_store.tdb
  * passdb.tdb 
  * group_mapping.tdb
  * account_policy.tdb
 * Da /run/samba:
  * gencache_notrans.tdb
 
Questi files devono trovarsi tutti nello stesso posto, quindi provvediamo a metterli tutti in una directory temporanea da qualche parte. In questo esempio, li metteremo in {{{/root/oldsamba}}}

Poi verifichiamo che non esista un file {{{/etc/samba/smb.conf}}}, perche` il provisioning ne generera` uno per noi.

Quando siamo pronti, eseguiamo il provisioning in questo modo:

{{{
samba-tool domain classicupgrade --dbdir=/root/oldsamba/ --use-xattrs=yes  --realm=mbuti.locale --dns-backend=SAMBA_INTERNAL /root/oldsamba/smb.conf
}}}

Piccola spiegazione: Il realm lo imposto uguale al dominio locale (mbuti.locale) che deve iniziare con "mbuti", che e` il nome del dominio NT. In questo modo i client riconoscono il nuovo dominio AD (mbuti.locale) come il loro dominio di appartenenza.
 

'''ATTENZIONE''': se il server ha piu` di una scheda di rete, e` necessario dire a samba-tool quale vogliamo usare per Samba, e quindi dovremo aggiungere i parametri relativi alla chiamata di Samba-tool, quindi:

{{{
samba-tool domain classicupgrade --dbdir=/root/oldsamba/ --use-xattrs=yes --realm=mbuti.locale --dns-backend=SAMBA_INTERNAL --option="interfaces=lo eth0" --option="bind interfaces only=yes" /root/oldsamba/smb.conf
}}}

Ora bisogna leggere l'output per vedere se ci sono informazioni utili (ovvero warning o errori). Una delle informazioni utili per esempio e` che l'utente "root" in Samba sarebbe meglio non usarlo piu`, ma usare "administrator". Il convertitore provvede a dare all'utente Administrator la password di root, e lascia anche root, suggerendo pero` che sarebbe meglio cancellarlo e non usarlo piu`.

Il SID del dominio deve essere mantenuto (e se controlliamo, vediamo che lo e` stato). 

I gruppi principali, se c'erano prima (domain admins, domain users, domain guest) non verranno importati in quanto esistono gia` nella infrastruttura nuova (ergo ci sono, non e` che spariscano) e questa cosa ci viene indicata nell'output del comando di classicupgrade.

E` stato automaticamente creato un file /etc/samba/smb.conf contenente una configurazione minimale. Questo file andra` integrato con la definizione degli share utente che vorremo aggiungere (ovvero migrare dalla vecchia installazione). Di questo ne parliamo dopo.

Esempio dell' smb.conf autocreato dalla funzione di classicupgrade:
{{{
# Global parameters
[global]
        workgroup = MBUTI
        realm = mbuti.locale
        netbios name = SAMBA4
        interfaces = lo eth0
        bind interfaces only = Yes
        server role = active directory domain controller
        idmap_ldb:use rfc2307 = yes

[netlogon]
        path = /var/lib/samba/sysvol/mbuti.locale/scripts
        read only = No

[sysvol]
        path = /var/lib/samba/sysvol
        read only = No
}}}


=== Configurazione del DNS ===

Prima di procedere ricordiamoci che e` necessario che il DNS usato dai client sia quello interno di Samba, ovvero che sia un altro DNS configurato pero` per richiedere a Samba alcuni hostname speciali del dominio AD. Dobbiamo quindi assicurarci di avere le configurazioni corrette sia per i client che per il server Samba stesso, che anche lui deve poter risolvere questi nomi.

Se sulla macchina dove gira Samba non c'e` alcun server DNS attivo, possiamo, per i test, impostare "nameserver 127.0.0.1" nel resolv.conf (cosi` il nostro DNS sara` Samba) e impostare in /etc/smb.conf una riga che dice chi e` il nostro DNS upstream (quello che avevamo prima in resolv.conf), cosi`:
{{{
dns forwarder = 192.168.5.2
}}}

Notate che non basta un reload di samba, serve un restart perche` prenda la configurazione del forwarder.

In seconda battuta poi possiamo scegliere di usare un'altra soluzione per il DNS, l'importante e` che i client possano risolvere i vari nomi interni del dominio AD. 

Vedasi [[../IntegrazioneSambaDnsmasq]]




=== Test del dominio ===

Avviamo samba4 (e gia` che ci siamo lo rendiamo avviabile al boot):
{{{
insserv sernet-samba-ad
service sernet-samba-ad start
}}}

Ora possiamo eseguire gli stessi test che sono indicati qui: [[../ConfigAD]]

In questo caso, per esempio, riporto i comandi e l'output relativo:

{{{
#  host -t SRV  _ldap._tcp.dc._msdcs.mbuti.locale
_ldap._tcp.dc._msdcs.mbuti.locale has SRV record 0 100 389 samba4.mbuti.locale.


#  smbclient -L localhost -U%
Domain=[MBUTI] OS=[Windows 6.1] Server=[Samba 4.2.3-SerNet-Debian-7.wheezy]

        Sharename       Type      Comment
        ---------       ----      -------
        netlogon        Disk
        sysvol          Disk
        IPC$            IPC       IPC Service (Samba 4.2.3-SerNet-Debian-7.wheezy)
Domain=[MBUTI] OS=[Windows 6.1] Server=[Samba 4.2.3-SerNet-Debian-7.wheezy]

        Server               Comment
        ---------            -------

        Workgroup            Master
        ---------            -------

# smbclient //localhost/netlogon -UAdministrator -c 'ls'
Enter Administrator's password:
Domain=[MBUTI] OS=[Windows 6.1] Server=[Samba 4.2.3-SerNet-Debian-7.wheezy]
  .                                   D        0  Sat Aug 22 22:24:31 2015
  ..                                  D        0  Sat Aug 22 22:24:35 2015

                7867856 blocks of size 1024. 6328424 blocks available
}}}



=== Configurazione degli share ===

Ragionevolmente avevamo degli share di dati prima della migrazione, che vanno riportati nella nuova. Il Wiki di Samba.org dice che e` buona cosa gestire tutte le ACL degli share da Windows, usando gli strumenti di gestione del dominio. Per questo motivo dovremo prendere la nostra configurazione originale ed estrarne solo il minimo necessario per condividere i files, poi dovremo, da Windows, riaggiustare tutte le ACL sugli share.

Gli share amministrativi (netlogon, printers$, IPC$, ecc) non ce li portiamo dietro. Eventuali script di logon andranno risistemati dentro al nuovo share di netlogon del dominio AD, che e` parte del provisioning di base della nuova configurazione. Per i driver delle stampanti al momento non ho una procedura pronta, cosi` come non ne ho una per gli share "home" o per gli share ad accesso pubblico o anonimo.

Tenendo conto dei permessi che vogliamo per ognuno degli share, prendiamo queste istruzioni qui [[../CreazioneShares]] e ricostruiamo (e poi dovremo testare) i nostri shares.

Visto che non stiamo partendo da zero, dovremo ricordarci di modificare le ACL sui files in modo congruo con le nostre esigenze. Ricordiamo che ora l'attributo "x" non mappa piu` gli attributi speciali DOS, ma mappa realmente il permesso da parte dei client di eseguire o meno un file. Quindi ora "r" non implica "x".

Ricordiamoci anche che dobbiamo impostare i permessi anche su tutti gli oggetti contenuti negli share e non solo sulla directory principale dello share. Si fa tutto dalla interfaccia di windows, comunque.


=== Configurazione degli script di logon ===

Con il passaggio a AD si perde lo script di logon di default per gli utenti, per cui a meno che non ci fossero utenti con uno script di logon "personale", ora (come si puo` vedere anche dal comando {{{pdbedit -L -v}}}) lo script di logon non e` valorizzato (campo vuoto). Questo vuole dire che dobbiamo risistemare le cose.


=== Test dei client ===

Un client Windows 7 che era gia` nel dominio dovrebbe collegarsi senza problemi al nuovo DC AD semplicemente accendendolo e facendo login normalmente. Occorre verificare che questo sia vero, e poi occorre verificare una serie di cose:

 * lo script di logon funziona?
 * posso accedere a un client con un utente del dominio che non vi ha mai acceduto prima?
 * posso cambiare la password a un utente del dominio, e il cambio viene realmente fatto sul server?
 * i permessi sul client per l'amministratore del dominio sono corretti? (cioe` posso per esempio modificare delle proprieta` del sistema client che come utente mi sono inibite?)
 * i permessi sul client per un utente normale sono corretti? (vedi sopra)