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:

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:

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

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.

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.

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:

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:

Samba4/UpdateDCtoAD (last edited 2015-08-25 08:37:39 by Kurgan)