Migrazione di un PDC samba3 da un server a uno nuovo

Questa procedura descrive le operazioni necessarie per sostituire un server (PDC con Samba 3.0.14a) con un nuovo computer con samba 3.0.24. si tratta di una sostituzione in blocco, quindi il nuovo server prende il posto del vecchio e il vecchio viene spento. E` stata provata anche con diverse versioni di samba 3.x piu` recenti (3.2.x, 3.5.x), ed ha sempre funzionato.

E` importante ricordare che i client scambiano chiavi con il server e che queste chiavi cambiano nel tempo, quindi durante la migrazione occorre che i client siano spenti (cosi` non modificano le loro chiavi) e una volta riaccesi sul nuovo server non e` detto che sia possibile tornare indietro al vecchio. Nel caso in cui un client non riesca piu` a riconoscere il dominio a causa di un cambio di chiavi avvenuto in un momento critico della migrazione lo si dovra` togliere e rimettere nel dominio.

Backup delle informazioni

Copia dei dati di config dalla vecchia macchina a quella nuova

Problema dei dischi mappati che non vanno

Capita (non so perche`) che dopo il cambio i dischi mappati non siano piu` accessibili, mentre i percorsi UNC funzionano benissimo. Nel caso, e` sufficiente smappare e rimappare i dischi. Puo` essere fatto cancellandoli a mano e poi rieseguendo il logon script oppure inserendo in cima al logon script una riga che smappi tutto, cosi`:

net use * /delete /yes

Problemi di charset

Se il vecchio server usava (sul file system) charset che non siano utf-8 e il nuovo invece usa utf-8, puo` essere necessario convertire il charset (oppure dire a samba di usare il charset vecchio). Vedasi LinuxDebian/RsyncSshBackup per come convertire il charset con rsync (anche in locale, senza fare una copia)

Problema del mapping dei gruppi

In Samba 3.0.24 la generazione dei GID dei gruppi che non siano stati definiti con "net groupmap" e` cambiata. Quindi se si migra da un server vecchio a uno con 3.0.23 o superiore occorre fare bene attenzione a quanto segue:

The user and group internal management routines have been rewritten to prevent overlaps of assigned Relative Identifiers (RIDs). In the past the has been a potential problem when either manually mapping Unix groups with the 'net groupmap' command or when migrating a Windows domain to a Samba domain using 'net rpc vampire'.

Unmapped users are now assigned a SID in the S-1-22-1 domain and unmapped groups are assigned a SID in the S-1-22-2 domain. Previously they were assign a RID within the SAM on the Samba server. For a DC this would have been under the authority of the domain SID where as on a member server or standalone host, this would have been under the authority of the local SAM (hint: net getlocalsid).

The result is that any unmapped users or groups on an upgraded Samba domain controller may be assigned a new SID. Because the SID rather than a name is stored in Windows security descriptors, this can cause a user to no longer have access to a resource for example if a file was copied from a Samba file server to a local NTFS partition. Any files stored on the Samba server itself will continue to be accessible because Unix stores the Unix gid and not the SID for authorization checks.

A further example will help illustrate the change. Assume that a group named 'developers' exists with a Unix gid of 782 but this user does not exist in Samba's group mapping table. it would be perfectly normal for this group to be appear in an ACL editor. Prior to 3.0.23, the group SID might appear as S-1-5-21-647511796-4126122067-3123570092-2565. With 3.0.23, the group SID would be reported as S-1-22-2-782. Any security descriptors associated with files stored on an NTFS disk partition would not allow access based on the group permissions if the user was not a member of the S-1-5-21-647511796-4126122067-3123570092-2565 group. Because this group SID not reported in a user's token is S-1-22-2-782, Windows would fail the authorization check even though both SIDs in some respect referred to the same Unix group.

The current workaround is to create a manual domain group mapping entry for the group 'developers' to point at the S-1-5-21-647511796-4126122067-3123570092-2565 SID.

Samba/Samba3Migration (last edited 2014-05-22 20:23:23 by Kurgan)