Diff for "Samba4/UpdateDCtoAD"

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

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.

Test dei client