[HowTo] Bloquer l’exécution de PSexec.exe

 

Introduction

PSexec fait partie de la fameuse SysInternals Tools/PsTools Suite de Microsoft, créée par Mark Russinovich, qui n’est autre que le CTO actuel de la firme américaine.

PSexec vous permet d’exécuter des commandes/Processus sur des machines distantes, et ce sans avoir besoin d’installer de features/outils supplémentaires.

Il s’agit d’un outil très puissant d’Administration (à distance) et troubleshooting des plateformes Windows (Client & Server).

Télécharger la Suite SysInternals Tools

Télécharger l’outil PSexec.exe

Note : le guide d’utilisation de PSexec est détaillé depuis la même page de Download.

Tip : comme vous pouvez le constater, les tools de la Sysinternals peuvent être téléchargés séparément.

 

Bloquer l’exécution de PSexec ?!! Pourquoi ? Pour quelles raisons ?

Contrairement à la plupart des Softwares/Tools de Microsoft, le fonctionnement de PsExec.exe n’est pas un secret, il est assez simple. PsExec autorise les redirections des Input & Output d’un exécutable démarré à distance via l’utilisation de SMB et du partage (caché) $ADMIN sur le système distant. Avec ce partage, PsExec utilise l’API Windows Service Control Manager (WSCM) pour démarrer le service PsExecsvc sur le système distant, qui crée un canal nommé avec lequel PsExec communique. Ce canal nommé est ce qui permet la redirection des entrées / sorties vers le système qui a lancé PsExec.

PsExec peut être utilisé pour collecter des informations depuis des machines distantes (IPConfig, Net use, …) ou administrer un serveur Windows (Changer le password d’un compte Admin Loca, Patch management à partir d’un script…) ou encore lancer une instance Regedit.exe en tant que System Account pour pouvoir écrire/modifier certaines clés de Registre et bien plus encore !

La puissance de cet outil fait justement « peur » à certains RSSI/DSI, par conséquent, PsExec fait généralement partie des tools à Blacklister sur tout le parc Windows Client/Server.

A l’aide de PsExec, un Hacker ayant réussi à récupérer des crédentials depuis une machine vulnérable sur le réseau, peut les utiliser pour établir une connexion distante et tenter des collecter plus d’infos sensibles voire envisager une escalation de privilège.

 

Quelques Real-world scénarios

• Exéuction d’un programme malveillant à distance (eg : Backdoor)

• Exécuter un programme/file à distance via l’utilisation d’un UserName et le Hash de son password !

Exécution des outils /programmes en tant que Compte « System » : compte ayant le plus haut niveau de privilège sur les OS Windows

 

Vous aurez compris, l’utilisation de PsExec au sein d’un réseau Windows peut s’avérer dangereuse car permettrait à un Hacker ou toute personne malveillante d’accéder et récupérer à des informations sensibles (AD, comptes Admin…)

 

HowTo : Bloquer l’exécution du PSexec

Il existe différentes méthodes pour bloquer l’exécution de PsExec.exe :

• Désactivation du partage (par défaut) ADMIN$
• Déploiement d’une clé de registre (psexec.exe > Dubugger = svchost.exe)

 

Bloquer PsExec via la désactivation du Partage Windows ADMIN$

Pourquoi désactiver le partage ADMIN$ ?

Lorsque PsExec est utilisé pour exécuter une tâche/commande sur un système distant, il crée un nouvel exécutable/service appelé « psexesvc.exe ». Cet exe est copié dans le dossier Windows de la machine distante via le partage par défaut ADMIN$ (d’où la nécessité d’être un administrateur pour que psexec fonctionne à distance), désactiver ce partage bloque donc le fonctionnement de PsExec

Pour désactiver le partage ADMIN$, rien de plus simple, il faut lancer la console « Dossiers partagés » en exécutant l’outil « FsMgmt.msc » depuis le Menu Exécuter ou Démarré > Partages > ADMIN$ > Click-droit > Arrêter le Partage.

 

Bloquer PsExec via la clé de Registre

