Comment bombarder à temps un GPO?


22

Je fais beaucoup de travail dans l'enseignement supérieur où il est assez courant de reconfigurer un certain nombre de membres de domaine Windows (par exemple des PC dans une salle de classe) pour la durée d'un cours ou d'un événement spécifique et de faire annuler cette configuration par la suite.

Étant donné que la plupart des modifications de configuration qui nous sont demandées peuvent être effectuées via des objets de stratégie de groupe et que ces modifications sont automatiquement annulées lorsque l'objet de stratégie de groupe est dissocié ou désactivé au niveau de l'unité d'organisation, il s'agit d'une route très confortable à prendre.

Le seul inconvénient est que la liaison et la dissociation manuelle répétées des objets de stratégie de groupe sur les unités d'organisation nécessitent de nombreux rappels et le personnel informatique en service avant le début et après la fin des cours - ce que l'équipe des opérations ne peut pas garantir à tout moment.

Existe-t-il un moyen de spécifier un délai pour la validité d'un GPO spécifique?

Réponses:


32

Cela peut être fait au moyen du filtrage WMI . Le client de stratégie de groupe exécuterait la requête WQL à partir d'un filtre WMI attaché et n'appliquerait le GPO que si la requête renvoyait un nombre non nul de lignes. Ainsi, en créant un filtre WMI en vérifiant si l'heure actuelle du système est dans un intervalle de temps donné et en reliant ce filtre WMI au GPO que vous souhaitez bombarder, vous obtenez exactement ce que vous vouliez.

La classe WMI win32_operatingsystem a un attribut localdatetime qui peut être comparé à une date de chaîne donnée au format 'aaaammjj hh: nn: ss', donc en utilisant la chaîne WQL comme

select * from win32_operatingsystem where localdatetime >= '20150220 00:00:00' and localdatetime <= '20150223 15:00:00'

dans l' root\CIMv2espace de noms garantirait que le GPO uniquement serait appliqué aux systèmes où l'heure locale est comprise entre le 20 février 2015 00:00:00 et le 23 février 2015 15:00:00:

configurer le filtre WMI avec une chaîne WQL

Assurez-vous que vous avez lié le filtre WMI au GPO souhaité:

lier le filtre WMI au GPO

À retenir:

  • le WQL évalue la date et l'heure locales sur le client, qui peuvent ou non être synchronisées avec la source de temps que vous souhaitez utiliser. Le temps du client ne sera pas trop avancé ou en retard par rapport au temps du contrôleur de domaine, sinon l'authentification Kerberos se cassera, mais il pourrait y avoir des écarts mineurs, tenez-en compte
  • le client de stratégie de groupe vérifiera les modifications de GPO et les réappliquera plutôt rarement par défaut:

    Par défaut, la stratégie de groupe de l'ordinateur est mise à jour en arrière-plan toutes les 90 minutes, avec un décalage aléatoire de 0 à 30 minutes.

    Ainsi, les paramètres par défaut ne permettront qu'une précision de +2 heures. L'intervalle de mise à jour peut être modifié par (un autre) paramètre de stratégie de groupe, si nécessaire.

  • votre stratégie doit pouvoir annuler toutes les modifications lorsqu'elle n'est plus appliquée. C'est le cas par défaut pour tous les modèles d'administration gérés. Il peut être nécessaire de définir explicitement les paramètres des préférences de stratégie de groupe pour "supprimer cet élément lorsqu'il n'est plus appliqué" : Onglet commun GPP


3
Très intelligent, bravo à vous.
Massimo

3
D'après mon expérience, il existe des politiques dans les modèles d'administration qui ne reviennent pas sur les modifications qu'elles ont apportées, alors il vaut mieux faire des tests d'abord ... Aussi, ce que Massimo a dit ...
EliadTech

D'accord, tous les paramètres qui donnent droit au registre ne reviennent pas simplement à leurs valeurs par défaut lorsqu'ils ne sont pas liés, ou même définis sur "Non configuré"
mortenya

Ajoutez une tâche planifiée pour déclencher une GPupdate aux heures de début et de fin et vous pourriez éventuellement (?) Obtenir un peu plus de précision sans avoir à modifier l'intervalle de mise à jour?
Get-HomeByFiveOClock

2
@mortenya, la partie "gérée" des modèles d'administration s'assure que les paramètres sont réellement définis dans un autre sous-arbre de la ruche du registre - par exemple HKLM\Software\Policiesou HKCU\Software\Policies. Ces emplacements de "stratégie" sont effacés si l'objet de stratégie définissant la clé ne s'applique plus ou si la propriété est définie sur "Non configuré". Pour les modèles ADM à l'ancienne écriture dans le registre, vous avez raison, ceux-ci sont "tatoués" dans le registre du client et ne sont pas supprimés par la suite. Connexe: serverfault.com/questions/566180
the-wabbit
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.