Workgroups, Domaines et MSWindowsRunOnce

vendredi 15 juin 2007
par  f
popularité : 33%

Suite à de nombreuses difficultés rencontrées pour rattacher une machine à un workgroup ou à un domaine Windows, une nouvelle procédure a été mise en place dans JeDDLaJ v1.4IBE. Elle repose principalement sur une nouvelle fonction : MSWindowsRunOnce.

Workgroups et Domaines sous JeDDLaJ v1.4IBE

Que dois-je faire pour que mes machines entrent automatiquement dans un domaine ou un workgroup ?

Voici pour les plus impatients les 3 étapes nécessaires à réaliser :

  1. dans le menu "Général" de "Modifier machine" indiquez l’affiliation Windows de votre machine ainsi que le nom de cette affiliation. La différence entre domain (PDC Windows) et sambadomain (PDC Samba) est purement informative, vous pouvez, si vous le voulez, utiliser domain pour joindre un domaine géré par un PDC Samba ;
  2. pour chaque domaine vous devez :
    1. créer un fichier nommé <NOM_DU_DOMAINE>_settings.rbc, dans lequel vous renseignerez les variables ADMINDOMAINE et ADMINPASSWD, avec respectivement le nom d’un compte ayant le droit de joindre une machine à ce domaine, et le mot de passe de ce compte ;
    2. malgré le nom de ces variables, il n’est pas nécessaire et même déconseillé, d’utiliser le compte administrateur du domaine. Pour un domaine samba par exemple, utilisez un compte auxquels vous aurez donné le privilège SeMachineAccountPrivilege. Imaginons que voue ayez créé un compte utilisateur toto dans le domaine MONDOMAINE, que le serveur PDC s’appelle MONPDC et le compte adminstrateur du domaine soit admindemondomaine :
      net rpc rights grant 'MONDOMAINE\toto' SeMachineAccountPrivilege -S MONPDC -U admindemondomaine

Il faut avoir au préalable activé la gestion des privilèges dans Samba avec la directive enable privileges = yes dans le fichier smb.conf ;

    1. compilez le fichier <NOM_DU_DOMAINE>_settings.rbc (afin que les informations n’apparaissent plus en clair) ;
    2. déposez le fichier <NOM_DU_DOMAINE>_settings.rbx dans le répertoire désigné par la variable RemboJeDDLaJScriptsDir ;
  1. choisissez une distribution Windows pour votre ordinateur par le menu "Modification de la configuration logicielle".

IMPORTANT : il n’y a plus de contrainte au niveau de l’image de base créée. La jonction au domaine ou au workgroup sera possible quelle que soit l’affiliation faite à la création de l’image de base.

Si vous vous demandez comment est utilisé le mot de passe que vous avez mis dans le fichier <NOM_DU_DOMAINE>_settings.rbx, ou bien comment joindre un AD Windows, vous allez devoir lire ce qui suit.

MSWindowsRunOnce

La fonction MSWindowsRunOnce(cmd), ajouté dans jeddlaj.rbc, permet de placer dans le registre Windows une commande qui sera exécutée une seule fois au premier boot du système. La commande donnée en argument cmd doit être une commande connue de Windows (pas du code Rembo !).
Vous pouvez appeler cette fonction depuis vos scripts de post-installations ; si plusieurs appels sont effectués, toutes les commandes seront exécutées, dans l’ordre d’installation des logiciels associés aux scripts de post-installations.
Par exemple, si vous souhaitez ajouter un driver en mode silencieux :

Voici en détails le déroulement des opérations lorsqu’on ajoute un logiciel avec un post-install script faisant appel à MSWindowsRunOnce(cmd) :

  1. la machine boote sous PXE
  2. la machine est en état "modifié" : il y a donc des modifications à faire sur la machine
  3. l’image de base est en état "modif_softs" : il s’agit d’un ajout ou d’une suppression (ou les deux) de logiciels
  4. le soft est ajouté, le post-install script exécuté et la commande cmd placé sous l’arborescence Windows dans le fichier jrunonce.cmd
  5. l’image de base passe en état "reboot"
  6. la machine boote sous Windows
  7. le fichier jrunonce.cmd est exécuté puis détruit
  8. la machine reboote sous PXE
  9. la machine est en état "modifié" : il y a donc des modifications à faire sur la machine
  10. la machine est en état "reboot" : si le fichier jrunonce.cmd a disparu de l’arborescence Windows c’est que l’opération s’est déroulée entièrement, sinon on repart en 6
  11. l’image de base passe en état "installé"
  12. la machine passe en état "installé"
  13. présentation du menu de boot, ou boot sous Windows si pas d’autres distributions installées.

