Contrôle de santé d’Active Directory avec le framework PowerShell

Tutoriels
PowerShell

Ceci est la partie II d’une série en deux parties sur les vérifications de l’état de l’Active Directory. Bien que la lecture ne soit pas obligatoire, si vous souhaitez savoir comment le script PowerShell dont vous allez apprendre dans cet article a été créé, nous vous encourageons à consulter Construction d’un outil de vérification de l’état de l’Active Directory [En profondeur] : Partie I.

Dans la Partie I, vous avez appris combien de tests multiples différents existent et pourquoi ils sont importants. Regroupons-les maintenant tous et construisons un outil. Dans cette partie, vous convertirez toutes les vérifications de l’état de l’Active Directory expliquées dans la Partie I en un cadre de test. Vous apprendrez également comment produire les résultats de diverses vérifications de l’état de l’AD vers des outils tels que Pester et un outil de surveillance appelé PRTG.

Pour suivre ou pour voir une version terminée de l’outil dont vous allez apprendre dans cet article, téléchargez le script ADHealthCheck-NoResult.ps1 depuis GitHub.

Définition de la sortie

Avoir un type d’objet commun et un moyen facile de le générer facilitera grandement la conversion des résultats des tests vers l’outil de votre choix.

Pour créer une sortie uniforme pour tous les outils potentiels, j’ai choisi d’utiliser une classe PowerShell. Bien que cela ne soit pas obligatoire, c’est l’approche que j’ai choisie ici. L’essentiel est de s’assurer que toutes les vérifications de l’état de l’AD renvoient le même type de sortie.

A PowerShell class is a schema that defines how a PowerShell object should look and what it should do. Each line you see below represents a property the objects return will have. You can see below I’m planning on each AD health check to return ten properties.

Class AdhcResult {
    [string]$Source
    [string]$TestName
    [bool]$Pass
    $Was
    $ShouldBe
    [string]$Category
    [string]$SubCategory
    [string]$Message
    $Data
    [string[]]$Tags
}

Pour accélérer la création de cette classe, j’utiliserai une fonction d’aide appelée New-AdhcResult. Cette fonction crée la classe et tout ce dont vous aurez besoin pour suivre. Cette fonction produira un objet de type [AdhcResult] personnalisé.

Exécution de l’outil de vérification de la santé AD

Tout d’abord, téléchargez et copiez le script de vérification de la santé AD sur un contrôleur de domaine. Ouvrez-le avec PowerShell ISE et exécutez-le. Cette partie de l’outil ne renverra aucune information.

Le script s’exécutera et stockera le résultat de chaque vérification dans la variable $TestResults sous forme de plusieurs objets [AdhcResult]. Vous utiliserez ces objets plus tard pour générer des rapports ou les exporter dans divers outils. Le fait de conserver les résultats de la vérification de la santé dans une variable de cette manière vous permet d’ajouter d’autres résultats si vous choisissez d’en créer un autre et d’utiliser la commande New-AdHcResult.

Une fois le script terminé, vous devriez maintenant avoir un ensemble complet d’objets de vérification de la santé AD stockés dans la variable $TestResults. Vous pouvez maintenant exécuter $TestResults depuis la console et voir les résultats bruts.

Affichage des résultats de la vérification de la santé AD dans des outils

Étant donné que toutes les vérifications sont dans un type d’objet commun, vous pouvez les inspecter plus facilement à travers quelques outils comme Pester et PRTG.

Dans cette section, vous allez apprendre comment créer un rapport HTML avec un outil appelé extent et afficher le rapport dans PRTG.

Création d’un fichier XML nUnit avec Pester

Vous devez d’abord convertir les objets PowerShell dans un format compréhensible par vos outils. La plupart des outils comprennent le XML, plus précisément le XML nUnit. C’est un format que vous pouvez importer dans divers outils pour afficher les résultats.

Étant donné que vous travaillez avec PowerShell, vous utiliserez le framework de test Pester pour lire la sortie du script de vérification de la santé de l’AD et générer un fichier XML nUnit