Pour bloquer l’exécution du PSexec via la clé de Registre, suivez les instructions suivantes :

• Créer une clé de Registre nommée « psexec.exe » au niveau de : HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\
• Créer ensuite une sous-clé au niveau de « psexec.exe », avec les informations suivantes :
  • Type : REG_SZ (Data String)
  • Nom clé : Debugger
  • Valeur : svchost.exe

 

Aucun reboot de la machine n’est requis :).

Testons maintenant l’exécution du PSexec. Dans l’exemple suivant, je reprend l’exemple précédent pour lancer un CMD.exe en tant que « System », comme montré ci-dessous, aucun résultat n’est retourné.

PSexec est bloqué au lancement, vous n’aurez aucune info ni message d’erreur :

 

Bloquer PsExec via GPO (GPP)

Si vous devez généraliser le déploiement de la clé Registre créée précédemment, le meilleur moyen de le faire, est de configurer une GPP (Group Policy Preference), voir paramètres suivants ;

 

Télécharger la clé de Registre

Vous pouvez télécharger la clé de Registre depuis l’URL suivante et l’importer directement sur les machines (Client et/ou Serveur) sur lesquelles vous souhaitez bloquer l’exécution de PSexec

https://gallery.technet.microsoft.com/Block-PsExec-Execution-4a86c023

 

Pensez à implémenter AppLocker 

Le meilleur moyen de bloquer l’exécution des PsTools (PsExec, PsShutdown…) est d’implémenter des règles (Blacklisting) AppLocker à base de Hash, c’est le moyen le plus fiable en terme de software blacklisting dans les environnements Windows.

 

Note : un eBook sur AppLocker 2012 R2 et 2016 est disponible sur BecomeITExpert.com. Si le sujet vous intéresse, cliquez sur une des images ci-dessous pour en savoir plus.

 

A bientôt :).

Différence entre Windows Server Active Directory (ADDS) vs Azure Active Directory (AAD) vs Azure AD Domain Services (AADDS)

Hi All,

Suite à la réalisation de plusieurs missions (Consulting /Expertise Azure), j’ai pu constater que plusieurs clients se posent toujours la même question quant il s’agit de gérer les identités et accès aux applications Cloud.

The Question est la suivante :

Quelle est la différence entre une infrastructure AD (Windows Server Active Directory) traditionnelle, Azure Active Directory (AAD) et Azure Active Directory Domain Services (AADDS) ?

Si vous vous posez aussi la même question, eh bien sachez que vous êtes à la bonne adresse :).

Let’s see la différence !

 

First of all, définissons ce que c’est Windows Server Active Directory, Azure AD et Azure ADDS !

Windows Server Active Directory (ADDS)

ADDS pour Active Directory Domain Services (aka AD pour Active Directory) est un rôle natif fourni (par défaut) sur toute nouvelle installation de Windows Server, que ce soit en mode GUI (Graphical User Interface) ou en mode Core (Installation Minimale)

Le rôle ADDS vous permet de déployer un annuaire AD (Base de données AD : NTDS.dit) pour stocker et gérer de manière centralisée tous vos objets réseaux et sécurité : ordinateurs, utilisateurs, imprimantes, partages, GPOs…etc

Cet annuaire permet également de stocker et gérer les données relatives aux applications pouvant être intégrées dans un AD et l’interroger via LDAP.

A l’aide de GPOs (Group Policy Objects) de domaine, vous pouvez également centraliser la configuration, le paramétrage et la sécurisation de vos comptes utilisateurs et ordinateurs du réseaux.

ADDS représente la base (Backbone) d’un réseau Microsoft d’entreprise.

 

Azure Active Directory (Azure AD)

Azure Active Directory (aka AAD) est l’offre IDaaS (IDentity-as–a–Service) proposé par Microsoft Azure.

AAD est une solution (service Cloud mutualisé >> Mulit-Tenant) de gestion des identités et des accès pour les applications (principalement WEB) hébergées et exécutées dans le Cloud Azure mais aussi celles hébergées dans vos Datacenters OnPrem(ise).