jjoinc.exe

Pour joindre un domaine ou un workgroup, JeDDLaJ utilise maintenant la fonction MSWindowsRunOnce, pour lancer au premier boot Windows l’ éxécutable jjoinc.exe. Ce petit programme développé par nos soins repose sur les fonctions NetJoinDomain et NetUnjoinDomain de la librairie Netapi32.dll. Voici les arguments à utiliser :

jjoinc.exe [domain|workgroup] [domain|workgroup] [OU] [nom de domaine ou workgroup] [compte utilisateur domaine] [mot de passe utilisateur domaine]

- Le premier argument indique dans quel type d’affiliation le système se trouve avant le rattachement : domaine ou workgroup ;
- le deuxième argument indique quel type de rattachement on veut effectuer : domaine ou workgroup ;
- le troisième argument précise l’OU (Organizational Unit) dans le cas d’un domaine AD ;
- les quatrième et cinquième arguments requis dans le cas d’un rattachement à un domaine concernent le nom et mot de passe compte du compte utilisé pour réaliser ce rattachement.

Voici les arguments donnés par JeDDLaJ à jjoinc.exe :
- si l’image de base a été faite dans un domaine, le premier argument est positionné à domain. Ainsi, à l’exécution de jjoinc.exe le compte machine sera retiré du domaine dans lequel l’image a été faite, et ce avec les renseignements contenus dans le registre. Sinon le premier argument est positionné à workgroup ;
- si la machine doit être rattachée à un domaine, le deuxième argument est positionné à domain. Sinon il est positionné à workgroup ;
- Ètant donné que les AD ne sont pas gérés au niveau de l’interface Web de JeDDLaJ, l’argument OU est postionné à null . Si vous voulez modifier ce comportement, modifiez la fonction JoinDomainOrWorkgroup en remplaçant la valeur null ;
- si la machine doit être rattachée à un domaine, les informations inscriptes dans le fichier <NOM_DU_DOMAINE>_settings.rbx seront utilisés pour les deux derniers arguments.

La ligne de commande de jjoinc.exe apparaît en clair dans le fichier jrunonce.cmd posé dans l’arborescence Windows. Quels sont les risques pour le mot de passe ?
- la ligne de commande ne s’affiche évidemment pas à l’écran lors de son exécution ;
- le mot de passe, on le rappelle, ne doit pas être celui d’un administrateur du domaine ;
- la durée du fichier jrunonce.cmd est réduite au temps d’éxécution du premier boot de Windows ;
- il n’est pas possible de prendre la main avant la fin de ce premier boot grâce au positionnement d’une variable dans le registre indiquant que le processus d’installation n’est pas terminé ;
- pour accéder au fichier jrunonce.cmd il faudrait :

  1. interrompre la machine pendant son premier boot sous Windows ;
  2. accéder au système de fichiers Windows, soit en ayant la possibilité de booter sur un liveCD soit en déplaçant le disque dans une autre machine possédant son propre système d’exploitation.

Si vous n’excluez pas cette éventualité vous préférerez peut-être modifier le code de jeddlaj.rbc en changeant l’appel de JoinDomainOrWorkgroup par JoinDomainOrWorkgroup2. Cette dernière fonction utilise les procédures natives Rembo et une fonction développée par Geoffroy Desvernay (dgeo AT ec-marseille DOT fr) et Jean-Luc Fornacciari (jean-luc.fornacciari AT ec-marseille DOT fr).

Lisez ce qui suit pour connaître le détail de ces procédures.

Les fonctions pour joindre Workgroups et Domaines

Voici dans l’ordre historique les fonctions utilisées pour joindre un workgroup ou un domaine avec Rembo/JeDDLaJ.

NTJoinDomain

Cette fonction native de Rembo 2, et conservée pour des raisons de compatibilté sous Rembo 4, permet de joindre un PDC Windows...sous certaines conditions :

  1. le serveur Rembo doit être installé sur une machine Windows ;
  2. le service Rembo Server doit tourner en tant qu’un compte ayant droit d’ajouter une machine dans le domaine (Paramètres-> Panneau de configuration-> Outils d’administration-> Services-> Connexion-> Ce compte) ;
  3. l’image de base utilisé lors du déploiement doit avoir été faite dans ce domaine.