Commencez par télécharger la dernière version de Pester. Vous pouvez le faire en exécutant Install-Module dans une console PowerShell élevée. La commande ci-dessous forcera l’installation de la dernière version de Pester. Comme le certificat avec lequel Pester est signé est livré avec Windows 10, nous devrons utiliser le paramètre SkipPublisherCheck pour l’installer.

PS51> Install-Module Pester -Force -Verbose -SkipPublisherCheck

Une fois que Pester est disponible, vous pouvez exécuter le script et créer dynamiquement un ensemble de tests Pester.

Remarque : Vous pouvez également créer des tests Pester vous-même sans même utiliser le script PowerShell que j’ai fourni.

Le script PowerShell ci-dessous utilisera Pester pour générer un fichier XML nUnit à partir de la sortie de la variable $TestResults définie dans le script ADHealthCheck-NoResult.ps1.

Enregistrez ce fichier sous Pester.ps1 dans le même dossier que le script de vérification de la santé AD.

# pointez dans le fichier ADHealthCheck
. $PSScriptRoot\ADHealthCheck-NoResult.ps1
$Grouped = $TestResults | Group-Object Category

Foreach($Category in $Grouped) {
    Describe -Name $Category.Name -Tags ($Category.Group.Tags | Select -Unique) {
        Foreach($Result in $Category.Group){
            Context "$($Result.Source) - $($Result.TestName)" {
                It -Name "Should've passed" {
                    $Result.Pass | Should -Be -ExpectedValue $True -Because $Result.data
                }
            }
        }
    }
}

Enfin, exécutez Invoke-Pester ci-dessous pour invoquer le fichier Pester.ps1 et enregistrer les résultats au format NUnitXml.

PS51 > Invoke-Pester -Script @{Path = '.\Pester.ps1'} -OutputFile .\NunitReport.xml -OutputFormat NUnitXml

Construction d’un rapport HTML avec l’outil Extent

Une fois que vous avez le fichier XML NUnit, vous pouvez maintenant utiliser ce fichier pour le passer à un outil qui peut le convertir en HTML. L’un de ces outils s’appelle extent. Extent est un outil pratique pour créer des rapports HTML à partir de fichiers XML Nunit.

Tout d’abord, téléchargez extent dans le même répertoire que le fichier NunitReport.xml créé précédemment. Ensuite, exécutez les commandes suivantes dans une session PowerShell. Ces commandes créeront le répertoire pour stocker les fichiers HTML, puis exécuteront extent.exe pour effectuer la conversion.

# Créer le répertoire du rapport
PS51> mkdir .\HTMLReports

# Créer le rapport
PS51> .\extent.exe -i .\NunitReport.xml -o .\HTMLReports\

Lorsque terminé, vous trouverez deux fichiers HTML dans le répertoire HTMLReports. Ces fichiers ressembleront aux captures d’écran ci-dessous lorsque vous les ouvrirez avec un navigateur Web.

HTML report for Pester test output
HTML report for Pester test output

Intégration des résultats de vérification de la santé AD dans PRTG

PRTG est un outil de surveillance populaire développé par Paessler que vous pouvez utiliser pour surveiller votre infrastructure et vos services. Dans cette section, vous apprendrez comment pousser les résultats de vérification de santé vers PRTG une fois que le script de vérification de santé a été exécuté.

Pousser les résultats vers PRTG nécessite plus de travail que de laisser l’outil récupérer les informations, mais vous verrez finalement que la configuration en vaut bien le temps passé.

Prérequis

Pour configurer avec succès PRTG en tant qu’outil de surveillance pour le script de vérification de santé AD présenté dans cet article, assurez-vous de disposer de :

  • PRTG installé et configuré
  • Tous les contrôleurs de domaine configurés dans PRTG
  • Le script PowerShell Send-AdhcResultToPrtg.ps1 téléchargé depuis GitHub
  • L’URL et le port de votre capteur PRTG

