Il s’agit d’une Question canonique sur les bases des stratégies de groupe Active Directory.
Qu’est-ce que les stratégies de groupe ? Comment fonctionnent-elles et pourquoi devrais-je les utiliser ?
Remarque : il s’agit d’une question-réponse destinée aux nouveaux administrateurs qui ne connaissent pas forcément leur fonctionnement et leur puissance.
Source : Server Fault
Les stratégies de groupe sont un outil disponible pour les administrateurs qui gèrent un domaine Active Directory sous Windows 2000 ou version ultérieure. Elles permettent la gestion centralisée des paramètres sur les ordinateurs clients et les serveurs joints au domaine, ainsi qu’un moyen rudimentaire de distribuer des logiciels.
Les paramètres sont regroupés dans des objets appelés objets de stratégie de groupe (GPO). Les GPO sont liés à une unité organisationnelle (OU) Active Directory et peuvent être appliqués aux utilisateurs et aux ordinateurs. Les GPO ne peuvent pas être appliqués directement aux groupes, mais vous pouvez utiliser le filtrage de sécurité ou le ciblage au niveau des éléments pour filtrer l’application des stratégies en fonction de l’appartenance à un groupe.
Tout.
Sérieusement, vous pouvez faire tout ce que vous voulez aux utilisateurs ou aux ordinateurs de votre domaine. Il existe des centaines de paramètres prédéfinis pour la redirection de dossiers, la complexité des mots de passe, les paramètres d’alimentation, le mappage de lecteurs, le chiffrement de disques, Windows Update, etc. Tout ce que vous ne pouvez pas configurer via un paramètre prédéfini peut être contrôlé par des scripts. Les scripts Batch et VBScript sont pris en charge sur tous les clients supportés, et les scripts PowerShell peuvent être exécutés sur les hôtes Windows 7.
Conseil professionnel : Vous pouvez en fait exécuter des scripts de démarrage PowerShell sur les hôtes Windows XP et Windows Vista à condition qu’ils aient PowerShell 2.0 installé. Vous pouvez créer un fichier batch qui appelle le script avec cette syntaxe :
powershell Set-ExecutionPolicy RemoteSigned
powershell \\\\server\share\script.ps1
powershell Set-ExecutionPolicy Restricted
La première ligne permet l’exécution de scripts non signés provenant de partages distants sur cet hôte et la deuxième ligne appelle le script depuis le fichier batch. La troisième ligne remet la stratégie à « restricted » (la valeur par défaut) pour une sécurité maximale.
Les GPO sont appliqués dans un ordre prévisible. Les stratégies locales sont appliquées en premier. Ce sont les stratégies définies sur la machine locale via gpedit.msc. Les stratégies de site sont appliquées en deuxième. Les stratégies de domaine sont appliquées en troisième, et les stratégies d’OU sont appliquées en quatrième. Si un objet est imbriqué dans plusieurs OU, les GPO sont appliqués aux OU les plus proches de la racine en premier.
Gardez à l’esprit qu’en cas de conflit, le dernier GPO appliqué « gagne ». Cela signifie, par exemple, que la stratégie liée à l’OU dans laquelle se trouve un ordinateur l’emportera en cas de conflit entre un paramètre de cette GPO et un paramètre lié dans une OU parente.
Un script d’ouverture de session ou de démarrage peut résider sur n’importe quel partage réseau tant que les groupes Utilisateurs du domaine et Ordinateurs du domaine ont un accès en lecture au partage. Traditionnellement, ils résident dans \\domain.tld\sysvol, mais ce n’est pas une obligation.
Les scripts de démarrage sont exécutés au démarrage de l’ordinateur. Ils s’exécutent en tant que compte SYSTEM sur la machine locale. Cela signifie qu’ils accèdent aux ressources réseau en tant que compte de l’ordinateur. Par exemple, si vous vouliez qu’un script de démarrage ait accès à une ressource réseau sur un partage ayant le chemin UNC \\server01\share1 et que le nom de l’ordinateur était WORKSTATION01, vous devriez vous assurer que WORKSTATION01$ a accès à ce partage. Puisque ce script s’exécute en tant que SYSTEM, il peut installer des logiciels, modifier des sections privilégiées du registre et modifier la plupart des fichiers sur la machine locale.
Les scripts d’ouverture de session s’exécutent dans le contexte de sécurité de l’utilisateur connecté localement. En espérant que vos utilisateurs ne sont pas administrateurs, cela signifie que vous ne pourrez pas les utiliser pour installer des logiciels ou modifier des paramètres de registre protégés.
Les scripts d’ouverture de session et de démarrage étaient un pilier des domaines Windows 2003 et antérieurs, mais leur utilité a diminué dans les versions ultérieures de Windows Server. Les préférences de stratégie de groupe offrent aux administrateurs un bien meilleur moyen de gérer les mappages de lecteurs et d’imprimantes, les raccourcis, les fichiers, les entrées de registre, l’appartenance aux groupes locaux et bien d’autres choses qui ne pouvaient être faites que dans un script de démarrage ou d’ouverture de session. Si vous pensez avoir besoin d’un script pour une tâche simple, il existe probablement une stratégie de groupe ou une préférence pour cela. De nos jours, sur les domaines avec des clients Windows 7 (ou ultérieur), seules les tâches complexes nécessitent des scripts de démarrage ou d’ouverture de session.
Oui, je comprends. J’y suis passé aussi. C’est particulièrement courant dans les laboratoires académiques ou d’autres scénarios d’ordinateurs partagés où vous souhaitez que certaines stratégies utilisateur pour les imprimantes ou ressources similaires soient basées sur l’ordinateur, pas sur l’utilisateur. Devinez quoi, vous avez de la chance ! Vous devez activer le paramètre GPO pour le Mode de bouclage de stratégie de groupe.
De rien.
Oui, c’est possible. Il y a cependant quelques mises en garde. Le logiciel doit être au format MSI, et toute modification doit être dans un fichier MST. Vous pouvez créer un MST avec un logiciel comme ORCA ou tout autre éditeur MSI. Si vous ne créez pas de transformation, le résultat final sera le même que l’exécution de msiexec /i <chemin vers le logiciel> /q
Le logiciel n’est installé qu’au démarrage, ce n’est donc pas un moyen très rapide de distribuer des logiciels, mais c’est gratuit. Dans un environnement de laboratoire à petit budget, j’ai créé une tâche planifiée (via GPO) qui redémarre chaque ordinateur de laboratoire à minuit avec un décalage aléatoire de 30 minutes. Cela garantit que les logiciels sont, au maximum, en retard d’un jour dans ces laboratoires. Néanmoins, un logiciel comme SCCM, LANDesk, Altaris, ou tout autre outil capable de « pousser » des logiciels à la demande est préférable.
Les clients actualisent leurs objets de stratégie de groupe toutes les 90 minutes avec une randomisation de 30 minutes. Cela signifie que, par défaut, il peut y avoir jusqu’à 120 minutes d’attente. De plus, certains paramètres, comme les mappages de lecteurs, la redirection de dossiers et les préférences de fichiers, ne sont appliqués qu’au démarrage ou à l’ouverture de session. Les stratégies de groupe sont conçues pour une gestion planifiée à long terme, pas pour des corrections instantanées.
Les contrôleurs de domaine actualisent leur stratégie toutes les cinq minutes.