Je vous invite à regarder la vidéo suivante pour en savoir plus sur Azure AD :

La documentation complète sur Azure Active Directory est disponible à cet URL.

Azure Active Directory Domain Services (Azure ADDS)

AADDS (Azure Active Directory Domain Services) est une offre PaaS (Platform-as-a–Service) de Microsoft Azure, cette offre est aussi connue sous le nom de DCaaS (DomainController-as-a–Service).

Azure AD DS est une instance (Forêt AD standalone) Windows Server Active Directory managée par Microsoft, cela veut dire que Microsoft créé, déploie, Manage et sécurise les Domain Controller pour vous.

Vous n’avez plus à vous soucier de la sécurité de vos Domain Controllers (Patch Management, Hardening, Monitoring, Sécurité Physique…etc).

Consultez cet article pour en savoir plus sur Azure Active Directory Domain Services.

Note importante : Le fait que MS manage les Domain Controllers à votre place présente certaines limitations que vous devez prendre en considérations, voir cet article pour en savoir plus : https://docs.microsoft.com/en-us/azure/active-directory-domain-services/active-directory-ds-comparison > Rubrique « Compare Azure ADDS to DIY AD« 

 

Mais quelle est la différence entre un annuaire AD (traditionnel), un Azure AD et une instance Azure ADDS ?

Nous allons tout d’abord voir la différence entre Windows ADDS et Azure AD, car il s’agit des deux items souvent confondus par les clients.

Pour commencer, il faut toujours garder à l’esprit qu’un Azure AD n’est pas une solution remplaçante ou équivalente d’Active Directory dans le Cloud.

Quand on parle d’Active Directory (AD), on pense généralement à :

• Forêt /Domaine (Root & Child) Active Directory
• Contrôleurs de domaine (DC : Domain Controller) hébergés chez vous généralement et sur lesquels vous avez Full Control (qu’ils soient physiques ou virtuels).
• Service d’annuaire qui a une structure hiérarchique basée sur X.500
• Annuaire pouvant stocker de multiple type d’objet : utilisateurs, ordinateurs, imprimantes, GPOs, Sites AD, Partages…
• Service DNS utilisé en tant que « Locator » de ressources réseaux (traduction d’@IP en Host et vice versa)
• Annuaire pouvant être interrogé à l’aide du protocole LDAP (Lightweight Directory Access Protocol) ou LDAPS
• Authentification via Kerberos/NTLM
• Organisation des objets à l’aide d’OU (Organitional Unit)
• Configuration des postes clients (Ordinateurs) et utilisateurs à l’aide de GPO (Group Policy Object)
• Relation d’approbation entre deux ou plusieurs forêts/Domaine AD si ces dernières ont besoin de discuter et partager des ressources entre elles.

 

Un Azure AD quant à lui est :

