Comme indiqué précédemment, il est possible de bloquer l'héritage pour ne pas recevoir les stratégies de groupe définies sur le parent.
Par défaut, il est aussi possible de redéfinir des stratégies de groupe dans un objet GPO lié à un emplacement enfant pour ne pas recevoir les paramètres configurées sur les emplacements parents.
Maintenant, en admettant que vous faites partie d'un groupe possédant des bureaux dans plusieurs pays, vous voudrez surement éviter qu'un administrateur local (d'un bureau local physique) bloque l'héritage des stratégies de groupe que vous aviez définies sur la racine du domaine Active Directory ou qu'il tente de les masquer en les redéfinissant sur un objet GPO enfant.
Pour cela, il vous suffit d'activer le paramètre "Appliqué" sur le lien vers l'objet GPO que vous avez créé à la racine du domaine ou sur un emplacement parent.
Maintenant que le paramètre "Appliqué" a été activé sur un lien parent, tous les enfants recevront ces stratégies de groupe (même si le blocage d'héritage de stratégie de groupe avait été activé sur un emplacement enfant).
De plus, si vous regardez, l'héritage de stratégie de groupe de votre emplacement enfant, vous verrez que l'ordre d'application des différents objets GPO liés à celui-ci aura changé.
Le lien dont le paramètre "Appliqué" a été activé a maintenant la priorité par rapport à l'objet GPO que vous avez lié à cet emplacement.
L'administrateur de ce bureau local ne peut donc plus bloquer les stratégies de groupe définies par le groupe (supérieur hiérarchique) ni redéfinir les stratégies définies dans celui-ci pour tenter de les masquer, car l'objet appliqué a la priorité par rapport à l'objet lié à l'emplacement enfant.
Si votre administrateur local est un peu malin, il tentera peut-être d'activer aussi le paramètre "Appliqué" sur son lien enfant pour tenter d'être prioritaire à son tour.
Sauf que cela ne fonctionnera pas. A partir du moment où vous forcez l'application d'un objet GPO, l'ordre d'application des différents objets GPO est inversé.
C'est le lien défini sur le parent qui devient prioritaire par rapport aux liens ajoutés sur les emplacements enfants.
Par défaut, lorsque vous liez un objet de stratégie de groupe (GPO) à un emplacement, le filtrage de sécurité défini est : Utilisateurs authentifiés.
Autrement dit, pour résumer, cela concerne tout le monde.
Néanmoins, lorsque vous devez limiter l'accès à certains utilisateurs (pour des raisons de licences logicielles, par exemple), il peut être intéressant de modifier ce filtrage de sécurité.
Par simplicité, nous allons créer un nouveau groupe qui sera obligatoirement de type : Sécurité.
Pour l'exemple, nous allons créer un nouvel objet GPO et le lier à notre unité d'organisation "RH_Computers".
Nous indiquons dans notre cas "MS_Office_Settings" comme nom d'objet GPO.
Pour le moment, le filtrage de sécurité est défini sur "Utilisateurs authentifiés". Ce qui est le paramétrage par défaut.
Cliquez sur : Ajouter.
Indiquez le nom du groupe créé précédemment.
Puis, supprimez le groupe "Utilisateurs authentifiés" de la liste.
Confirmez la suppression de ce privilège de délégation.
Maintenant, les stratégies de groupe définies dans cet objet GPO "MS_Office_Settings" seront appliquées à l'emplacement "RH_Computers" uniquement lorsque ce sera un utilisateur de notre groupe "GestionPaies" qui ouvrira une session.
Pour aller encore plus loin dans le filtrage pour l'application de stratégies de groupe, vous pouvez utiliser des filtres WMI.
Pour créer un filtre WMI, il faut d'abord connaitre ce qu'est le WMI (Windows Management Instrumentation) et de quoi il est composé.
Bien qu'il existe un utilitaire "wbemtest" sur toutes les versions de Windows, nous trouvons que le programme "WMI Code Creator" de Microsoft est beaucoup plus simple à appréhender quand on débute dans le WMI.
ATTENTION : le WMI est accessible en lecture et en écriture et modifier les données dans cette couche WMI sans savoir ce que vous faites peut endommager physiquement votre ordinateur.
Nous vous recommandons donc de n'effectuer que des requêtes "SELECT" (donc une lecture) sur la couche WMI et non des modifications sur celle-ci.
Pour que le programme "WMI Code Creator" puisse fonctionner, il faut que vous installiez le ".Net Framework 3.5" sur l'ordinateur ou le serveur où vous voulez le lancer.
En sachant que vous devez évidemment lancer ce programme sur l'ordinateur à cibler pour obtenir les informations qui vous permettront de le cibler lui et pas un autre.
Pour installer le ".Net Framework 3.5" sur les versions clientes de Windows, vous devez activer la fonctionnalité correspondante : .Net Framework 3.5...
Sur les versions serveur de Windows, vous devrez ouvrir l'assistant d'ajout de rôles et de fonctionnalités et activer la fonctionnalité "Fonctionnalités de .Net Framework 3.5 -> .NET Framework 3.5 (inclut .NET 2.0 et 3.0)".
Pour la procédure détaillée, référez-vous à notre tutoriel : Installer .Net Framework 2.0, 3.0 et 3.5 sous Windows Server
Une fois le .NET Framework 3.5 installé, vous pourrez lancer le programme "WMI Code Creator".
Patientez pendant le chargement des classes WMI.
L'espace de noms (namespace) que vous utiliserez le plus sera : root\CIMV2.
Dans cet espace de noms "root\CIMV2", vous trouverez de nombreuses classes et notamment la classe : Win32_OperatingSystem.
En sélectionnant cette classe WMI "Win32_OperatingSystem", la liste de ses propriétés s'affichera.
Si nous sélectionnons la propriété "Version", on s'aperçoit que la version de notre PC client est : 10.0.19041.
En nous renseignant sur la documentation officielle de Microsoft, nous avons ensuite trouvé cet article : Créer des filtres WMI pour l’objet de stratégie de groupe (GPO).
Dans cet article, Microsoft vous explique comment cible une version spécifique de Windows en utilisant justement cette classe WMI "Win32_OperatingSystem" et ses propriétés : ProductType et Version.
Bien que le programme "WMI Code Creator" est intéressant pour trouver les informations souhaitées, le programme "wbemtest" est aussi utile, car il permet d'exécuter une requête WMI et donc de tester si celle-ci est correcte et si elle retourne bien le résultat souhaité.
Sachant que le filtre WMI dans Active Directory fonctionne sur une base de vrai ou faux. Si la requête WMI renvoi un résultat positif, les stratégies de groupe concernées seront appliquées, sinon pas.
Bref, lancez le programme "wbemtest" intégré dans toutes les versions de Windows et de Windows Server et cliquez sur le bouton "Connexion".
Ne changez rien dans cette fenêtre et cliquez simplement sur : Connexion.
Note : comme vous pouvez le voir, cet utilitaire se connecte par défaut sur l'espace de noms : root\CIMV2.
Conformément à la documentation officielle de Microsoft (citée précédemment), nous pouvons cibler les PCs clients sous Windows 10 grâce à la requête WMI :
SQL
SELECT * FROM Win32_OperatingSystem WHERE Version LIKE "10.%" AND ProductType="1"
Notez que le format des requêtes WMI est : WQL. C'est pour cette raison que le format WQL ressemble beaucoup aux requêtes SQL utilisées avec les serveurs de bases de données : Microsoft SQL Server, MySQL, ...
Pour tester cette requête, cliquez sur le bouton "Requête ...", collez la requête WMI et cliquez sur "Appliquer".
Si la requête retourne un résultat (un objet), c'est que votre requête est bonne et Active Directory considérera donc que le résultat est : vrai.
Faites un double clic sur le résultat affiché.
L'éditeur d'objets apparait avec de nombreuses informations.
Ne modifiez rien ici, mais vous pouvez voir qu'il a bien trouvé notre ordinateur donc le nom NETBIOS est : WIN10.
Et que la version de Windows installée sur notre ordinateur est : 10.0.19041.
Ce qui commence bien par "10." comme indiqué dans notre requête WMI.
Si vous affichez les propriétés système de Windows, vous retrouvez le nom NETBIOS de votre ordinateur.
Et vous pouvez connaitre sa version en lançant le programme "winver.exe" disponible sur toutes les versions de Windows.
Notez que la version disponible via la couche WMI est celle indiquée entre parenthèses (19041) et non le "nom" public de cette version (2004).
Maintenant que nous avons trouvé la requête WMI permettant de cibler ce que l'on voulait (dans notre cas : les PCs clients sous Windows 10), il suffit de créer un nouveau filtre WMI dans notre infrastructure Active Directory.
Pour cela, sélectionnez le dossier "Filtres WMI" et faites un clic droit "Nouveau" dans la liste de droite.
Indiquez un nom et une description pour ce filtre WMI et cliquez sur le bouton "Ajouter" pour ajouter une requête WMI pour celui-ci.
Comme indiqué précédemment, l'espace de noms utilisé sera : root\CIMv2.
Collez la requête WMI créée précédemment et cliquez sur OK.
La requête a été ajoutée.
Important : comme vous pouvez le voir, aucune vérification n'a été effectuée pour savoir si cette requête était valide ou non. D'où l'utilité de la tester d'abord sur via "wbemtest" pour vous assurer que votre requête WMI est correcte.
Notre filtre WMI a été créé.
Si vous le sélectionnez à gauche ou que vous faites un double clic sur celui-ci, vous retrouverez :
Dans notre cas, nous allons choisir le lien vers l'objet GPO "MS_Office_Settings" et sélectionner notre filtre WMI "Win10_Clients" dans la section "Filtrage WMI".
Confirmez le changement du filtre WMI.
Maintenant, les stratégies de groupe de notre objet GPO "MS_Office_Settings" seront appliquées uniquement :
Windows Server 16/4/2021
Windows Server 3/4/2021
Windows Server 30/4/2021
Windows Server 21/5/2021
Contenu épinglé
Contact
® InformatiWeb-Pro.net - InformatiWeb.net 2008-2022 - © Lionel Eppe - Tous droits réservés.
Toute reproduction totale ou partielle de ce site est interdite et constituerait une contrefaçon sanctionnée par les articles L.335-2 et suivants du Code de la propriété intellectuelle.
Pas de commentaire