Migrer un domaine Samba3 vers Samba4

1. Introduction et processus de migration

Le processus proposé par Samba n'implique pas de devoir recréer le domaine ainsi que l'ensemble des comptes. Bien qu'il soit possible de mettre à jour un serveur existant, il est par contre nettement préférable de passer par un nouveau serveur. Sachant qu'il y a deux types de sysadmins, ceux qui ont fait une boulette et ceux qui ne vont pas tarder à en faire une, autant passer par cette méthode et repousser l'échéance de la prochaine bourde.

Pour la démonstration, je vais partir d'un domaine existant PLANETEXPRESS disposant de quelques comptes utilisateurs actifs. Pour le lecteur curieux qui souhaite reproduire les étapes de migration mais qui n'a pas de serveur samba3 sous la main, je vais très succinctement rappeler la mise en place d'un domaine NT4, sans entrer dans le détail de la configuration ou des partages.

Le futur serveur de son côté est donc une nouvelle installation. Dans le processus de migration du domaine, on ne procède pas à la création d'un nouveau domaine via un samba-tool provision, mais on créé le domaine en aspirant le contenu des bases Samba3 afin de migrer l'ensemble des objets du domaine tout en conservant les identifiants de sécurité (SID).

2. Le domaine NT4

Je vais partir d'un serveur samba3 en version 3.5.6 nommé disons srv-pdc et faire fonctionner une Debian Squeeze, donc stable. La configuration exposée ici n'a pas pour but de rentrer dans le détail du fonctionnement et de la configuration de Samba, aussi je resterai assez succinct.

On va commencer par créer deux groupes dont le nom parle de lui-même quant à leur fonction, puis on associe les groupes Windows génériques à nos comptes Unix :

On ajoute au moins un compte à ce domaine et on génère un mot de passe avec un hash NTLM :

Enfin, il faut bien entendu déclarer notre serveur comme étant capable de gérer les authentifications sur le réseau et on le déclare sur les listes d'exploration Netbios. Pour faire court, les lignes utiles à ce niveau se résument à :

Il ne reste plus qu'à redémarrer Samba3 et on peut enfin attaquer les choses sérieuses !

3. Le nouveau serveur Samba4

3.1. Pré-requis :

Le futur serveur nommé srv-ad est sous Debian Testing pour des raisons de compatibilité entre le plugin pour les backend de zones dynamiques pour Bind fourni par Samba4 et la version de Bind de la distribution. Bien entendu, il est possible de compiler la bonne version de Bind pour Debian Testing. Le serveur se prépare de la même manière qu'un nouveau domaine. Le serveur devra donc être maintenu à l'heure par un serveur NTP proprement configuré et les partitions devront être montées avec les attributs user_xattr et acl.

Tout comme pour un nouveau serveur, on va avoir besoin des dépendances suivantes, je vous conseille également d'adapter votre variable d'environnement $PATH avec la valeur ci-dessous :

Il restera ensuite à récupérer les sources de ldb et samba4 (en beta5 lors de la rédaction de cet article ) depuis ftp.samba.org et à les compiler à l'aide des traditionnels ./configure && make && make install.

3.2 Migration

Tout d'abord, il va donc falloir récupérer la configuration qui nous intéresse, disons dans le répertoire /samba3 préalablement créé.

Ensuite, on peut vampiriser les bases issues de l'installation du domaine Samba3 pour créer le domaine Active Directory. Le domaine NT4 se nomme PLANETEXPRESS, j'ai par convention suffixé le domaine du TLD .local, mais ceci n'est en rien une obligation.

Si tout va bien, le domaine aura été aspiré de la même façon, avec une série de jolies erreurs qui pourraient servir à effrayer de jeunes enfants. En effet, le serveur a été migré mais pas les groupes attenants, c'est pour cette raison que le fichier /etc/group de srv-pdc a été récupéré. Je vous propose par conséquent le script suivant qui remettra les choses d'aplomb. Une fois ce script exécuté, je vous invite à démarrer Samba en lançant la commande du même nom.

On peut désormais vérifier que notre domaine est correctement remonté et que l'on liste bien les utilisateurs et leur appartenance aux groupes :

Si tout est en ordre, je vous invite alors à valider la connexion au domaine depuis un poste client Windows. Si l'authentification a fonctionné, le poste doit renvoyer le nom du nouveau serveur. Notez que bien entendu pour que l'authentification fonctionne, le poste client devra être en mesure de résoudre les enregistrements du domaine planetexpress.local, que ce soit au moyen d'un redirecteur DNS pour ce domaine ou bien en indiquant srv-ad comme serveur DNS.

4. Que reste-t-il ensuite ?

Le plus urgent consiste en premier lieu à arrêter les services Samba de l'ancien serveur. Un petit exit 0 au début du script d'init est un choix judicieux car il permet de s'assurer que même en cas de redémarrage de l'ancien serveur, il n'y aura pas les deux serveurs actifs sur le réseau. En effet, le rôle émulateur de contrôleur de domaine de type NT4 est géré par un serveur unique sur l'AD et un seul serveur de ce type doit être présent sur un réseau. De plus, les bases doivent rester cohérentes et donc un seul serveur doit gérer le domaine à la fois.

Au niveau réseau, si vous utilisez encore du WINS, il est toujours possible de paramétrer le fichier smb.conf pour que ce soit pris en charge par les anciens démons samba3, mais il serait sans doute temps de retirer ces options DHCP si elles sont présentes afin de se débarrasser d'une telle vieillerie. Si vous avez une zone DNS sur l'ancien serveur qui risque d'entrer en conflit, je vous conseille de la migrer également dans Samba4. Il est très facile d'automatiser cela via samba-tool. Par exemple :

Il restera enfin les services de fichiers et d'imprimantes. Bien que le fichier smb.conf ait été transféré dans le répertoire /samba3 avant de lancer la migration des bases, cela n'a eu aucun effet sur les partages. Il faudra donc les réintégrer dans le fichier /usr/local/samba/etc/smb.conf. Bien que je n'aborde ce point qu'en fin d'article, c'est finalement presque le plus critique. C'est celui qui touche directement les utilisateurs. Le nom de serveur ayant changé, il est donc fort souhaitable que les utilisateurs travaillent via des lecteurs réseau mappés à la connexion, la directive logon script paramétrée sur le serveur Samba3 vous sera d'une aide précieuse. Enfin, la migration des données est bien entendu à opérer en amont. Il n'est pas tenable de laisser patienter les utilisateurs le temps que les données arrivent. Je ne saurais donc que trop vous recommander un transfert via rsync -AXLzvp –delete afin d'une part de préserver les propriétés des fichiers et surtout de n'avoir qu'un différentiel à traiter lors de la migration en cas réel.