Problème d'activation GPO

Fermé
katanka Messages postés 9 Date d'inscription mardi 17 mars 2015 Statut Membre Dernière intervention 19 mars 2015 - 17 mars 2015 à 10:39
kelux Messages postés 3074 Date d'inscription vendredi 18 juin 2004 Statut Contributeur Dernière intervention 20 janvier 2023 - 19 mars 2015 à 11:25
Bonjour,

Dans un environnement Windows Server 2012 / postes de travail Windows 7, je souhaite mettre en place une GPO sur un certain nombre d'ordinateurs de mon domaine.
J'ai créé une OU spécifique qui contient ces stations et j'ai créé puis lié ma GPO à cette même OU. L'objectif de cette GPO est l'installation sur le poste d'une tache planifiée avec pour résultat l'extinction du PC à heure fixe, quel que soit l'utilisateur connecté.
Dans ma GPO je suis allé dans la section configuration ordinateur/preferences/... pour définir ma tâche planifiée (en mode création) avec comme identifiant d'exécution le compte admin du domaine.

Résultat : la GPO s'exécute sur le poste concerné mais la création de la tâche planifiée est rejetée (Ox80070005 accès refusé).
Je me doute que cela doit être un problème de droits d'accès, j'ai bien essayé d'ajouter le compte admin domaine en administrateur du poste mais cela n'a rien changé.

Merci de votre aide
A voir également:

13 réponses

kelux Messages postés 3074 Date d'inscription vendredi 18 juin 2004 Statut Contributeur Dernière intervention 20 janvier 2023 432
Modifié par kelux le 17/03/2015 à 11:52
Bonjour je ne vais peut etre pas apporté de solution, mais j'ai quelques commentaires.

On n'utilise pas un compte admin du domaine pour faire tourner des taches planifiées, et encore moins sur des stations de travail. (et surement Le compte admin du domaine, je suppose que c'est el compte original, donc celui qui a le plus de droits...)

Vous mettez en péril votre infrastructure, c'est super dangereux :
https://support.microsoft.com/en-us/help/2962486/ms14-025-vulnerability-in-group-policy-preferences-could-allow-elevati

https://www.grouppolicy.biz/2013/11/why-passwords-in-group-policy-preference-are-very-bad/

Avec les GPP vous stockez le mot de passe du compte admin du domaine, dans le sysvol, dans un fichier que tout le monde peut lire, et que tout le monde peut déchiffrer, Microsoft a publié les clefs pour chiffrer et déchiffrer, avec un script en 20 secondes c'est réglé...

