Archives de la catégorie ‘Group Policy Objects’

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-asaService) 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-aService) de Microsoft Azure, cette offre est aussi connue sous le nom de DCaaS (DomainController-as-aService).

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

Publicités

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

 

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.

 

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

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

 

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.

 

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