• Un service Cloud (IDaaS) : cela veut dire que Microsoft conçoit, déploie et gère toute l’infrastructure (mutualisée) hébergeant Azure AD. Et vous, en tant que « Cloud Customer », vous consommez et payer ce service de manière mensuelle (en fonction du nombre d’utilisateurs s’authentifiant à travers votre Azure AD).
• Authentifie les utilisateurs aux niveaux des applications hébergées dans Azure ou celles hébergées chez vous OnPrem, via l’utilisation du service Azure AD Application Proxy.
• L’authentification se fait via Internet : Azure AD s’appuie principalement sur une authentification over Internet (HTTP/80 ou HTTPS/433).
• L’authentification ne se limite pas aux devices connectés sur le réseau Corporate de l’Entreprise mais plutôt to Any Device (vu que la communication avec un Azure AD se fait à l’aide des protocoles HTTP ou HTTPS, il suffit d’avoir un device connecté à Internet pour pouvoir communiquer avec un Azure AD.
• Azure AD s’appuie quant à lui sur des protocoles dis « Modern Authentication Protocol » tels que OpenID Conncet /Oauth2 /SAML /WS-FEDERATION (Goodbye Kerberos & NTLM ^_^).
• Contrairement à un Active Directory, Azure AD peut être interrogé via une interface REST API, appelée AD Graph API
• Azure AD étant un service Cloud (IDentity-as-a-Service), vous n’avez pas la main sur l’infrastructure hébergeant cette solution IAM, il n’y pas de gestion de GPO possible, la création d’une structure d’OU n’est pas non plus disponible car il s’agit d’une structure Plate (Flat).
• Azure AD stocke et gère uniquement les objets « Users » et « Groups » : pas de GPO, pas de partage réseau, pas de sites AD…etc
• La manière dont les objets AD classiques (users, computers, partages, groupes….) sont stockés et gérés est complètement différente entre un AD et Azure AD :
  • AD : Structure Hiérarchique (Hierarchical Structure)
  • Azure AD : Structure plate (Flat Structure)

Les deux schémas suivants illustre les deux types de structures :

 

En ce qui concerne Azure ADDS, c’est ni plus ni moins qu’un Active Directory traditionnelle déployé et géré par Microsoft. Les mêmes caractéristiques liées à AD listées ci-haut s’appliquent également à un Azure ADDS, ce dernier s’appuie sur Kerberos/NTLM pour authentifier les utilisateurs du réseau, permet l’organisation des objets dans des OU et vous permet de créer et configurer des GPOs. Il existe tout de même certaines limitations relatives à un Azure ADDS :

• Contrairement à un AD, Azure ADDS ne vous permet pas d’établir/créer de relations d’approbation entre plusieurs instances Azure ADDS.
• Vous n’avez plus la main sur les comptes « Admins Entreprises » et « Admins du Schéma »
• Et enfin, l’extension du schéma AD n’est pas possible sur un domaine (Managé) Azure ADDS.

 

Ce qu’il faut retenir !

Ce qu’il faut garder en tête :

Windows Server Active Directory (ou Services de Domaine Active Directory, ou encore Windows ADDS) est un rôle natif dans les plateformes Windows Server (from Windows Server 2000 :)). ADDS authentifie les utilisateurs via les protocoles Kerberos (ou NTLM), vous permet de créer tout type d’objet dans l’AD et les stocker dans des OUs. Ces objets peuvent être gérés à l’aide de GPO (User ou Computer).

Azure Active Directory (ou Azure AD, ou encore AAD), est une offre IDaaS (IDentity-as-a-Service) de Microsoft Azure, qui vous permet d’authentifier vos utilisateurs sur les applications Cloud (ou locales via l’utilisation d’Azure AD Application Proxy). Il peut héberger uniquement des objets « Utilisateurs » et « Groupes ». Ces objets peuvent être directement créés dans Azure AD (Cloud Only mode) ou récupérés depuis votre AD local via une synchronisation AD to AAD à l’aide de l’outil Azure AD Connect (Synchro Mode). Azure AD est conçu pour les Apps/Services Web, il s’appuie sur les protocoles Web Modernes tels que SAML /WS-FEDERATION /OAuth2…etc.

Quand vous déployez un Azure AD, vous êtes considérés comme un « Tenant » > Client Cloud

Votre Azure AD étant « Trusted » par défaut avec plusieurs annuaires (comme ceux de Facebook, Google..etc), vous pouvez automatiquement accéder à d’autres services Web en utilisant le même compte Azure AD (SSO by default).
Pour finir, il faut considérer Azure AD comme un « Federation Hub » car vous pouvez à tout moment « Trust » un autre Azure AD (d’autres clients/partenaires) et accéder à leurs ressources (et vice versa) en rien de temps !