Il y a un patch qui permet de désactiver le stockage des mots de passe via les GPP (il n'y a pas que les taches planifiées qui sont affectées), si ce patch a été passé sur le controleur de domaine, il n'est plus possible que le mot de passe soit stocké pour la création de la tache, et ceci pourrait expliquer l'erreur. Vous n'avez pas indiqué comment la tache a été créée via le GPP. (si le mot de passe a bien été enregistré etc ...).

D'autre part la machine pour s'éteindre n'a pas besoin de droits admin du domaine pour le faire...
Ajouter également le compte admin du domaine en tant qu'administrateur local est inutile, car le groupe 'Admins du domaine" est par défaut administrateur local de chaque station/serveur.

-

Dans un de mes posts j'avais déja répondu à cette problématique.

Using a registry "compactor" on top of a registry "cleaner" would be equivalent to rinsing your throat with a swig of Jack Daniels after swallowing a pint of snake oil....
1
kelux Messages postés 3074 Date d'inscription vendredi 18 juin 2004 Statut Contributeur Dernière intervention 20 janvier 2023 432
17 mars 2015 à 11:57
0
katanka Messages postés 9 Date d'inscription mardi 17 mars 2015 Statut Membre Dernière intervention 19 mars 2015
Modifié par katanka le 17/03/2015 à 14:24
Merci beaucoup de ces précisions Kelux, en l'occurrence je pensais que le compte admin était simplement nécessaire à la création de la tâche sur la station et donc ne serait pas stocké.
Je viens de lire votre précédente réponse à une question similaire et je voudrais bien quelques précisions sur la mise en place de la méthode 3, notamment sur le compte à utiliser pour créer la GGP, et le contenu du script de vérification
0
kelux Messages postés 3074 Date d'inscription vendredi 18 juin 2004 Statut Contributeur Dernière intervention 20 janvier 2023 432
Modifié par kelux le 17/03/2015 à 17:02
Avec la méthode 3, on utilise pas de GPP, juste une GPO qui lance un script.
Ce script lance la commande schtasks pour créer la tache planifiée.
La tache planifiée lancera la commande shutdown.

J'ai mis le paramètre /F dans schtasks pour écraser la création même si la tache existe déja. Ca permet d'etre sur que cela sera créé, et aussi si on veut mettre à jour les paramètres de la tache, on est sur d'écraser la tache existante.

On créé une gpo de type "logon script", sur la partie machine. Le script sera donc exécuté à chaque démarrage de la machine.
Dans cette gpo on fait exécuter le script "create_task_shutdown.bat"

Et dans "create_task_shutdown.bat" on y mets ceci :

:: Creation de la tache planifiee ExtinctionAuto
:: Se lance tous les jours a 20 h 30 minutes
:: et execute la commande shutdown /s /t 0 (extinction immediate)
:: le code suivant est sur une seule ligne
schtasks /create /ru system /rl highest /sc DAILY /tn ExtinctionAuto /st 20:30 /F /tr "shutdown /s /t 0"


Il faut ensuite jouer un peu avec la commande schtasks et shutdown en fonction de ce qu'on veut faire.

Les options que j'ai données sont à titre d'exemple.



Using a registry "compactor" on top of a registry "cleaner" would be equivalent to rinsing your throat with a swig of Jack Daniels after swallowing a pint of snake oil....
1
bendrop Messages postés 12601 Date d'inscription jeudi 30 juin 2005 Statut Contributeur Dernière intervention 14 décembre 2024 8 300
17 mars 2015 à 11:19
Bonjour,

vérifie, sur les postes windows 7, les permissions NTFS de ce répertoire
C:\ProgramData\Microsoft\Crypto\RSA. les groupes administrateurs et système doivent être sur contrôle total.

Cordialement.
0
katanka Messages postés 9 Date d'inscription mardi 17 mars 2015 Statut Membre Dernière intervention 19 mars 2015
17 mars 2015 à 11:50
Bonjour,

Oui c'est bien le cas. Peux-tu m'expliquer en quoi cette vérif peut jouer sur l'activation de ma gpo ( pour ma culture personnelle ;) ).

Pour info le compte utilisateur domaine sur le poste concerné n'est pas déclaré dans la partie configuration utilisateurs du panneau de configuration. Est ce que cela a une importance ou pas de le définir à cet endroit ?
0

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
katanka Messages postés 9 Date d'inscription mardi 17 mars 2015 Statut Membre Dernière intervention 19 mars 2015
17 mars 2015 à 16:03
Merci beaucoup de ces précisions Kelux, en l'occurrence je pensais que le compte admin était simplement nécessaire à la création de la tâche sur la station et donc ne serait pas stocké.
Je viens de lire votre précédente réponse à une question similaire et je voudrais bien quelques précisions sur la mise en place de la méthode 3, notamment sur le compte à utiliser pour créer la GGP, et le contenu du script de vérification
0
katanka Messages postés 9 Date d'inscription mardi 17 mars 2015 Statut Membre Dernière intervention 19 mars 2015
17 mars 2015 à 17:25
Merci beaucoup de ces explications détaillées, je ne connaissais pas la commande schtasks.

Je vais regarder cela de plus prêt
0
katanka Messages postés 9 Date d'inscription mardi 17 mars 2015 Statut Membre Dernière intervention 19 mars 2015
18 mars 2015 à 15:10
Bonjour,

Je viens de faire l'essai en suivant vos recommandations.
J'ai donc créé une GPO qui s'applique sur une OU dans laquelle on ne trouve qu'un seul poste de travail.
J'ai créé le fichier .bat qui contient le script et j'ai placé celui-ci dans un sous dossier du dossier sysvol sur l'AD.
Dans la GPO je suis allé dans la section Configuration ordinateur/Stratégies/Paramètres Windows/Script (démarrage/arrêt).
J'ai modifié l'élément démarrage pour lui renseigner le fichier .bat



J'ai ensuite forcé l'application de la Gpo en faisaont clic droit/mettre à jour la stratégie sur l'OU concernée.

J'ai vu apparaître quelques instants plus tard une fenetre msdos sur le poste de travail avec le message d'application de la stratégie.

Par contre, à l'heure d'extinction prévue (13h), rien ne s'est passé ! Aucun message particulier dans les journaux de log windows et pas trace de la tâche quand je lance le planifacteur de tâches.
0
kelux Messages postés 3074 Date d'inscription vendredi 18 juin 2004 Statut Contributeur Dernière intervention 20 janvier 2023 432
Modifié par kelux le 18/03/2015 à 15:28
J'ai ensuite forcé l'application de la Gpo en faisaont clic droit/mettre à jour la stratégie sur l'OU concernée.

Donc ceci ne sert a rien. C'est une mauvaise traduction de l'anglais.
En anglais on a "enforced", en français ça donne "appliqué".
Décochez cette case, elle ne sert pas à "mettre à jour sur l'OU une GPO", d'ailleurs ce n'est pas comme ça que ça se passe, la phrase n'a pas de sens.


J'ai vu apparaître quelques instants plus tard une fenetre msdos sur le poste de travail avec le message d'application de la stratégie.
Aucun lien encore une fois.

-

Cette GPO, même si elle est "vue par le poste", n'aura d'effet que lorsque le poste démarre. C'est durant la phase de démarrage que ce type de Stratégie va avoir son effet.
Je l'ai indiqué dans mes premiers messages :
Le script sera donc exécuté à chaque démarrage de la machine.

Si vous ne démarrez pas la machine vous ne verrez pas l'effet d'un script de démarrage (loginscript) ; disons que le nom est équivoque.

-
Second point, inutile d'attendre 13H, il suffit de voir si la tache est créée .... si la tache est créée, le loginscript a fait son effet.
Et vous validerez que la tache est correcte en l'éditant.
Si vous avez besoin de modifier ou ajuster les paramètres, vous n'avez qu'à modifier le script ;)

