none
GPO Default Domain Policy RRS feed

 > 

  • Discussion générale

  • Discussion
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour, j'essaie de mettre en place un script qui ne fonctionne pas quand le pc sur lequel j'essaie de l'exécuter se trouve dans une unité d'organisation qui bénéficie de l'héritage. Après plusieurs heures de recherche je me rend compte que c'est à cause de la GPO Default Domain Policy et je ne sais pas quoi configurer pour pouvoir passer mon script.

    Le but du script est de créer un compte admin local sur un poste.

    @echo OFF
 
set AccountUsername=Test
set AccountPassword=MloTbdf20#!
 
net user %AccountUsername% %password% /add
net localgroup administrateurs "%computername%\%AccountUsername%" /add
 
exit

    Le script fonctionne parfaitement lorsque qu'il est utilisé sur un poste dans une unité d'organisation qui ne bénéficie pas de l'héritage donc pas de Default Domain Policy. Entre autre le problème se trouve dans cette GPO. 

    Concernant la stratégie de mot de passe, rien n'est appliqué. ans ma GPO tout est par défaut, même la complexité.

    Et concernant le groupe qui n'existe pas, je ne comprends pas car le script mentionne bien localgroup et je rappelle qu'il fonctionne sans problème lorsque cette GPO n'est pas appliquée.

    Quelle règle dois-je activer pour que cela fonctionne ?

    Merci d'avance pour votre aide.

    mardi 29 septembre 2020 14:55
    |

Toutes les réponses

  • Discussion
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Salut, défaut domaine policy ne bloque pas ton script, ca n'a rien avoir.

    Envoies nous le résultat de gpresult /z

    Si tu veux créer des utilisateurs locaux, fait le par gpo simplement pas par script

    Dakhama Mehdi : Windows developper https://github.com/dakhama-mehdi

    mardi 29 septembre 2020 16:13
    |
  • Discussion
    Connectez-vous pour voter
    0
    Connectez-vous pour voter
    Salut merci pour ta réponse,
    Je trouve ça étrange que ça n'ai rien à voir car le seul héritage de la racine c'est la GPO Default Domain Policy, lorsque je retire cette GPO de l'OU tout refonctionne...
    J'obtiens 
    PS C:\Windows\system32> gpresult /z
    Information : L’utilisateur « HOMEBOX0\GLOBAL » n’a pas de données RSOP.
    PS C:\Windows\system32>
    mercredi 30 septembre 2020 07:38
    |
  • Discussion
    Connectez-vous pour voter
    0
    Connectez-vous pour voter
    Bonjour Tomioka952,

    Si vous avez trouvé une solution à votre problème, merci de la partager avec la communauté TechNet.

    Je vous remercie par avance pour votre retour.

    Cordialement, 
    Nedeltcho

    Votez! Appel à la contribution TechNet Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votre problème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution.

    lundi 2 novembre 2020 13:36
    |
  • Discussion
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Est ce que tu as modifié quelques chose dans la gpo defaut domaine policy ? Car si le cas effectivement cela peut bloquer.

    Moi je parlais en partant d'aucune modifications

    Est tu dans un environnement de test ? Pour voir les commandes à te proposé 

    Dakhama Mehdi : Windows developper https://github.com/dakhama-mehdi

    lundi 2 novembre 2020 13:53
    |
  • Discussion
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour Tomioka952

    Visiblement il y a des bases sur la gestion des GPOs qui manquent.

    • La GPO "Default Domain Policy" ne défini par défaut que la stratégie de mot de passe. Ne jamais la modifier et créer une (ou des) autre stratégie pour modifer/compléter cette GPO, en jouant sur l'ordre de priorité. La nouvelle GPO devant alors être prioritaire.
    • Il y a un ordre d'application des GPO. Du plus loin de l'objet à traiter (utilisateur ou machine) vers le plus près ... et c'est la dernière à causer qui l'emporte.
    • L'ordre d'application de GPO situées à un même niveau peut être modifié en changeant l'ordre d'application
    • On peut également "forcer l'application" d'une GPO normalement moins prioritaire en cochant "Appliqué" sur la GPO (terme en français absolument mal traduit, car en version anglaise, le terme est "enforced" qui se traduirait par "forcer l'application"). Cette possibilité dit cependant être utilisée avec parcimonie et de préférence de manière temporaire, le temps de corriger le tir sur les GPO plus prioritaires qui ne font pas ce qu'elles devraient.
    • On peut également "bloquer l'héritage", mais tout comme le "Appliqué" cela doit être utilisé avec parcimonie.

    Mais revenons à ton pb.

    [... Le script fonctionne parfaitement lorsque qu'il est utilisé sur un poste dans une unité d'organisation qui ne bénéficie pas de l'héritage donc pas de Default Domain Policy...]

    ==> Ce qui signifie que le mot de passe que tu as défini dans ton script ne répond pas aux exigences de complexité et longueur définies dans la Default Domain Policy. Ce n'est pas la Default Domain Policy qui pose problème et qu'il faut remettre en cause, c'est ton mot de passe.

    Le Logon Script présenté doit :

    • être exécuté dans une GPO spécifique - et pas dans la Default Domain Policy.
    • est un LogonScript machine. Il s'exécute au démarrage de la machine

    Le dit logonScript ajoute un compte local dans le groupe administrateur local de la machine.

    • Password en clair ==> grr, un script n'est qu'un simple fichier texte qu'on peut éditer et là bingo, on a le login et le password. A proscrire ! 
    • Il y a bien plus simple ... et sécure : GPO groupe restreint.

    des exemple  : https://thesysadminchannel.com/add-local-administrators-via-gpo-group-policy/

    https://www.it-connect.fr/gpo-definir-un-utilisateur-administrateur-local-de-tous-les-pcs/

    Retour d'expérience sur ce que décrit ci-dessus :

    • Ce n'est pas parce qu'on a trouvé un "tuto" ou un script sur le Net qu'on se doit de l'appliquer sans comprendre ce qu'il fait. Sinon, pourquoi prendre un admin pour effectuer ces opérations ? Autant prendre juste quelqu'un qui sait lire et reproduire.
    • Si on trouve plusieurs "tuto" qui donnent des voies différentes pour faire ce que désiré,on se doit de déterminer lequel est dans les Best-Practices. Pour cela, il faut faire fonctionner ce qui se situe entre les 2 oreilles.
    • Ce n'est pas parce qu'un tuto est "techniquement valable" à un moment donné qu'il doit être appliqué  Ad vitam aeternam. Les pratiques changent, les Best-practices évoluent également. Ce qu'on faisait il y a 20 ans, n'est plus forcément valable de nos jours.

    cordialement

    Olivier

    mardi 3 novembre 2020 03:51
    |