Questa procedura e` stata verificata con Samba 3.0.14a su Debian Sarge, migrando da un NT4 sp6a.

Scopo dell'operazione

Migrare un dominio da NT4 a samba3, tenendo buoni gli utenti e gli account delle workstation. I gruppi vanno modificati e quindi non e` importante tenerli.

Stato della rete prima dell'operazione

Il server NT che vogliamo eliminare e` il PDC, nella rete si trova un server Samba 3 il quale ha utenti locali con lo stesso username del server NT4, per consentire agli utenti del dominio di accedere al server Samba anche se questo non partecipa al dominio di NT.

Il metodo indicato funziona anche se il server Samba viene installato ex-novo, quindi non ha mai lavorato in affiancamento all' NT, e non ha utenti locali. Inoltre funziona anche se il server Samba contiene solo alcuni utenti locali e non tutti quelli del server NT.

Il metodo indicato NON funziona se il server Samba contiene utenti locali che vanno mantenuti (e che accedono a Samba) che pero` non ci sono nell' NT. in questo caso occorrera` esportare questi utenti dal tdbsam e reimportarli alla fine. Questo caso non e` pero` spiegato.

Il server Samba, non partecipando al dominio, non ha machine accounts in locale, ne` conosce quelli dell' NT.

I gruppi, gli shares, le stampanti, sono totalmente diversi su Samba rispetto a NT, ed esistono gia` su Samba, in parte o per intero, quindi vanno preservati ed eventualmente integrati. Se anche non esistessero la procedura e` valida lo stesso, andranno creati in seguito secondo le proprie esigenze.

Vincoli tecnici e organizzativi

• Linux deve diventare PDC e NT va eliminato dalla rete nello stesso istante.
• La migrazione va fatta a rete totalmente ferma, quindi il tempo di migrazione deve essere breve (un weekend al massimo)
• Dal momento del cambio di PDC in poi e` chiaro che i client non accederanno piu` ad alcuno share sul vecchio NT, quindi occorre che stampanti e share non siano piu` in uso sull' NT da prima della migrazione. Di fatto l' NT deve avere solo funzione di PDC ed eventualmente di WINS server.
• Il SID del dominio va mantenuto fra i due PDC, altrimenti non funziona piu` nulla
• il SID dei gruppi principali (Domain Users, Domain Admins, e Domain Guests) va tenuto uguale durante la migrazione. Per fortuna questi SID hanno valori standard (513, 512 e 514) e quindi si mantengono senza dover fare nulla di particolare.
• il nome del dominio va mantenuto, come sopra.
• Il nome del server Samba e` diverso da quello dell' NT, e lo rimarra`.
• Il nome e il SID degli account di utente vanno mantenuti, cosi` come le password di accesso degli utenti. Per fortuna gli username usati sull' NT sono compatibili con Linux in termini di lunghezza e caratteri usati.
• Il nome e l' UID (lato linux) degli account gia` presenti sul server Samba prima della migrazione vanno mantenuti, cosi` come le home. Questo perche` nel nostro caso ci sono gia` dati e share su Linux a cui gli utenti accedono.
• Il nome e il SID degli account delle macchine vanno mantenuti, cosi` da non dover rimettere tutti i client nel dominio.
• I gruppi presenti su NT vanno persi, i gruppi gia` presenti su Linux (e le assegnazioni degli utenti ai gruppi) vanno conservati e integrati eventualmente con alcuni nuovi.
• Non vi sono policy da mantenere nella migrazione
• I dati (files degli utenti) sono gia` stati sistemati e non ci sono contenuti degli share da migrare all'atto del cambio di PDC.
• Gli script di login vanno rifatti adatti alle nuove esigenze
• Le stampanti condivise sono gia` presenti sul server Linux, e vanno mantenute.
• La funzione di server WINS deve passare dall' NT al Samba al momento della migrazione.

---

Operazioni da eseguire per migrare

Di seguito sono indicate le operazioni da eseguire in sequenza nel momento in cui si effettua la migrazione.

Backup configurazioni Linux

• Copiare /etc/passwd, /etc/group, /etc/shadow, e tutti i files di /var/lib/samba da qualche parte.
• Copiare i files in /var/spool/samba da qualche parte.

Esecuzione del "vampire"

ATTENZIONE: dal momento che si joina il dominio come BDC, i client cominciano a chiedere al BDC di autenticare, quindi siccome stiamo ancora migrando le configurazioni di fatto i client ricevono risposte farlocche che pero` considerano valide! In questa fase la rete deve essere ferma.