Le but est avant tout de bien avoir une tache créée via le loginscript ; après ce n'est que de l'ajustage.


Using a registry "compactor" on top of a registry "cleaner" would be equivalent to rinsing your throat with a swig of Jack Daniels after swallowing a pint of snake oil....
0
katanka Messages postés 9 Date d'inscription mardi 17 mars 2015 Statut Membre Dernière intervention 19 mars 2015
Modifié par katanka le 18/03/2015 à 15:42
Je me suis peut être mal exprimé concernant l'application de la GPO. Quand on se trouve dans l'outil "Gestion de stratégie de groupe", à gauche se trouve la description de la forêt/domaine/OUs/Gpo . Si on clic droit sur une OU, le menu contextuel fait apparaître une option "Mise à jour de la stratégie de groupe...". C'est cette option que j'ai utilisé.

Toujours est-il que la GPO s'applique correctement, mais la tâche ne se créée pas. schtasks /query ne la liste pas. J'ai copié/collé le script sur le poste pour l'exécuter localement, résultat nul sans doute dû aux droits limités de l'utilisateur connnecté. Quand je lance un invite dos en tant qu'admin et que j'exécute la commande, la tâche se créée bien, elle est visible avec schtasks /query, visible dans le planificateur de tâche et s'exécute bien à l'heure dite.

Pour finir, aucune fenêtre dos n'est apparu au démarrage du poste de travail, que ce soit avant ou après l'authentification de l'utilisateur
0
kelux Messages postés 3074 Date d'inscription vendredi 18 juin 2004 Statut Contributeur Dernière intervention 20 janvier 2023 432
Modifié par kelux le 18/03/2015 à 16:40
Les scripts "machines" de startup lancés via GPO se lancent en tant que "local system", donc la tache peut être créée sans problème.

Pour finir, aucune fenêtre dos n'est apparu au démarrage du poste de travail, que ce soit avant ou après l'authentification de l'utilisateur

C'est normal, on ne voit pas les fenetres de startup scripts machine par défaut sur win7.(enfin à vérifier, j'ai un doute qd meme).

