Scripts d'ouverture de session Windows [La documentation d'AbulÉdu]

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
{{tag>version-8-08}}====== Scripts d'ouverture de session Windows ======

===== Principe de fonctionnement =====

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.

==== Modèles de scripts ====

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.

==== Modification des modèles de scripts ====

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.

<note important>
Les scripts locaux (dont le nom se termine par'**-local.bat**') ont **toujours** priorité sur les scripts d'usine. Si un script local existe, le script d'usine correspondant **ne sera pas** exécuté du tout. Veillez donc à conserver ce qui vous intéresse du script d'usine dans votre script local, et de le tenir à jour lors des mises à jour du paquet ''samba''.
</note>

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.