Azure Active Directory Domain Services (ou Azure ADDS ou encore AADDS) est une offre DCaaS (DC-as-a-Service) de Microsoft Azure. Cette plateforme représente votre infrastructure AD locale dans Azure, la différence réside dans le fait que c’est Microsoft (le Cloud Provider) qui créé, déploie, gère et sécurise les Contrôleurs de domaine pour vous. Il s’agit d’une instance « Standalone » d’une forêt AD isolée et déconnectée de votre réseau local. Si vous avez des contraintes de sécurité relatives à la réplication de votre AD local vers Azure (vers des DCs hébergés sous forme de VMs Azure), l’offre Azure ADDS peut être une solution à adopter pour créer rapidement une nouvelle forêt dédiée pour Azure, pour authentifier (via Kerberos/NTLM) vos utilisateurs/machines Windows hébergés dans Azure. Azure ADDS reste aussi le meilleur compromis (Sécu, Réduction de coût /Réduction des efforts liés aux MCO) quand il s’agit de migrer des plateformes/locales Apps « Legacy » vers Azure et donc faire du Lift-and-Shift (ou As-Is) Migration.

 

That’s All,

A bientôt :).

#HK

[Windows Security News] La « Security Baseline » pour Windows Server 2019 et Windows 10 (1809)

L’équipe Windows Corp a récemment annoncé (01 Octobre/18) la disponibilité des paramètres de la « Security Configuration Baseline » pour Windows 10 1809 (RS5 > “Redstone 5« ) et Windows Server 2019.

Notez qu’il s’agit ici d’une version « Draft« . La version finale ne devrait pas tarder à arriver. Stay connected, abonnez-vous sur le Blog de MS TechNet

Le contenu de cette « Security Baseline » est disponible en téléchargement à l’URL suivante :

Windows-10-1809-Security-Baseline-DRAFT.zip

 

Contenu de la Security Baseline ?

Le zip file contient plusieurs :

• GPOs : plusieurs GPOs sont fournies avec le fichier zip téléchargé via le lien ci-dessus. Ces GPOs peuvent être importées directement dans votre environnement Windows.
• Script PowerShell : des scripts PowerShell sont également fournis avec le fichier zip. Ceux-ci vous permettent d’appliquer directement les GPOs à vos stratégies locales
• Fichiers ADMX personnalisés
• Documentations : plusieurs documents techniques intéressants sont disponibles :
  • MS Security Baseline Windows 10 v1809 and Server 2019.xlsx : La liste complète des paramètres applicables à WS 10 1809 et WS Server 2019
  • BaselineDiffs-to-v1809-RS5-DRAFT.xlsx : La liste des paramètres qui sont modifiés entre Windows 10 1803 et Windows 10 1809, et ceux modifiés entre Windows Server 2016 et Windows Server 2019
  • Windows 10 1803 to 1809 New Settings.xlsx : Les nouveaux paramètres introduits avec Windows 10 1809
  • Server 2016 to 2019 New Settings.xlsx : Les nouveaux paramètres introduits avec Windows Server 2019

 

Consultez cet article pour en savoir plus

[OS Hardening] : Restreindre l’accès aux clés USB via GPO (Group Policy Objects) et Script (Batch)

 

Introduction

Dans le cadre d’un projet de Hardening/Sécurisation d’infrastructures systèmes (Windows Server ou Client), vous pouvez avoir comme exigence « La désactivation des ports USB /Accès aux USB Devices ».

Cela peut concerner sur les serveurs (Physiques ou Virtuels) et/ou Postes de travail.

Pour répondre à cette exigence, Microsoft fourni par défaut dans ses OS (Client & Server) des paramètres de Stratégie de Groupe vous permettant de mettre en place cette restriction.

Alors, comment ça marche ?

Avant l’application de la procédure décrite ci-dessous, Notez que dans l’exemple ci-dessous, mon Laptop (un WS10 > 1803) permet toujours l’accès à mes devices USB :

Maintenant lancez l’outil GPMC.msc si vous souhaitez appliquer cette restriction sur plusieurs machines jointes à un domaine AD, ou GPEdit.msc si vous souhaitez d’abord tester et valider la procédure sur une machine localement.

Développez ensuite :

Configuration Ordinateur > Stratégies > Modèles d’Administration > Système > Accès au stockage amovible > Toutes les classes de stockage amovible : refuser tous les accès

Pour désactiver l’accès aux devices USB, il suffit de cochez « Activé » :