Si vous avez accompli chacun des prérequis, vous pouvez ensuite suivre les instructions étape par étape ci-dessous sur la manière dont je recommande de pousser ces résultats de vérification de santé AD vers PRTG.

  1. Créez un dispositif dans PRTG appelé Domaine ou tout autre nom que vous préférez.
  2. Créez un capteur de poussée HTTP avancé avec un IdentityToken de directory-adhealthcheck.  Notez que la casse est sensible!
  3. Pour chaque dispositif contrôleur de domaine dans PRTG, créez un capteur de poussée HTTP avancé. Pour chaque IdentityToken, ajoutez à chaque capteur -adhealthcheck comme dc01-adhealthcheck.
  4. Ajoutez le contenu du script PowerShell Send-AdhcResultToPrtg.ps1 à la fin du script PowerShell ADHealthCheck-NoResult.ps1 que nous avons couvert.
  5. Modifiez la variable $PRTGUrl avec l’URL et le port de votre capteur PRTG.
  6. Exécutez le script.

Une fois terminé, une fois que le script de vérification de la santé de l’AD est terminé, il devrait désormais transmettre l’état à vos capteurs PRTG comme indiqué ci-dessous.

PRTG sensors showing AD health

Programmation du script de vérification de la santé de l’Active Directory

La surveillance de la santé de l’AD est un processus continu. Vous devriez exécuter des tests en permanence plutôt que des instances ad hoc. Planifions l’exécution du script de vérification de la santé de l’Active Directory à des intervalles fréquents.

Le moyen le plus simple d’automatiser ces vérifications est d’ajouter le script au planificateur de tâches et de le laisser s’exécuter sous un compte utilisateur AD ou un compte de service géré par groupe.

L’utilisation d’un compte de service géré par groupe (gMSA) est la manière la plus sécurisée d’exécuter des tâches planifiées de manière autonome, car seuls les comptes informatiques spécifiés peuvent récupérer le mot de passe dans AD. Mais certaines organisations peuvent ne pas avoir cette chance.

Création d’un compte utilisateur AD

Commençons par décomposer ce qu’il faut pour configurer un compte utilisateur AD afin d’exécuter la tâche planifiée.

Si vous devez exécuter une tâche planifiée en tant que compte utilisateur, n’hésitez pas à ne pas l’exécuter en tant que votre propre compte ! Créez toujours un compte utilisateur distinct à cette fin.

Pour gagner du temps, vous verrez ci-dessous un script PowerShell. Il s’agit d’un exemple de script que vous pouvez utiliser pour créer un compte utilisateur AD faisant partie du groupe Domain Admins. Vous pouvez ensuite utiliser ce compte pour exécuter la tâche planifiée.

# Changez ceci pour l'OU de vos comptes de service
$OU = "OU=Service Accounts,DC=contoso,DC=com"
# Changez ceci pour le mot de passe que vous souhaitez utiliser pour le compte
$Password = "JägareTvå"
$SecureString = $Password | ConvertTo-SecureString -AsPlainText -Force
New-ADUser -Enabled $True -Path $OU -Name svcADHealthCheck -AccountPassword $SecureString
# Restreindre le compte aux contrôleurs de domaine uniquement
$DomainControllers = (Get-ADDomainController -Filter *).Name

Set-ADAccount -Identity svcADHealthCheck -LogonWorkstations ($DomainControllers -Join ",")

# Le rendre Domain Admin (Désolé)
Add-ADGroupMember -Identity "Domain Admins" -Members svcADHealthCheck

Création d’un compte de service géré par un groupe

Utiliser un gMSA pour exécuter la vérification de l’état de santé est un peu plus délicat si vous n’utilisez pas déjà gMSA dans votre environnement, mais c’est beaucoup plus sécurisé.

Création d’une clé racine KDS

Pour créer un compte gMSA afin d’exécuter le script de vérification de l’état de santé AD, ajoutez d’abord une clé racine KDS si vous n’en avez pas déjà une. Vous pouvez vérifier si vous avez une clé racine KDS en exécutant la commande PowerShell Get-KDSRootKey sur un contrôleur de domaine.

