Scripts d'ouverture de session Windows

Chaque fois qu'un utilisateur s'identifie avec succès sur un poste Windows, un script est exécuté avant de lui donner la main sur l'environnement. Ce script :

• accroche des lecteurs réseaux à son poste de travail
• Mappe “Mes Documents” vers son répertoire maison Linux pour qu'il retrouve ses documents et ses répertoires partagés de groupes
• met sa machine à l'heure par rapport au serveur
• fusionne des fichiers de registres pour restreindre (ou étendre) ses permissions sur la machine locale.

Ce script peut être entièrement personnalisé :

• pour la version de Windows installée sur le poste,
• pour le poste (en fonction du nom du poste),
• pour tous les enseignants ou pour tous les élèves,
• pour un groupe donné,
• pour un utilisateur donné.

En pratique, ce script est généré à partir d'une série de modèles (templates), découpés en fonction des paramètres pré-cités (utilisateur, groupe, OS, poste…). Au moment où l'utilisateur s'identifie, le système récupère son groupe, le nom de son poste, la version de Windows de son poste, va piocher dans les modèles correspondants pour assembler un script en fonction de tous ces paramètres, et donne ce script assemblé à la station Windows qui l'exécute alors.

Sur le serveur AbulÉdu, les modèles sont dans /home/netlogon/templates. Les scripts générés sont dans /home/netlogon. Attention : tout les scripts présents dans /home/netlogon sont automatiquement régénérés / écrasés à chaque ouverture de session sur un poste donné. Toutes les modifications que vous y ferez seront donc perdues.

Vous devez apporter des modifications uniquement dans le répertoire /home/netlogon/templates, dans lequel vous trouverez :

• commun.bat : modèle de script utilisé quelque soit l'utilisateur, le poste, la version de l'OS, etc.
• enseignants.bat / responsables.bat : contient les spécificités des utilisateurs enseignants ou responsables.
• eleves.bat / usagers.bat : idem pour les élèves ou usagers.
• demar???.bat : ou ??? est un numéro de version abbrégé de Windows. Le script qui correspond à la version de Windows du poste sera ajouté au script final.
• d'autres scripts qui n'existent pas encore mais que vous pouvez créer :
  • par poste : par exemple si vous avez un poste qui s'appelle ordi1, s'il existe un script ordi1.bat, les commandes de ce script seront exécutées sur le poste ordi1 quelque soit l'utilisateur qui s'y identifie (utile pour les postes maîtres des salles informatiques par exemple).
  • par utilisateur : pour utilisateur dont l'identifiant est jean.dupont, s'il existe un fichier jean.dupont.bat, les commandes de ce script seront exécutées [uniquement] pour lui, quelque soit le poste sur lequel il s'identifie.

Les priorités des scripts sont celles citées ci-avant, c'est à dire que les script “modèles” seront ajoutés et exécutés dans l'ordre suivant :

• commun
• version OS
• machine
• groupe primaire (enseignant / eleve)
• groupes secondaires par ordre numérique (GID)
• identifiant utilisateur

Donc par exemple : si vous appliquez des restrictions spécifiques dans machine.bat et login_utilisateur.bat, et que ces restrictions modifient toutes les deux les mêmes propriétés du registre Windows, ce sont celles de login_utilisateur.bat qui prévalent car elles seront exécutées en dernier. Il est donc possible d'écraser ou de “défaire” une directive du commun.bat pour un certain groupe ou un certain utilisateur car les deux scripts modèles du groupe et de l'utilisateur seront exécutés après le commun.bat.

Ceci est valable pour une clé de registre, un fichier ou un lecteur réseau. En revanche, si vous tentez d'accrocher des lecteurs réseaux à la même lettre de lecteur dans le poste de travail, Windows vous indiquera une erreur et arrêtera temporairement le déroulement du script. prenez donc garde à utiliser des lettres de lecteurs réseau différentes d'un script à l'autre.

Évidemment, comme un utilisateur “responsable” n'est pas “administrateur” (il est toujours ou l'un, ou l'autre, mais pas les deux, de même qu'un élève n'est pas enseignant et vice-versa), vous pouvez utiliser des lettres de lecteurs identiques pour ces scripts là. Ceci n'est pas valable pour les groupes supplémentaire (journal, football, ce2, 4e3, etc) car un utilisateur peut faire partie de plusieurs de ces groupes en même temps. Donc cette considération est à prendre en compte en fonction des spécificités de votre installation.

Dans /home/netlogon/templates, tous les scripts existant à l'installation de votre serveur sont fournis « d'usine » par des paquets. Si vous les modifiez ils seront donc écrasés lors de la mise à jour du paquet, ce qui n'est certainement pas ce que vous voulez. Pour éviter cela, il suffit de rajouter “-local” dans le nom de votre script. Donc les scripts que vous créerez vont s'appeler :

• commun-local.bat si vous souhaitez personnaliser le modèle commun,
• demarWinXP-local.bat si vous souhaitez personnaliser le modèle exécuté pour tous les postes XP Pro,
• journal-local.bat si vous souhaitez ajouter des actions spécifiques pour les membres du groupe journal.
• jean.dupont-local.bat si vous souhaitez ajouter des actions spécifiques pour l'utilisateurs jean.dupont.
• etc.

Pourquoi “-local” est-il nécessaire même quand il s'agit de vos groupes ou utilisateurs ?

Parce que nous nous réservons la possibilité de fournir un jour des scripts spécifiques à des comptes utilisateurs d'usine (comme abuladmin) ou à des groupes d'usine (comme webmestres), et que ce jour là nos scripts packagés écraseraient les votres s'ils ne portaient pas le suffixe “-local”. Donc même si un script d'usine donné n'existe pas, prennez toujours la bonne habitude de rajouter “-local” dans le nom de votre script, vous éviterez d'éventuelles mauvaises surprises.