GPO Guys, Hello Again :),

Dans le cadre d’un projet de migration vers Windows Server 2016, une task intéressante faisant partie du plan de migration consistait à convertir toutes les GPOs locales de certains serveurs (en mode WorkGroup) placés en DMZ vers des GPOs de domaine A(ctive) D(irectory).

J’aimerais donc partager avec vous à travers cet article la méthode /outils utilisé pour réaliser cette action, qui n’est malheureusement pas décrite dans les K(nowledge) B(ase) de MS.

Alors comment ça marche ?

Tout d’abord, vous devez faire le listing de toutes les machines ayant des GPOs locales, à transformer en GPOs de domaine.

Téléchargez ensuite l’outil LGPO.exe et placez-le sur toutes les machines Windows ayant des GPOs Locale à récupérer.

LGPO.exe est un outil en ligne de commande très puissant qui vous permet d’accélérer la gestion de vos stratégies de groupes locales (LGPO : Local Group Policy Objects).

Actuellement disponible en V2.0, LGPO.exe prend désormais en charge les MLGPO (Multiple Local Group Policy Objects) ainsi que les valeurs de Registre REG_QWORD 64-bit.

LGPO.exe fait partie du package « Microsoft Security Compliance Toolkit 1.0« .

 

Vous pouvez le télécharger gratuitement ici.

HowTo : Transformer une GPO locale >> GPO de domaine

Dans l’exemple suivant, nous allons convertir une GPO locale, configurée sur un de mes serveurs d’administration et la transformer /migrer vers un domaine Active Directory.

Je vais commencer par placer (via un Copy/Paste) l’outil LGPO.exe sur mon serveur d’administration (l’outil sera placé dans le dossier C:\GPOTools) et je lancerai ensuite l’Invite de Commande (CMD.exe) en tant qu’Administrateur.

Enfin, la commande suivante est exécutée pour faire un Backup de la GPO locale :

LGPO.exe /b C:\LocalGPOs_Backup /n MyLocalGPO

Maintenant que le Package de GPO Locale est généré, lancez l’outil GPMC.msc depuis un Domain Controller ou une machine d’administration ayant les outils RSAT installés et suivez les instructions suivantes :

  • Copiez /Collez le Package de GPO généré précédemment sur votre DC ou Machine d’Administration
  • Faites un clic-droit sur le noeud « Group Policy Objects » (ou Objets de stratégie de groupe si votre OS Server est en FR) et sélectionnez « Import Settings…« 

  • L’assistant d’importation de paramètres GP apparaît, cliquez sur « Next /Suivant » pour continuer
  • Spécifiez l’emplacement de la sauvegarde GPO locale créée précédemment :

  • Vérifiez les informations concernant votre GPO locale et cliquez sur « Next /Suivant » :

  • Une fois les paramètres importés, cliquez sur « Finish » pour lancer /confirmer le processus d’importation au niveau de la GPO de domaine

  • L’assistant vous affiche le statut post-importation des paramètres : Succeeded si l’opération s’est bien déroulée 🙂 :

  • Enfin, vérifiez que les paramètres de votre GPO locale sont bien présents au niveau de la GPO de domaine :

Et voilà le tour est joué :).

HK.

Publicités
commentaires
  1. Hugo dit :

    Bonjour, faut-il créer une gpo portant le même nom au préalable ou pas ?

  2. loic dit :

    Bonjour, je n’ai jamais utilisé de stratégies de groupe, du coup pourrais-tu m’éclaircir ? Pour une app de monitoring, je mets certains réglages d’audits dans les stratégies locales (création de process, changement de stratégie, …). Si l’app est installée sur un ordi au sein d’un domaine qui possèdes des stratégies de groupes, vont elles remplacer les stratégies locales ? Ou bien le feront elles que dans certains cas ?
    exemple: si l’audit de création de process est réglé dans les stratégies locales à 3 (success et failure) et à 0 dans la stratégie de groupe, qui l’emporte ?
    PS:Bon article en tout cas 😉

    • Hicham KADIRI dit :

      Bonjour Loic, l’ordre d’application des GPO est le suivant : LSDOU (Local | Site | Domain | OU). La réponse à ta question est dans le concept LSDOU. Dans ton cas, la première GPO appliquée est « L -> Locale », la GPO linkée au niveau du site ou Domain (voire aussi OU) viendront ensuite, cela veut dire qu’à partir du moment ou t’as une GPO de domaine qui s’applique, les paramètres configurés localement sont écrasés par ceux appliqués via la GPO de domaine. Pour en savoir plus : https://blogs.technet.microsoft.com/arnaud_jumelet/2009/09/19/ordre-dapplication-des-gpo/

      • loic dit :

        Merci pour ta réponse 🙂 Donc pour être sûr de bien comprendre, il n’y a pas de principe de précaution qui voudrait de laisser la règle la plus « sécurisante » ? C’est à dire que dans mon exemple, la règle de l’audit de création de process serait écrasée, et l’audit ne serait plus actif. Que se passerait t-il si je ré-active l’audit ? Est-ce que je serais tranquille juste qu’à ce qu’une GPO S D ou OU soit à nouveau modifiée ? Autrement, comment faire pour garder mes audit locaux, et ceux non-locaux ?

      • Hicham KADIRI dit :

        Tu ne peux pas paramétrer les Settings de GPO avec des valeurs différentes, quel serait l’intérêt ?
        Si je dois appliquer un Setting X avec une valeur V1 via GPO local, pourquoi pousser le même paramètre X avec cette fois une valeur V2 via GPO de domaine ?
        Si les paramètres configurés localement via GPO locale doivent restés en place, le mieux c’est de les forcer en appliquant une GPO de Domaine.

  3. loic dit :

    Je suis bien d’accord avec toi, et bien sûr ta dernière phrase est la meilleure possibilité, mais elle n’est pas possible dans mon cas. Je voudrait que mon logiciel soit installé et modifie localement les GPO, mais parce qu’il doit pouvoir être installé par un employé n’ayant pas de connaissances techniques (par exemple le pdg), sans que je reçoive pleins de demandes de support pour savoir comment bien configurer les GPOs de domaine. De plus, les GPOs de domaine seront forcément vues par l’administrateur réseau, ou l’ingénieur de production, ce que je voudrais éviter. La prévention de fuites dans une entreprise comprend parfois ce type de pratique, c’est à dire la surveillance par une équipe rendant compte directement au pdg, ou directement par le pdg, sans que le reste de l’équipe et des employés ne soient au courant. Je sais qu’une boite française bien connue dans un secteur sensible a notamment déjà mis en place une telle pratique dans le passé.

    • Hicham KADIRI dit :

      Eh bien dans ce cas, tu créé un Master Windows dédié pour cette population de users. à l’aide de l’outil LGPO + SCM tu peux générer des general settings de GPO local qui sont fournis « by default » avec l’OS. Comme ça l’utilisateur lambda n’aura rien à faire.

Répondre

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l'aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s