• Fermare Samba

• Cancellare (ne abbiamo una copia) il file /var/lib/samba/passdb.tdb contenente gli account utente di Samba.

• Mappare i gruppi di base (domain admins, domain users, domain guests)
  • creare il gruppo ntadmins

  • usare i comandi net groupmap modify per mappare almeno i tre succitati gruppi.

L'esempio di seguito effettua entrambe le operazioni sopra descritte.

adduser ntadmins
net groupmap modify ntgroup="Domain Guests" unixgroup=nogroup
net groupmap modify ntgroup="Domain Admins" unixgroup=ntadmins
net groupmap modify ntgroup="Domain Users" unixgroup=users

• Joinarsi al dominio come BDC

  • mettere domain master=no in smb.conf

  • mettere il dominio giusto in smb.conf
  • Lanciare samba

  • usare il comando net rpc join -S sntgiepr01 -W GIEPR -UAdministrator%password per joinare il dominio

  • usare il comando net getlocalsid per verificare il SID del dominio appena acquisito dall' NT.

  • Volendo, usare il comando net rpc samdump -S sntgiepr01 -W GIEPR -UAdministrator%password > filename per dumpare su un file tutti i dati degli utenti e gruppi del server NT. Non e` necessario, ma aiuta poi a capire cosa c'e` che non va, nel caso.

  • Operazioni di pulizia dei gruppi (probabilmente inutili)

    • Fermare samba, rinominare il file /var/lib/samba/group_mapping.tdb, eseguire net groupmap list per verificare se i gruppi sono tutti non mappati

    • Rieseguire la mappatura di base dei gruppi. Notare se i SID dei gruppi contengono i valori propri del dominio NT che stiamo migrando.

  • usare il comando net rpc vampire -S oldnt4pdc -U Administrator%password > vam.log 2>errori_vamp.log per vampirare loggando stdout e stderr.

A questo punto ci si trova con uno strano casino. Gli utenti sono portati correttamente, e gli account delle macchine anche, sempre che rispettino i limiti di dimensione dei nomi degli utenti e delle macchine. Gli utenti che in Linux (/etc/passwd) esistevano gia` sono rimasti li` e hanno conservato l' UID, il GID, e tutte le impostazioni presenti in /etc/passwd e /etc/shadow. Gli utenti nuovi sono stati creati con un default che dipende dalla configurazione di Samba. Lo stesso identico discorso vale per i gruppi in /etc/group.

Quello che non viene portato correttamente sono i gruppi con gli spazi, che proprio non vengono creati. Inoltre l'appartenenza degli utenti ai gruppi e` fatta a meta`, perche` il comando che esegue la funzione di "add user to group" in realta` aggiunge l'utente al gruppo indicato, ma lo rimuove da quelli in cui era prima, cosa che non dovrebbe fare. Il risultato e` che gli utenti sono membri solo dell'ultimo gruppo in cui appaiono. La cosa tuttavia non ci preoccupa perche` i gruppi sono da rifare.

Sarebbe bene verificare nei log del comando di vampire che gli errori siano circoscritti e gestibili. (tipicamente sono circoscritti a utenti o gruppi con nomi non validi, ovvero con spazi dentro)

Nota che gli account di macchina vengono messi dentro al GID 513 (domain users) anziche` 514 (domain guests) come fa Linux se joini le macchine al dominio. La cosa non dovrebbe provocare casino, pero`, quindi li lasciamo cosi` a meno che non abbiamo tempo da perdere.

Promozione di Linux a PDC dopo il vampire

Nota: occorre staccare dalla rete il vecchio PDC NT prima di lanciare samba sul nuovo. Questa roba viene fatta con i demoni di samba spenti.

• Provare con pdbedit -L -v se a naso i SID sono quelli giusti (cioe` parte del dominio interessato alla migrazione)