Après application/refresh des stratégies de groupe (GpUpdate /Target:Computer), l’accès aux USB devices (USB Keys, External Disks…etc) devient interdit (accès refusé) :

 

Astuce : Désactiver les ports USB via Script 

La désactivation des ports USB peut également se faire via Script.

Dans l’exemple suivant, un simple script Batch basé sur le Command-Line Tool « REG.exe » vous permet de réaliser cette opération en changeant la valeur de la Clé « Start » et la positionnant à 4 (au lieu de 3).

---

REM ==== Important : vous devez exécuter le script en tant qu’Administrateur !
REM ===================================================

REG ADD HKLM\SYSTEM\CurrentControlSet\Services\USBSTOR /v Start /t REG_DWORD /d 4 /f

---

Information utile

Si vous souhaitez ré-activer l’accès aux ports USB, il suffit d’éditer le fichier (Script Batch) et positionnez la valeur de la clé « Start » à 3

 

Téléchargez le script

Ce script est disponible en téléchargement gratuit depuis la Gallery TechNet.

Téléchargez le script ici.

[Group Policy Objects – Tip of the Week] HowTo : Supprimer les GPO « Orphelins » via PowerShell

 

Aujourd’hui, nous allons découvrir une technique qui va vous permettre d’optimiser votre infrastructure G(roup) P(olicy) O(bjects) : scanner, détecter, lister et supprimer toutes les GPOs « Orphelins/Non Linkés »

 

HowTo : Lister les GPOs Orphelins

Commencez par importer le module PowerShell GroupPolicy en exécutant la commande suivante :

Import-Module GroupPolicy

Pour collecter des informations sur toutes les GPOs, le paramètre -All est utilisé avec la Cmd-let Get-GPO.

Nous exportons ensuite le résultat vers un fichier XML qui sera traité et analysé pour savoir quelle GPO n’as pas de Link vers des OUs (sous-OUs) ou Domaine AD : lecture du fichier XML ligne par ligne pour connaitre les lignes sans le mot « LinkTo »

So, CTRL+C /CTRL+V la commande suivante et notez le résultat :

Get-GPO -All | Sort-Object displayname | Where-Object {If ( $_ | Get-GPOReport -ReportType XML | Select-String -NotMatch « <LinksTo> » ) {$_.DisplayName }}

Si vous souhaitez avoir un output au format tableau, exécutez la commande suivante :

Get-GPO -All | Sort-Object displayname | Where-Object {If ( $_ | Get-GPOReport -ReportType XML | Select-String -NotMatch « <LinksTo> » ) {$_.DisplayName }} | ft -AutoSize

Pour optimiser le résultat (Output), nous allons dans l’exemple suivant, afficher uniquement les deux valeurs des deux attributs suivants :

• DisplayName (Nom d’affichage)
• ID (GUID* de la GPO)

 

*: GUID pour Globally Unique IDentifier

Pour ce faire, exécutez la commande suivante :

Get-GPO -All | Sort-Object displayname | Where-Object {If ( $_ | Get-GPOReport -ReportType XML | Select-String -NotMatch « <LinksTo> » ) {$_.DisplayName }} | select DisplayName,Id | ft -AutoSize

Nous allons maintenant exécuter la commande suivante pour connaître le nombre de GPO non linkés (à aucun Domaine ou OU/sous-OUs) :

(Get-GPO -All | Sort-Object displayname | Where-Object {If ( $_ | Get-GPOReport -ReportType XML | Select-String -NotMatch « <LinksTo> » ) {$_.DisplayName }}).Count

Dans mon cas, 11 GPOs au total sont actuellement stockées/hébergées dans mon annuaire AD (HKCorp.Lan : AD de LAB o_O) alors qu’elles sont ni Linkées au Domaine (HKCorp.Lan) ni aux OUs ou sous-OUs !

Pour confirmer le résultat obtenu, je vais simplement lancer l’outil/console GPMC.msc (Group Policy Management Console) et vérifier le Scope de la GPO HKCRP-POC-LAPS (GPO retournée par la commande comme étant « Orphelin ») :