Si vous n’avez pas de clé racine KDS, vous pouvez en créer une en exécutant Add-KDSRootKey -EffectiveImmediately sous un compte utilisateur faisant partie du groupe Domain Admins AD sur un contrôleur de domaine 2012R2 ou ultérieur.

La clé doit se répliquer sur les autres contrôleurs de domaine pour prendre effet. Plus d’informations sur ce processus peuvent être trouvées dans la documentation Microsoft.

Création du gMSA

Une fois la clé racine KDS créée, vous êtes prêt à créer le compte gMSA avec PowerShell. Ci-dessous, vous pouvez voir un exemple de script à utiliser pour créer le compte gMSA autorisé uniquement à s’authentifier à partir d’un contrôleur de domaine du groupe Domain Admins.

# Changez pour votre domaine
$Domain = "contoso.com"

$AccountName = "svcadhealthcheck"

# Créez un GMSA appelé svcadhealthcheck (ou en réalité svcadhealthcheck$) et autorisez uniquement les contrôleurs de domaine à récupérer le mot de passe
New-ADServiceAccount $AccountName -DNSHostName "$AccountName.$Domain" –PrincipalsAllowedToRetrieveManagedPassword "Domain Controllers"

# Ajoutez le GMSA aux Domain Admins
# Notez que nous ajoutons le compte par son véritable nom SamAccount 'svcadhealthcheck$'
Add-ADGroupMember -Identity "Domain Admins" -Members "$AccountName`$"

Installation et Test du gMSA

Maintenant que le gMSA est créé, la dernière étape consiste à l’installer et à le tester sur tous les contrôleurs de domaine. Une façon de le faire est d’utiliser la commande PowerShell Invoke-Command. Ci-dessous, vous pouvez voir un script PowerShell qui installera le gMSA sur tous les DC et s’assurera qu’il fonctionne correctement.

# Cela s'exécutera sur tous les contrôleurs de domaine
Invoke-Command -ComputerName (Get-ADDomainController -Filter *).Name -ScriptBlock {
    $Account = Get-ADServiceAccount -Filter { Name -eq 'svcadhealthcheck'}
    Install-ADServiceAccount $Account

    # Vérifie que le GMSA fonctionne sur l'ordinateur
    # Renvoie $True si les tests sont OK
    $Test = Test-ADServiceAccount -Identity $Account.Name
    if($Test){
        Write-Output "GMSA test OK on $env:computername"
    }
    else {
        Write-Output "GMSA test FAILED on $env:computername"
    }

}

Donner à gMSA l’autorisation d’exécuter un travail en lot

Une fois que le gMSA est installé, vous devrez maintenant lui donner l’autorisation d’exécuter un travail en lot sur les DC. Le compte a besoin de ce droit car il fonctionnera de manière autonome en arrière-plan dans une tâche planifiée.

Vous pouvez définir cette autorisation via un GPO existant ou en créant un nouveau GPO et en le liant à l’OU Contrôleurs de domaine. Si vous n’avez pas déjà de GPO à utiliser, voici quelques étapes que vous pouvez suivre pour en créer un.

  1. Lancez l’éditeur de stratégie de groupe Group Policy sur un DC.
  2. Faites un clic droit sur l’OU Contrôleurs de domaine et sélectionnez Créer un GPO dans ce domaine et le lier ici.
  3. Nommez-le DC – Connexion en tant que lot ou un autre nom que vous préférez
  4. Faites un clic droit sur le GPO et cliquez sur Modifier.
  5. Allez à Configuration de l’ordinateur -> Paramètres Windows -> Paramètres de sécurité -> Affectation des droits utilisateur.
  6. Cliquez sur le bouton gauche de la souris sur Se connecter en tant que lot et cliquez sur Propriétés.
  7. Cliquez sur Ajouter utilisateur ou groupe
  8. Cliquez sur Types d’objets, sélectionnez uniquement Comptes de service et cliquez sur OK.
  9. Recherchez le compte de service svcADHealthCheck créé précédemment, sélectionnez-le et cliquez sur OK.