En constate rapidement que :

  1. le serveur Rembo ne pas être installé sur un autre système que Windows ;
  2. On ne peut joindre qu’un seul domaine ;
  3. on ne peut pas joindre un domaine Samba ;
  4. on ne peut pas utiliser n’importe quelle image de base.

NTSetWorkgroupName

Cette fonction permet de CHANGER le nom du workgroup contenu dans l’image de base, ce qui sous-entend que l’image de base utilisée doit avoir été faite au sein d’un workgroup.

SmbJoinDomain

Cette fonction développée par Geoffroy Desvernay et Jean-Luc Fornacciari permet de pallier au problème du rattachement dans un environnement domaine Samba/LDAP. Il s’agit d’un démon qui va recevoir les demandes de rattachement via un tunnel déclaré sur le serveur Rembo.

Mise en oeuvre :

  1. installer les fichier du répertoire rembo/SmbAddMachine contenus dans l’archive, sur une machine de type UNIX possédant un interpréteur PERL ;
  2. modifier le fichier configuration SmbAddMachine.conf en y indiquant entre autre le port d’écoute du démon ;
  3. lancer le programme SmbAddMachine.pl ;
  4. déclarer un nouveau tunnel sur le serveur Rembo nommé SmbAddMachine en y indiquant l’adresse IP du serveur et le port sur lesquels le démon tourne.

Remarque : les images de bases utilisées doivent avoir été faites dans LE domaine Samba PDC auquel on veut se rattacher.

JoinDomain

Cette fonction est apparue dans Rembo 4 (avec son homologue ADSJoinDomain pour active directory).

Avec cette fonction vous n’aurez pas besoin de faire tourner le service Rembo Server sous un utilisateur privilégié mais il faudra indiqué le nom et le mot de passe de ce compte directement dans l’appel de la fonction.

Comme pour NTJoinDomain l’image de base utilisée doit avoir été faite dans un domaine.

L’agent Rembo rbagent

Une dernière méthode consiste à utiliser l’agent de Rembo 4. Exécuté depuis Windows avec l’option -o joindomain, il permet le rattachement à un domaine ou à un AD. Les arguments à donner sont le nom de domaine, le compte administrateur, le mot de passe CHIFFRÉ de l’administrateur, et éventuellement l’OU.
En ajoutant le flag /w après joindomain, il rend possible le rattachement à un workgroup.
La méthode pour faire entrer automatiquement une machine, lors d’un déploiement, consiste, comme pour l’utilisation de jjoinc.exe, à faire exécuter rbagent au premier boot de Windows. Il existe une fonction sous Rembo 4, InstallMiniSetup, qui permet cela.
Pour plus de détails, lisez le source Rembo-C utils.rbc, et en particulier l’implémentation de la fonctions ApplySysprepSettings.

Récit d’une migration ou pourquoi avoir écrit jjoinc.exe