• Mettere a punto i files /etc/passwd ed /etc/group
  • Verificare se in /etc/passwd sono stati creati gli utenti
    • Se gli utenti erano tutti gia` presenti, non dovrebbero essere stati creati ex-novo
    • Se qualche utente e` stato aggiunto nella migrazione, verificare che sia a posto e che magari non sia obsoleto e da cancellare.
  • Verificare se in /etc/passwd sono state creati gli account di macchina e sono giusti come GID e home.
  • Nota che in /etc/shadow gli utenti aggiunti ex-novo hanno "!" al posto di "*" come password disattivata. Questo aiuta a capire quali sono nuovi.
  • Editare /etc/group ed eliminare tutti i gruppi inutili che sono stati migrati. Occhio al gruppo "Users" che viene creato e che ovviamente non e` "users" standard. Eliminarlo senza pieta`.

  • Se si eliminano utenti, magari farlo con userdel -r per fare secche le home (controlla prima che non puntino a qualcosa che sia pericoloso!) e le entry in shadow.

• Sistemare i nuovi gruppi
  • Aggiungere root al gruppo ntadmins in /etc/group

  • modificare l'account di root con pdbedit per dargli il primary group SID 512 (domain admins) pdbedit  root -r -G="S-1-5-21-610474926-686117454-311576647-512"

  • verificare con pdbedit se gli utenti sono stati messi correttamente tutti con il primary group SID 513 (domain users)
  • editare /etc/group, magari prendendo pezzi dal backup, per rimettere a posto i gruppi che c'erano prima. Probabilmente con un minimo di occhio si puo` riprendere il backup senza stare tanto a copiaincollare, in quanto non ci interessa tenere i nuovi gruppi e invece ci interessa tenere i vecchi, che possono essere stati massacrati dal problema dell' "add user to group" citato prima.

  • Pulire il group mapping di samba a colpi di net groupmap delete ntgroup="nome gruppo" eliminando tutti i gruppi vecchi che sono stati migrati ma non ci servono.

  • Aggiungere i gruppi nuovi con net groupmap add ntgroup="groupname" unixgroup=groupname type=d (non credo che serva, dal momento che non c'e` nulla da mappare se i nomi dei gruppi sono uguali fra Linux e Windows)

• Modificare smb.conf mettendo domain master=yes e wins support = yes, e levando wins server = 10.0.0.251

• Modificare il server DHCP per riflettere la modifica al WINS SERVER.
• Lanciare samba
• Eliminare l'account "Administrator" e sostituirlo con "root" (se si vuole avere "root" come amministratore, credo che non sia necessario ma che semplifichi molto il join delle nuove WS al dominio)
  • usare pdbedit o smbpasswd per segare "administrator"
  • usare pdbedit per dare all'utente root un user SID che finisca in "500", il che lo identifica come amministratore primario del dominio. (il SID che finisce in 500 e` proprio dell'utente administrator di NT)

Test del nuovo PDC

• eventualmente tracciare il traffico con tethereal sul server per avere una visione piu` chiara.
• Tentare con un client di fare logon al dominio con diversi utenti, anche utenti che non si siano mai loggati da quel client, per saltare la cache.
• verificare empiricamente se i permessi di accesso ai profili locali sul client sono ancora al loro posto

• dal client eseguire qualche net user <username> /domain per vedere se i dati dell'utente (e la mappatura dei gruppi) vengono letti bene dal nuovo PDC.

• provare a joinare un nuovo client al dominio e vedere se funziona.

---

Cose utili da sapere

E` possibile esportare e importare i dati dal backend tdbsam a un file XML, il che puo` venire utile per editarli a mano.

I comandi sono i seguenti:

$ pdbedit -e xml:filename (per esportare sul file "filename")
$ pdbedit -i xml:filename (per importare)

NOTA: occorre avere installato (cioe` presente) il plug-in XML per pdbedit, il quale non fa parte di nessuna distro samba per Debian. Il workaround molto sporco e` stato prendere quello della Suse 9 della versione di Samba corrispondente con quella che uso. Detto file va messo in /usr/lib/samba/pdb/xml.so, ed e` disponibile per Samba 3.0.14a qui: xml.so. Occorre anche installare il pacchetto libxml2

Per verificare che cosa viene registrato nel wins, nel caso in cui i client dovessero avere difficolta` a trovare il PDC, e` utile leggere (volendo editare anche) il file /var/lib/samba/wins.dat che e` in testo. il PDC ha come nome netbios una stringa composta dal nome del dominio seguita dal carattere "1B" hex.