Vous devriez maintenant voir le compte gMSA dans la liste des objets AD comme indiqué ci-dessous.

gMSA given rights to logon as a batch job

Création de la tâche planifiée

Maintenant que vous avez créé un compte pour exécuter les tâches planifiées, vous pouvez maintenant créer la tâche planifiée elle-même sur un serveur rejoint au domaine de votre choix.

Vous pouvez créer la tâche planifiée via l’interface graphique, mais cela nécessite trop de clics ! Au lieu de cela, je vous recommande de le faire avec PowerShell. Pourquoi ? Parce que vous pouvez simplement copier le code que vous voyez ci-dessous et c’est tout.

Vous trouverez ci-dessous deux scripts; les deux scripts sont similaires, mais l’un suppose un compte utilisateur AD et l’autre suppose un gMSA. Assurez-vous d’utiliser le script approprié en fonction du compte que vous utilisez.

# Remplacez par le chemin d'accès à votre script
$ScriptPath = "C:\Scripts\ADHealthCheck.ps1"
# Remplacez par le nom d'utilisateur du compte que vous avez créé pour exécuter la tâche
$UserName = "svdADHealthCheck"

# Remplacez par le mot de passe que vous avez défini pour le compte ci-dessus
$Password = "JägareTvå!"
# Créez l'action qui lance le script
$Action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-ExecutionPolicy bypass -File '$ScriptPath'"
# Créez le déclencheur qui démarre la tâche
$Trigger = New-ScheduledTaskTrigger -Once -At "12:00" -RepetitionInterval (New-TimeSpan -Hours 12)
# Créez des paramètres pour la tâche planifiée
$Settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries -StartWhenAvailable -RunOnlyIfNetworkAvailable -DontStopOnIdleEnd
# Créez la tâche planifiée en utilisant un splat pour la lisibilité
$Splat = @{
    User = "$env:USERDOMAIN\$UserName"
    Password = $Password
    TaskName = "ADHealthCheck"
    Action = $Action
    Trigger = $Trigger
    RunLevel = "Highest"
    Settings = $Settings
}
Register-ScheduledTask @Splat
# Remplacez par le chemin d'accès à votre script
$ScriptPath = "C:\Scripts\ADHealthCheck.ps1"
# Remplacez par le nom d'utilisateur du compte que vous avez créé pour exécuter la tâche
$UserName = "svdADHealthCheck$"
# Créez l'action qui lance le script
$Action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-ExecutionPolicy bypass -File '$ScriptPath'"
# Créez le déclencheur qui démarre la tâche
$Trigger = New-ScheduledTaskTrigger -Once -At "12:00" -RepetitionInterval (New-TimeSpan -Hours 12)
# Créez des paramètres pour la tâche planifiée
$Settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries -StartWhenAvailable -RunOnlyIfNetworkAvailable -DontStopOnIdleEnd

# Créez un principal qui définit le GMSA
$Principal = New-ScheduledTaskPrincipal -UserID "$env:USERDOMAIN\$UserName" -LogonType Password -RunLevel Highest
# Créez la tâche planifiée en utilisant un splat pour la lisibilité
$Splat = @{
    Principal = $Principal
    TaskName = "ADHealthCheck"
    Action = $Action
    Trigger = $Trigger
    RunLevel = "Highest"
    Settings = $Settings
}
Register-ScheduledTask @Splat

Vous avez terminé ! À ce stade, la tâche planifiée s’exécutera à l’intervalle fourni dans l’un des scripts ci-dessus.

Résumé

Whew! Si vous avez suivi depuis la première partie, vous devriez maintenant savoir que la santé d’AD est un sujet complexe. Il y a tellement à dire sur ce sujet qu’il ne suffirait même pas de deux articles de blog détaillés.

Mais, à ce stade, vous devriez avoir suffisamment de connaissances et un framework PowerShell pré-construit que vous pouvez intégrer à d’autres vérifications de santé d’Active Directory au fur et à mesure qu’elles se présentent.

Lecture complémentaire

Source:
https://adamtheautomator.com/active-directory-health-check-2/