Dès que l'on passe l'authentication Utilisateur, la partie machine a fini de s'exécuter, donc on aura jamais les scripts de démarrage machine passé cet instant.

-

Les tests ne sont pas assez précis pour voir où ça foire.

Editez la ligne avec la commande schtask.
et ajoutez à la fin ceci :
schtask .................. >> C:\TEMP\testgpo.txt

Pour voir le résultat ...

Si il n'y a rien ds le fichier, remplacez la ligne complète par un :
echo test >> C:\TEMP\testgpo.txt


On verra au moins si un simple echo fonctionne ...

Si cela ne marche toujours pas, alors c'est que la machine n'arrive pas à exécuter le script-ou bien n'arrive pas à trouver le script dans le Sysvol ...

Using a registry "compactor" on top of a registry "cleaner" would be equivalent to rinsing your throat with a swig of Jack Daniels after swallowing a pint of snake oil....
0
katanka Messages postés 9 Date d'inscription mardi 17 mars 2015 Statut Membre Dernière intervention 19 mars 2015
18 mars 2015 à 17:23
Tout fonctionne !

Je viens de trouver l'origine du problème : le nom de mon fichier script !
Je l'avais nommé script_coupure.bat et apparemment il n'aime pas le '_'.

Sinon la redirection vers le fichier txt a bien fonctionné, sauf au début car je n'avais pas de dossier TEMP à la racine de C:\. Le fichier txt contient " Opération réussie : tâche planifiée créée".

Si j'ai bien compris les explications précédentes, il est préférable d'utiliser cette méthode plutôt que celle avec la GPT, surtout s'il on souhaite revenir en modif sur le contenu de la tâche planifiée.

Je profite de vos compétences pour vous poser 2 autres questions sur des évolutions que je souhaite apporter à mon infra.

1) Existe t-il une méthode permettant de définir des plages horaires de connexions pour mes utilisateurs autrement qu'en se les tapant 1 par 1?

2) Les lecteurs réseaux de nos utilisateurs sont mappés à l'ancienne grâce à des scripts netlogon définis dans chaque fiche utilisateur. Est-il envisageable de les définir un peu comme on vient de le faire avec le script d'extinction programmée ? Si oui, est-ce aussi souple qu'avec l'ancienne méthode ?

En tout cas merci de m'avoir aidé à résoudre ce problème
0
kelux Messages postés 3074 Date d'inscription vendredi 18 juin 2004 Statut Contributeur Dernière intervention 20 janvier 2023 432
18 mars 2015 à 18:44
Pour le "_" c'est étrange, j'utilise très souvent le underscore comme séparateur dans le nom de mes scripts.

-

Pour en revenir à la méthode GPP :
Disons que GPP a un comportement bien particulier, surtout en fonction du contexte.
Dans certains contextes, une fois appliqué, le GPP ne se réappliquera plus, et ce même si on modifie le paramètre, pour pousser une update c'est parfois contraignant. Il faut supprimer le GPP quand ça foire et le refaire.
Il faut revoir le contexte bien entendu, lorsque j'ai dit que la méthode sans GPP était mieux, c'était car la personne avait des Windows XP dans son parc aussi et pas du full windows 7 ou 8...
GPP n'est pas compris de base sur XP.

-

Aujourd'hui c'est préconisé d'utiliser du GPP ceci dit, surtout lorsque l'on a du Windows 7 en poste client.
Attention à l'utilisation de l'option "Apply once and do not reapply", c'est la que ça grince...

J''invite quand même à refaire la meme chose en GPP.
Vous avez demandé à utiliser la méthode sans GPP ... donc j'ai répondu en fonction.

Il y a quelques comparaisons faites ici : https://docs.microsoft.com/en-us/archive/blogs/

La notion de tatooing par exemple... j'enleve mon paramètre, est ce que le paramètre initial est repositionné ? Avec GPP, la réponse est non ....

-
Disons que modifier un script c'est assez facile ... par contre cela a des contraintes aussi : on doit jouer sur le fait que les machines vont l'exécuter au démarrage (ou au shutdown)... et pas "en live".
Du scripting, ça fait un peu "à l'ancienne" aussi ... par contre certains préfère modifier une ligne de code que d'aller cliquer 40 000 trucs.

