Je vais vous parler d’une fonctionnalité, que j’utilise beaucoup, sur Windows Server, ( de Server 2000 à 2012), qui est la gestion des stratégies utilisateurs et ordinateurs sur un réseau, aussi appelées GPO : Group Policy Object .
Petite description de l’utilité
Le principe est simple, nous créons des OU (Objects Units), concrètement cela peut être des groupes d’utilisateurs, des groupes de machines, sur un réseau et pouvant êtres distingués par une séparation physique ou de domaine professionnel ( ex : un groupe d’utilisateurs pour les comptables, et un autre pour les programmeurs).
Une fois ces groupes créés, on peut leur appliquer des GPO, qui sont en réalité des règles, dans lesquelles on peut faire énormément de réglages, ( exécution de scripts au démarrage, installation de packages (fichiers .msi) ou de .exe, copie de paramètres système, montage de lecteurs réseaux, configuration avancée de programmes, etc …).
Cela permet dans un réseau de gérer l’automatisation de tâches qui normalement prendraient un certain temps lors de l’intégration d’une nouvelle machine dans le réseau ou de la réinstallation/déploiement de programmes et fonctionnalités.
Les différents choix de stratégie
Il existe deux types de GPO :
- Les GPO Utilisateur : Les règles des ces GPO vont êtres appliquées dès l’identification de l’utilisateur (ouverture de sa session), et nécessite dans certains cas, selon les opérations effectuées, d’être administrateurs de leur machine.
- Les GPO Ordinateur : Ces GPO vont s’appliquer au moment du démarrage de la machine et ne nécessite, par la présente, aucune authentification d’administrateur ( les opérations s’effectuant en compte système).
En plus de cela, on peut définir une GPO avec deux types de déploiement différents :
- Elles peuvent êtres Publiées : Dans ce cas, l’installation d’un programme ne se fera pas automatiquement mais sera directement disponible dans les programmes et fonctionnalités du Panneau de configuration.
- Elles peuvent êtres Attribuées : Ici, les programmes seront installés automatiquement, sans que l’utilisateur le lance manuellement.
- On peut également définir un type de déploiement avancé, mais personnellement je n’ai pas exploré cette option.
Appliquer les GPO
Après la création de celles-ci, on peut les lier à un OU ou plusieurs OU, et ensuite définir quels objets vont êtres concernés. Par exemple, dans mon pôle « Commercial », j’ai deux OU de postes, les « Commerciaux » et les « Administratifs », et je veux appliquer une GPO liée au pôle commercial aux commerciaux, il me suffit dans les attributs de supprimer les Utilisateurs Authentifiés ( qui correspondent à la totalité du groupe « Commercial ») et d’ajouter le groupe « Commerciaux« . Ainsi, le groupe « Administratif » ne se verra pas appliquer les règles.
Si on veut appliquer une GPO à tout le domaine, rien de plus simple, il existe deux groupes qui sont constamment mis à jour, et qui contiennent la totalité des utilisateurs et des machines du domaine. Pour une stratégie utilisateur, on la déploie au groupe « Utilisateurs authentifiés » et pour une stratégie ordinateur, on la déploie au groupe « Ordinateurs du domaine ». Donc soit à tous les utilisateurs, soit toutes les machines.
La structure d’une stratégie
La structure des GPO est découpée en 3 sections, qui sont chacune disponibles soit pour le stratégie côté ordinateur, ou utilisateur :
- Paramètres logiciels (« Software settings ») : C’est ici que l’on définit le package à déployer, où les scripts à exécuter au démarrage ou à l’arrêt de la session/machine
- Paramètres Windows (« Windows settings ») : Dans cette section on définit tout ce qui pourrait être changé dans la panneau de configuration, dans les options diverses de Windows, ce qui va être fait ou non durant les étapes d’ouverture/fermeture de sessions/machines.
- Modèle d’administration (« Administrative templates ») : Ici on va pouvoir faire énormément de choses, notamment des actions réalisables par des scripts, mais plus haut niveau. Par exemple la copie d’un fichier, sa suppression, en fonction de pleins de choses, de valeurs de variables d’environnement, de la taille de la RAM, de la bande passante, … )
Pour ce dernier point, voulant solidifier ma clarté, je vais donner un ou deux exemples simples :
Admettons que je désire installer deux versions logicielles (une à 32 et une à 64 bits) sur les postes de mon réseau en fonction de l’architecture de leur processeur. Il me suffit d’aller modifier ma stratégie, d’aller dans l’arborescence Modèle d’administration > Puis dans Fichiers. Et la on sélectionne, créer depuis notre source jusqu’à la destination voulue, et on peut faire en sorte que le fichier ne se copie qu’une fois. Puis, dans un onglet de cette même fenêtre, on peut définir les conditions/règles pour lesquelles vont s’appliquer cette copie de fichier. Ici on choisit Variable d’environnement et on saisis la suivante : %PROCESSOR_ARCHITECTURE% que l’on compare à « AMD64 » pour des machines 64 bits, ou « x86 » pour des machines 32 bits.
Ou on peut aussi installer une application gourmande en mémoire, seulement pour les postes dont la RAM est supérieure ou égale à 4 Go.
Énormément de possibilité s’offrent à vous avec l’outil puissant qu’est l’Active Directory et sa gestion de stratégie de groupe associée, mais pour ce qui touche au réseau (filtres, limitation de bande passante, …) il est conseillé de laisser cette partie au pare-feu et au proxy de votre réseau.
Je n’ai sur le sujet que certaines connaissances acquises sur le vif, mais j’espère que cette courte présentation vous faits entrevoir le panel de déploiement Windows et ses fonctionnalités ;).
Le débogage d’une GPO
1. Il faut savoir que lorsque l’on met à jour une GPO côté serveur, celle-ci met entre 60 à 90 minutes pour se répliquer sur les clients. Il existe une commande qui permet de forcer la réplication, dans l’invite de commande :
gpupdate /force
Note : Cette commande fonctionne aussi du côté client, pour mettre à jour la stratégie locale.
2. Maintenant, lorsque l’on démarre son poste et qu’on ouvre sa session, et qu’on constate avec désarroi que notre GPO n’a pas fonctionné, le premier réflexe est d’ouvrir une console côté client (à exécuter en administrateur) :
gpresult /r
On regarde alors si la stratégie c’est appliquée, ou non.
On voit ici, par exemple toutes les stratégies appliquées à mon ordinateur.
3. On sait que notre stratégie a été appliquée ? Vérifions maintenant si tout s’exécute correctement, dans notre stratégie. Windows > Executer > rsop.msc (à exécuter en administrateur)
Vous devriez avoir une fenêtre de log, avec une arborescence stratégie utilisateur et ordinateur. Vérifiez dans la bonne catégorie, par exemple dans Configuration utilisateur > Paramètres Windows > Script > Démarrage, que les scripts sensés être exécutés au démarrage l’on étés.
4. Vérifiez que votre GPO est bien « Appliquée » sur votre serveur, et quelle s’applique bien aux bons utilisateurs, groupes ou postes. Il faut savoir que les GPO déployées au niveau utilisateur et machine ne sont pas du même type en fonction de ce qu’on veut déployer. Par exemple, une GPO utilisateur rajoutant une imprimante pourra se faire à la volée, alors qu’une GPO utilisateur ajoutant une clé registre dans la base de registre nécessitera un redémarrage ou une réouverture de session après la mise à jour de la stratégie sur le poste.
