Bonjour
Objectif :
Déterminer comment s’applique les stratégies de groupe sur une machine Windows XP / Windows 7.
Scénario 1 :
Se connecter sur un contrôleur de domaine (Windows 2008 R2 dans l’exemple).
Créer une OU appelée Msreport-Computers. Joindre une machine Windows 7 appelée Melanie-computers dans le domaine et déplacer le compte ordinateur de cette machine dans cette OU.
Créer la GPO Msreport-Computers. Aller dans Computer configuration | Policies | Windows Settings | Security Settings | Windows Firewall with advanced Security. Configurer la GPO pour activer le pare feu sur les 3 profils. Bloquer les connexions entrantes et autoriser les connexions sortantes (paramètres par défaut).
Sur la machine Melanie-Computers, lancer cmd.exe puis entrer la commande gpupdate /force.
Aller dans le Control Pannel | cliquer sur View by Small icons. Cliquer sur Administrative Tools | Windows firewall with advanced settings. La console se lance et affiche que le pare feu est configuré à l’aide des stratégies de groupe.
Maintenant qu’on a reproduit l’environnement, on va essayer de supprimer cette GPO depuis la base de registre de la machine Melanie-Computers
Editer l’entrée de registre EnableFirewall (REG_DWORD) et lui définir comme valeur 0 (au lieu de la valeur 1) au niveau de la clé HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsFirewall\Domain Profile.
Le pare feu est maintenant désactivé.
Redémarrer ensuite la machine ou relancer le service Windows Firewall.
Aller dans le Control Pannel | cliquer sur View by Small icons. Cliquer sur Administrative Tools | Windows firewall with advanced settings. La console se lance et affiche que le pare feu est configuré à l’aide des stratégies de groupe.
Si on entre la commande gpupdate /force de nouveau, les anciens paramètres de la GPO s’appliquent de nouveau. Le pare feu sera actif de nouveau.
Editer de nouveau l’entrée de registre EnableFirewall (REG_DWORD) et lui définir comme valeur 0 au niveau de la clé HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsFirewall\Domain Profile. Le pare feu est maintenant désactivé.
Aller dans les propriétés (onglet Sécurité) de la clé HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsFirewall.
Cliquer sur Advanced . Sélectionner le compte System et cliquer sur Edit.
Interdire les droits suivants pour ce compte:
– Set Value
– Create subkeys
– Delete
– Write owner
– Read control.
Lorsque l’on fait un gpupdate /force on a maintenant un message d’erreur qui indique que l’application des stratégies de groupe a échoué : The processing of Group Policy failed because of an internal system error
Tous les paramètres du pare feu dans HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsFirewall sont supprimés. C’est en effet le compte SYSTEM qui applique les GPO de type Configuration Ordinateur.
Le service Windows Firewall n’est pas impacté car il s’exécute avec le compte Local service et non le compte SYSTEM.
Il ne faut pas interdire contrôle totale (inclue lecture) au compte SYSTEM sur les clés de registre. Cela pourrait bloquer le démarrage de certains services qui utilise le compte SYSTEM pour exécuter le service !
On constate que le pare feu continue à fonctionner et que l’on peut le configurer manuellement via la console Windows Firewall with Advanced Features. Cela est du au fait que le pare feu dispose de ses propres fichiers / entrées de registre de configuration.
Les valeurs de registre dans HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsFirewall sont la manière de configurer le pare feu via les GPO. Cette configuration est prioritaire sur la configuration standard du pare feu (via la console).
Explication :
En fait les GPO modifie pas en règle générale directement la configuration des applications.
Elles utilisent toujours un second emplacement de configuration prioritaire par rapport à la configuration standard (manuelle) de l’application. Les principaux emplacements de configuration via les stratégies de groupes se trouvent dans :
HKEY_LOCAL_MACHINE\SOFTWARE\Policies
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\ CurrentVersion\Policies
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy
HKEY_CURRENT_USER\SOFTWARE\Policies
On notera aussi que pour faire ce changement je dois être administrateur local de la machine. La morale est donc que lorsqu’on est administrateur local, on peut toujours arriver à outrepasser les GPO.
Pour plus d’informations :
http://support.microsoft.com/kb/201453/en-us
http://technet.microsoft.com/en-us/library/cc786941(v=ws.10).aspx
Scénario 2 :
Créer une OU appelée Msreport-Users. Créer un compte utilisateur appelé melanie.mathieu.
Créer un objet de GPO appelé Msreport-Users et le lier à l’OU Msreport-users.
Editer la GPO et définir le paramètre Prohibit access to the Control Pannel dans User Configuration | Administrative Tools | Control Panel. Mettre cette GPO à la valeur Enabled.
Cela crée l’entrée de registre NoControlPanel (REG_DWORD) à la valeur 1 dans HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer.
Au niveau des droits d’accès sur cette clé Explorer, on remarquera que le compte melanie.mathieu ne dispose que du droit de lire (le compte system et le groupe administrateurs disposent du contrôle totale) et que le compte SYSTEM est propriétaire de l’entrée. Il faut donc être administrateur de la machine pour modifier cette clé et bloquer l’application de cette GPO à l’aide de la solution vue dans le scénario 1.
Problème d’application des GPO :
Parfois l’erreur suivant apparaît sur des machines Windows (exemple avec Windows XP) :
Type de l’événement : Erreur
Source de l’événement : Userenv
Catégorie de l’événement : Aucun
ID de l’événement : 1047
Date : 11/09/2013
Heure : 11:38:40
Utilisateur : AUTORITE NT\SYSTEM
Ordinateur : MSREPORTO05
Description :
Windows ne peut pas lire l’historique des objets de paramètre de groupe à partir du Registre. Le traitement de la stratégie de groupe continue.
Pour plus d’informations, consultez le centre Aide et support à l’adresse http://go.microsoft.com/fwlink/events.asp.
Ces justement lié au cache des GPO qui s’applique mal.
Il faut alors supprimer ce cache comme vu précédemment.
Ce problème se produit si on a déployé des stations de travail à partir d’un modèle qui n’était pas en groupe de travail ou qui avait encore des restes du cache des stratégies de groupe (machine intégrée dans le domaine puis repassée en groupe de travail pour la capture de l’image).
A+
Guillaume MATHIEU
Consultant Proservia
La connaissance s’accroît quand on la partage.
http://msreport.free.fr