-

1. Non il faut se taper chaque cvompte, on ne peut pas le faire par groupe. Par contre on peut faire de la multi sélection de users et les configurer d'un coup.
Par contre on peut le scripter en Powershell notamment, mais je n'ai pas le temps de le faire, et je ne l'ai jamais fait auparavant, mais ça doit pas être bien compliqué.

Un monsieur super gentil l'a déja fait en plus :
https://gallery.technet.microsoft.com/scriptcenter/How-to-set-Users-Logon-1bb4b1a2

Attention toutefois, il faut configurer à coté , le "forcage" de déconnexion de la session utilisateur arrivé en dehors de l'heure.

https://www.rebeladmin.com/2014/06/use-of-group-policies-to-control-log-on-hours-to-the-network/

-

2. Euh oui et non.
Ca dépends des écoles aussi, certains préfèrent comme avant d'autre pas...
On peut très bien le faire par GPP le montage des lecteurs réseaux ;-)
Faites le Test avec GPP vous verrez.
0
katanka Messages postés 9 Date d'inscription mardi 17 mars 2015 Statut Membre Dernière intervention 19 mars 2015
Modifié par katanka le 19/03/2015 à 11:06
Bonjour,

Concernant l'underscore c'est pourtant la seule chose que j'ai changé entre 2 tentatives, à moins que ce soit le fait de modifier le contenu du script depuis son dossier de stockage sans repasser par la mise en place faite dans la GPO ...

Pour mes prochaines mises en place, merci pour les informations et les liens communiqués, je découvre powershell et cela va être je pense un excellent cas pratique.

Une dernière question concernant le fonctionnement des GPO. Dans mon cas j'ai créé une GPO changeant des paramètres de la configuration ordinateur. Est ce que cela signifie que, sur l'OU où je vais l'appliquer, son impact ne portera que sur les ordinateurs présents dans cette OU ou aussi sur les utilisateurs présents ?
0
kelux Messages postés 3074 Date d'inscription vendredi 18 juin 2004 Statut Contributeur Dernière intervention 20 janvier 2023 432
Modifié par kelux le 19/03/2015 à 11:30
Est ce que cela signifie que, sur l'OU où je vais l'appliquer, son impact ne portera que sur les ordinateurs présents dans cette OU ou aussi sur les utilisateurs présents ?

En effet, uniquement sur les ordinateurs.

Lorsque l'on configure la partie "ordinateur" d'une GPO, elle affectera uniquement des ordinateurs.( Même réflexion avec la partie "utilisateurs")

On peut ensuiter filtrer l'application de la gpo à une certaine population d'ordinateurs dans cette même OU, avec des groupes.
On peut également utiliser des filtres WMI pour être plus fin, et que les groupes AD ne permettent pas.

Et dernièrement il y a un cas particulier, une exception.
On peut effectivement appliquer des paramètres utilisateurs à des ordinateurs, on utilise la fonctionnalité nommé "boucle de rappel" (loopback processing) - c'est bon à savoir, mais lorsqu'on débute ça complqiue la compréhension.
Il faut garder cette notion en tête lorsque le moment sera venu.

-

Petit bonus : lors du traitement des stratégies de groupe. Si la stratégie contient uniquement des paramètres Ordinateurs (ou utilisateurs), mais pas les deux; il est conseillé de désactiver l'application des paramètres qu'on utilisera pas.

Par exemple, j'ai une GPO avec que des paramètres ordinateurs, je vais désactiver l'application coté utilisateur, ça se configure sur la GPO dans l'onglet "Détails" , sur "GPO status" ; dans cet exemple je mettrai "Désactiver les paramètres de configuration de l'utilisateur".
Ca permet de booster un peu l'application des stratégies, c'est moins long disons.
C'est très parlant sur des très gros environnements ceci dit. Mais ça reste une habitude bonne à prendre.

-

Autre point : il y a RSoP qui permet de vérifier ce qui est appliqué à une machine/utilisateur. C'est très utile pour débugguer lorsque une GPO s'applique mal, où que l'on ne comprends pas ce qu'il se passe.

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc772175(v=ws.11)?redirectedfrom=MSDN

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc736424(v=ws.10)?redirectedfrom=MSDN
0