Comme montré dans la screenshot ci-dessus, le scope de la GPO HKCRP-POC-LAPS est en effet vide, cela veut simplement dire que cette GPO n’a aucun Link. Cela confirme donc le résultat retourné par la commande PS ci-haut.

HowT: GPO Orphelins – Reporting

Si vous souhaitez « Journaliser » et exporter la liste des GPOs Orphelins retournés par les commandes PS précédentes, vous pouvez exécuter les commandes suivantes :

Export vers un fichier texte (.TXT File)

Get-GPO -All | Sort-Object displayname | Where-Object {If ( $_ | Get-GPOReport -ReportType XML | Select-String -NotMatch « <LinksTo> » ) {$_.DisplayName }} | Out-File C:\GPO_Orphs.txt

Vers un fichier CSV (.CSV File)

Get-GPO -All | Sort-Object displayname | Where-Object {If ( $_ | Get-GPOReport -ReportType XML | Select-String -NotMatch « <LinksTo> » ) {$_.DisplayName }} | Export-CSV C:\GPO_Orphs.csv

HowTo : Supprimer les GPOs « Orphelins »

Si après vérification, vous confirmez qu’effectivement les GPOs non linkés remontés par les commandes PS sont « obsolètes » et n’ont simplement plus besoin d’exister dans votre annuaire AD, vous pouvez les supprimer directement depuis le snap-in GPMC.msc ou en exécutant la commande suivante :

Get-GPO -All | Sort-Object displayname | Where-Object {If ( $_ | Get-GPOReport -ReportType XML | Select-String -NotMatch « <LinksTo> » ) {$_.DisplayName }} | Remove-GPO 

je vous recommande tout de même de sauvegarder toutes les GPOs Orphelins avant de les supprimer (histoire d’avoir un moyen de Rollback :)), cela peut être réalisé en exécutant les commande suivantes.

Dans l’exemple suivant, je vais sauvegarder mes 11 GPOs dans C:\GPO_Backups

$Emplacement_GPOsBackup = « C:\GPO_Backups »

Get-GPO -All | Sort-Object displayname | Where-Object {If ( $_ | Get-GPOReport -ReportType XML | Select-String -NotMatch « <LinksTo> » ) {$_.DisplayName }} | Backup-GPO -Path $Emplacement_GPOsBackup

Une entrée par GPO « sauvegardée » vous est retournée :

Les fichiers de Backups (11 au total pour les 11 GPOs) sont générés et stockés dans l’emplacement spécifié lors de l’exécution de la commande (C:\GPO_Backups » :

 

Note importante

Comme mentionné à plusieurs reprises dans ce post, les techniques expliquées ici ne couvrent pas les GPOs linkées au niveau site AD.

Notez donc que les résultats qui vont vous être retournés après exécution des différentes commandes concernent uniquement les GPOs Orphelins non « Linkées » au Domaine AD ou OUs et sous-OUs.

J’espère que cette technique pourra vous être utile lors de la réalisation de vos audits AD/GPOs.

Keep in touch, d’autres HowTo GPOs arrivent prochainement :).

#HK

Les Administratives Templates (ADMX) pour Windows 10 {1709} sont désormais disponibles !

Microsoft vient de publier les Modèles d’Administrations/Administratives Templates (ADMX, ADML) AD pour Windows 10 {1709} Creator Updates. Téléchargez-les dès maintenant en cliquant sur le lien ci-dessous

Le fichier téléchargé (MSI file) inclut les modèles d’administration publiés pour Windows 10 (Fall Creators Update « 1709 »), dans les langues suivantes :

• cs-CZ Czech – Czech Republic
• da-DK Danish – Denmark
• de-DE German – Germany
• el-GR Greek – Greece
• en-US English – United States
• es-ES Spanish – Spain
• fi-FL Finnish – Finland
• fr-FR French – France
• hu-HU Hungarian – Hungary
• it-IT Italian – Italy
• ja-JP Japanese – Japan
• ko-KR Korean – Korea
• nb-NO Norwegian (Bokmål) – Norway
• nl-NL Dutch – The Netherlands
• pl-PL Polish – Poland
• pt-BR Portuguese – Brazil
• pt-PT Portuguese – Portugal
• ru-RU Russian – Russia
• sv-SE Swedish – Sweden
• zh-CN Chinese – China
• zh-TW Chinese – Taiwan

 