En décembre 2006, dans le cadre de la migration de notre SI, nous avons été amenés à remplacer notre contrôleur de domaine NT4 par un serveur SAMBA/LDAP, passant par la même occasion du nom de domaine ANCIEN au nom de domaine NOUVEAU (ce ne sont pas les vrais noms, mais ceux-ci seront plus clairs pour comprendre le déroulement des opérations).

  1. Disposant d’un serveur Rembo 2, nous avons commencé par modifier JeDDLaJ pour y intégrer la fonction SmbJoinDomain ainsi qu’un nouveau type d’affiliation : sambadomain.
    1. Premier problème rencontré : la fonction SmbJoinDomain permettait bien de créer un compte machine dans le domaine NOUVEAU, mais ne changeait pas le nom de domaine dans la bannière de login. Toutes nos images de base ayant été faites dans le domaine ANCIEN, il était impossible de se logguer sur les machines.
    2. Pour contourner ce problème, nous avons créé un package qui retirait le nom ANCIEN de l’image de base pour le remplacer par NOUVEAU.Cela fonctionnait mais ça posait plusieurs autres soucis :
      1. le package apparaissait dans la liste des logiciels installables depuis le menu "Modification de la configuration logicielle" ;
      2. cette solution n’était pas très portable pour être intégrée et distribuée dans JeDDLaJ ;
      3. il fallait à partir de ce moment là distinguer les images créées dans le domaine ANCIEN et le celles qui seraient créées dans le domaine NOUVEAU et pour lesquelles il ne faudrait surtout appliquer le package retirant le nom ANCIEN de l’image de base (puisque ce nom n’y apparaîtrait pas).
  2. Nous avons alors opté pour un mode de rattachement qui se rapprocherait le plus de celui effectué manuellement depuis le poste client. Nous avons commencé par développer la fonction MSWindowsRunOnce. Il fallait ensuite trouver un programme sous Windows qui permette de joindre un domaine et également,si possible, un workgroup.
  3. L’utilitaire netdom.exe semblait être le bon candidat. Il a été utilisé dans JeDDLaJ, jusqu’à ce que la migration des domaines soit terminée et que l’on coupe le contrôleur du domaine ANCIEN. Dès lors, le rattachement au domaine ne marchait plus :
    1. en effet, netdom.exe ne permet pas d’affilier des machines qui sont déjà attachées à un domaine. Il permet de sortir d’un domaine, mais si son contrôleur n’est plus joignable l’opération échoue ;
    2. netdom.exe est basé sur l’API NetJoinDomain de la librairie Netapi32.dll. Cette API prévoit pourtant la possibilité de joindre un domaine même si un rattachement existe déjà (flag NETSETUP_DOMAIN_JOIN_IF_JOINED), mais elle n’a pas été implémentée dans netdom.exe.
  4. Donc nous avons développé un petit utilitaire très semblable mais utilisant lui cette possibilité :
    1. d’abord comme un application "fenêtrée" qui s’exécutait en mode détaché et donc n’attendait pas la fin effective de jointure au domaine : jjoin.exe pour JeDDLaJ-join ;
    2. puis jjoinc.exe version "console" de JeDDLaJ-join affichant les messages de succès ou d’échec des opérations d’affiliation.

Conclusion

La méthode développée dans JeDDLaJ v1.4IBE a l’avantage de marcher dans les versions 2 et 4 de Rembo, d’être indépendante de l’image de base,de la nature du contrôleur de domaine et du système hébergeant le serveur Rembo. Le Rembo-Agent permet également d’être indépendant de l’image de base,de la nature du contrôleur de domaine et du système hébergeant le serveur Rembo ET EN PLUS assure la protection du mot de passe...Mais ne marche que sous Rembo 4.
Cette solution n’est pas implémentée dans JeDDLaJ.

Par contre, une fonction JoinDomainOrWorkgroup2 a été écrite pour, si vous le désirez, remplacer la fonction JoinDomainOrWorkgroup dans le source jeddlaj.rbc.
Suivant le type d’affiliation et la version de votre serveur Rembo, les fonctions suivantes seront utilisées :
- domain + Rembo 2 : NTJoinDomain ;
- domain + Rembo 4 : JoinDomain (il sera alors nécessaire d’avoir créé un fichier <NOM_DU_DOMAINE>_settings.rbx pour indiquer les compte et mot de passe d’un utilisateur ayant les droits de joindre NOM_DU_DOMAINE ;
- sambadomain : SmbJoinDomain ;
- workgroup : NTSetWorkgroupName.

Remarque : dans JoinDomainOrWorkgroup2 on distingue donc les contrôleurs de domaines Windows et Samba, désignés respectivement par domain et sambadomain.


Brèves

12 février 2009 - JeDDLaJ passe sur SourceSup à partir de la version 1.6IBE+

La communauté JeDDLaJ manquait jusqu’alors cruellement de certains services et moyens de (...)

12 février 2009 - 11/2/2009 : La version 1.6 IBE+ est disponible !!!

Ça y est. Après tant de mois (18 à peu près...) de gestation, d’hésitations, de :wq et autres (...)

12 février 2009 - JeDDLaJ gagne le concours DEVA => nouvelles fonctionnalités pour vous !!!

JOIE !!! BONHEUR !!! FIERTÉ !!!
JeDDLaJ remporte le concours DEVA (DEVeloppements (...)

9 juillet 2007 - Précision importante sur la compatibilité MySQL 5 de JeDDLaJ 1.4IBE

Dans le cas d’un serveur Rembo sous Windows, 2 moyens pour pouvoir utiliser MySQL 5 :
soit (le (...)

9 juillet 2007 - Déjà le SP1 pour JeDDLaJ 1.4IBE : désormais TPMfOSd-ready !!!

Description
Ce service pack n’apporte principalement qu’une amélioration... mais de taille... (...)