Enfin, notez les prérequis (OS Requirement) suivants :

• Windows 10
• Windows 8.1
• Windows 7
• Windows Server 2016
• Windows Server 2012 R2
• Windows Server 2012
• Windows Server 2008 R2

[Group Policy Objects] HowTo : Transformez vos GPOs Locales en GPOs de domaine

 

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.

[Group Policy Objects] HowTo : Lister toutes les GPOs « Vides » !

 

Hello GPO Guys,

Une « Trick » sur les GPOs qui peut vous être utile si vous faites régulièrement des audits GPOs.

J’ai récemment audité une infrastructure système « Windows Server 2012 R2 /2016 » assez complexe avec un peu plus de 1000 GPOs implémentées.

La phase /Step 1 de mon audit GPO était de lister et supprimer (après validati/on du client) toutes les GPOs vides, le but étant de réduire rapidement le nombre de GPOs de domaine « inutiles » (MAIS qui sont quand même répliquées dans tous les sens, lors de la réplica AD ^-^).

Alors comment ça marche ?

Lancez PowerShell ISE depuis un D(omain) C(ontroller) ou une machine d’administration ayant les outils RSAT ADDS installés et Copiez /Collez le bloc de code PS suivant :

---

$GPOVides = Get-GPO -All
foreach ($item in $GPOVides)
{
if ($item.Computer.DSVersion -eq 0 -and $item.User.DSVersion -eq 0)
{
write-host $item.DisplayName est vide !
}
}

---

Dans l’exemple suivant, le script me retourne les GPOs listées ci-dessous :

Notez que ce script PS est disponible en téléchargement gratuit sur la Gallery TechNet.

Téléchargez-le ici.

A bientôt

HK T___T

Découvrez le « Group Policy caching » sous Windows Server 2012 R2 et Windows 8.1

Hello everyone,

Aujourd’hui, nous allons parler des GPO (Group Policy Objects), et plus précisément d’une nouvelle fonctionnalité introduite aux Stratégies de Groupe sous Windows Server 2012 R2 et Windows 8.1 : Group Policy Caching

Group Policy Caching ?! Qu’est-ce que c’est ?

Quand une machine du réseau exécutant « Windows 8.1 » ou « Windows Server 2012 R2 » récupère des paramètres de Stratégies Groupes depuis un DC (Domain Controller), les valeurs de ces paramètres de stratégies de groupes sont stockées localement sur la machine où l’utilisateur AD s’est authentifié, et ce dans l’emplacement suivant :

C:\Users\<UserName>\AppData\Local\GroupPolicy\DataStore\0\SysVol\<domain name>\Policies

Chaque GPO récupérée est représentée par un dossier portant son IDentifiant Unique (GUID : Globally Unique IDentifier)

Le principe du « Policy Caching » consiste à lire /charger le contenu le plus récent des paramètres de stratégies de groupe téléchargé et stocké localement depuis l’emplacement (local) indiqué précédemment au lieu de contacter un DC à chaque Logon.
Ceci réduit le temps requis pour chaque actualisation du moteur de stratégie de groupe local et chargement des paramètre GP depuis le réseau (depuis un DC du réseau).

Notez que le « Group Policy Caching » est une fonctionnalité activée par défaut sur les OS Windows Server 2012 R2 et Windows 8.1

Si toutefois vous voulez contrôler l’activation /désactivation de cette fonctionnalité, cela peut être fait via l’arborescence suivante :

OS en FR :

Configuration Ordinateur > Modèles d’administration > Système > Stratégies de groupe > « Configurer la mise en cache des stratégies de groupe »

OS en EN :

Computer Configuration > Administrative Templetes > System > Group Policy > « Configure Group Policy Caching »