Adam l’Automateur

Il s’agit de la partie II d’une série en deux parties sur les vérifications de l’état d’Active Directory. Bien que la lecture ne soit pas obligatoire, si vous souhaitez savoir comment le script PowerShell que vous apprendrez dans cet article a été construit, nous vous encourageons à consulter Créer un outil de vérification de l’état d’Active Directory: Partie I.

Dans la partie I, vous avez appris combien de tests multiples différents et pourquoi ils sont importants. Maintenant, rassemblons-les tous et construisons un outil. Dans cette partie, vous allez convertir tous les contrôles d’intégrité d’Active Directory expliqués dans la partie I en un framework de test. Vous apprendrez également à produire les résultats de diverses vérifications de l’état des PUBLICITÉS dans des outils tels que Pester et un outil de surveillance appelé PRTG.

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

Définir la sortie

Ayant un type d’objet commun et un moyen facile de le générer rendra beaucoup plus facile la conversion des résultats de test 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 ce ne soit pas obligatoire, c’est l’approche que j’ai choisi de prendre ici. Le point principal est de s’assurer que tous les contrôles d’intégrité des ANNONCES renvoient le même type de sortie.

Une classe PowerShell est un schéma qui définit l’apparence d’un objet PowerShell et ce qu’il doit faire. Chaque ligne que vous voyez ci-dessous représente une propriété que les objets renvoyés auront. Vous pouvez voir ci-dessous que je prévois sur chaque bilan de santé de l’annonce de renvoyer dix propriétés.

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

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

Exécution de l’outil de vérification de l’état de l’annonce

Tout d’abord, téléchargez et copiez le script de vérification de l’état de l’annonce dans un contrôleur de domaine. Ouvrez-le avec l’ Power PowerShell et exécutez-le. Cette partie de l’outil ne retournera aucune information.

Ce script s’exécutera et stockera le résultat de chaque vérification dans la variable $TestResults sous forme de plusieurs objets . Vous utiliserez ces objets plus tard pour générer des rapports ou les produire dans divers outils. Maintenir les résultats de vérification de l’état dans une variable comme celle-ci 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 l’état de l’annonce stockés dans la variable $TestResults. Vous pouvez maintenant exécuter $TestResults à partir de la console et voir les résultats bruts.

L’affichage des résultats de la vérification de l’état des ANNONCES dans les outils

Étant donné que toutes les vérifications sont dans un type d’objet commun, vous pouvez mieux les inspecter à l’aide de quelques outils tels que Pester et PRTG.

Dans cette section, vous allez apprendre à 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 que vos outils peuvent comprendre. La plupart des outils comprennent XML ou, plus spécifiquement, XML nUnit. Il s’agit d’un format que vous pouvez importer dans divers outils pour afficher les résultats.

Puisque vous travaillez avec PowerShell, vous utiliserez le framework de test Pester pour lire la sortie du script de vérification de l’état de l’annonce et générer un fichier XML nUnit

Commencez par télécharger la dernière version de Pester. Vous pouvez télécharger Pester en exécutant Install-Module dans une console PowerShell surélevée. La commande ci-dessous forcera l’installation de la dernière version de Pester. Étant donné que le certificat d’éditeur avec lequel Pester est signé est fourni 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 ensuite exécuter le script et créer dynamiquement un ensemble de tests Pester.

Remarque: Vous pouvez également créer vous-même des tests Pester 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 l’état de l’annonce.

# dot source in the ADHealthCheck file. $PSScriptRoot\ADHealthCheck-NoResult.ps1$Grouped = $TestResults | Group-Object CategoryForeach($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 appeler le Pester.fichier ps1 et enregistrez les résultats au format NUnitXml.

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

Création d’un rapport HTML avec l’outil Extent

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

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

# Create report directoryPS51> mkdir .\HTMLReports# Create the reportPS51> .\extent.exe -i .\NunitReport.xml -o .\HTMLReports\

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

Intégration des résultats du bilan de santé des PUBLICITÉS 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 à transmettre les résultats du bilan de santé à PRTG une fois le script de bilan de santé exécuté.

Pousser les résultats vers PRTG demande plus de travail plutôt que d’avoir les informations d’extraction de l’outil, mais vous verrez finalement que la configuration vaut bien le temps passé.

Prérequis

Pour configurer avec succès PRTG en tant qu’outil de surveillance du script de vérification de l’état des ANNONCES intégré dans cet article, assurez-vous d’avoir:

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

Si vous avez effectué chacune des conditions préalables, vous pouvez suivre les instructions étape par étape ci-dessous sur la façon dont je recommande de transmettre ces résultats de vérification de l’état des publicités à PRTG.

1. Créez un périphérique dans PRTG appelé Domain ou le nom que vous préférez.
2. Créez un capteur push HTTP avancé avec un IdentityToken de directory-adhealthcheck. Notez que cela est sensible à la casse!
3. Pour chaque périphérique contrôleur de domaine dans PRTG, créez un capteur push HTTP avancé. Pour chaque IdentityToken, ajoutez chaque capteur avec -adhealthcheck tel que 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. Remplacez la variable $PRTGUrl par l’URL et le port de votre capteur PRTG.
6. Exécutez le script.

Une fois le script de vérification de l’état de l’annonce terminé, il devrait maintenant transmettre l’état à vos capteurs PRTG, comme indiqué ci-dessous.

La planification du script de vérification de l’état d’Active Directory

La surveillance de l’état des ANNONCES est un processus continu. Vous devriez exécuter des tests tout le temps plutôt que des instances ad hoc. Planifions l’exécution du script de vérification de l’état d’Active Directory à intervalles fréquents.

La voie la plus simple pour automatiser ces vérifications consiste à ajouter le script au planificateur de tâches et à le laisser s’exécuter sous un compte d’utilisateur AD ou un compte de service géré par un groupe.

L’utilisation d’un compte gMSA (Group Managed Service Account) est le moyen le plus sûr 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 d’AD. Mais certaines organisations peuvent ne pas avoir ce luxe.

Création d’un Compte d’utilisateur AD

Voyons d’abord ce qu’il faut pour configurer un compte d’utilisateur AD pour exécuter la tâche planifiée.

Si vous allez exécuter une tâche planifiée en tant que compte d’utilisateur, ne l’exécutez pas en tant que votre propre compte ! Créez toujours un compte utilisateur séparé à cet effet.

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

# Change this to the OU of your service accounts$OU = "OU=Service Accounts,DC=contoso,DC=com"# Change this to the password that you want to use for the account$Password = "JägareTvå"$SecureString = $Password | ConvertTo-SecureString -AsPlainText -ForceNew-ADUser -Enabled $True -Path $OU -Name svcADHealthCheck -AccountPassword $SecureString# Restrict account to only Domain Controllers$DomainControllers = (Get-ADDomainController -Filter *).NameSet-ADAccount -Identity svcADHealthCheck -LogonWorkstations ($DomainControllers -Join ",")# Making it Domain Admin (Sorry)Add-ADGroupMember -Identity "Domain Admins" -Members svcADHealthCheck

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

L’utilisation d’un gMSA pour exécuter le bilan de santé est un peu plus délicate 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 pour exécuter le script de vérification de l’état de l’annonce, 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 en créez une en exécutant Add-KDSRootKey -EffectiveImmediately sous un compte utilisateur faisant partie du groupe AD Admins de domaine 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 pleinement 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 uniquement autorisé à s’authentifier à partir d’un contrôleur de domaine dans le groupe Admins de domaine.

# Change to your domain$Domain = "contoso.com"$AccountName = "svcadhealthcheck"# Create a GMSA called svcadhealthcheck (or in reality svcadhealthcheck$) and allow only Domain Controllers to fetch the passwordNew-ADServiceAccount $AccountName -DNSHostName "$AccountName.$Domain" –PrincipalsAllowedToRetrieveManagedPassword "Domain Controllers"# Add the GMSA to Domain Admins# Note that we're adding the the account by it's true SamAccountName '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 CD et s’assurera qu’il fonctionne correctement.

# This will run on all Domain ControllersInvoke-Command -ComputerName (Get-ADDomainController -Filter *).Name -ScriptBlock { $Account = Get-ADServiceAccount -Filter { Name -eq 'svcadhealthcheck'} Install-ADServiceAccount $Account # Tests that the GMSA works on the computer # Returns $True if tests are 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 à la gMSA l’autorisation de s’exécuter en tant que tâche par lots

Une fois que la gMSA est installée, vous devez maintenant lui donner l’autorisation de s’exécuter en tant que tâche par lots sur le DCs. Le compte a besoin de ce droit car il s’exécutera 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 aux OU des contrôleurs de domaine. Si vous n’avez pas encore de GPO à utiliser, voici quelques étapes que vous pouvez suivre pour en créer un.

1. Lancez l’éditeur de stratégie de groupe sur un DC.
2. Cliquez avec le bouton droit sur l’unité d’organisation des contrôleurs de domaine et sélectionnez Créer un GPO dans ce domaine et liez-le ici.
3. Nommez-le DC-Logon en tant que lot ou un autre nom que vous préférez
4. Cliquez avec le bouton droit sur le GPO et cliquez sur Modifier.
5. Accédez à Configuration de l’ordinateur – > Paramètres Windows – > Paramètres de sécurité – > Attribution des droits de l’utilisateur.
6. Cliquez avec le bouton gauche sur Se connecter en tant que travail par lots et cliquez sur Propriétés.
7. Cliquez sur Ajouter un utilisateur ou un 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 gMSA sous la liste des objets AD comme indiqué ci-dessous.

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 associé à un domaine de votre choix.

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

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

# Replace with the path to your script$ScriptPath = "C:\Scripts\ADHealthCheck.ps1"# Replace with the username of the account that you created to run the task$UserName = "svdADHealthCheck"# Replace with the password that you set for above account$Password = "JägareTvå!"# Create the action that launches the script$Action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-ExecutionPolicy bypass -File '$ScriptPath'"# Create the trigger that starts the task$Trigger = New-ScheduledTaskTrigger -Once -At "12:00" -RepetitionInterval (New-TimeSpan -Hours 12)# Create settings for the scheduled task$Settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries -StartWhenAvailable -RunOnlyIfNetworkAvailable -DontStopOnIdleEnd# Create the scheduled task using a splat for readability$Splat = @{ User = "$env:USERDOMAIN$UserName" Password = $Password TaskName = "ADHealthCheck" Action = $Action Trigger = $Trigger RunLevel = "Highest" Settings = $Settings}Register-ScheduledTask @Splat

# Replace with the path to your script$ScriptPath = "C:\Scripts\ADHealthCheck.ps1"# Replace with the username of the account that you created to run the task$UserName = "svdADHealthCheck$"# Create the action that launches the script$Action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-ExecutionPolicy bypass -File '$ScriptPath'"# Create the trigger that starts the task$Trigger = New-ScheduledTaskTrigger -Once -At "12:00" -RepetitionInterval (New-TimeSpan -Hours 12)# Create settings for the scheduled task$Settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries -StartWhenAvailable -RunOnlyIfNetworkAvailable -DontStopOnIdleEnd# Create principal that defines the GMSA$Principal = New-ScheduledTaskPrincipal -UserID "$env:USERDOMAIN$UserName" -LogonType Password -RunLevel Highest# Create the scheduled task using a splat for readability$Splat = @{ Principal = $Principal TaskName = "ADHealthCheck" Action = $Action Trigger = $Trigger RunLevel = "Highest" Settings = $Settings}Register-ScheduledTask @Splat

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

Résumé

Ouf! Si vous avez suivi tout le chemin de la première partie, vous devez savoir maintenant que la santé de l’annonce est un sujet profond. Il y a tellement de choses à ce sujet que même deux longs articles de blog ne pourraient pas couvrir.

Mais, à ce jour, vous devriez avoir suffisamment de connaissances et un framework PowerShell pré-construit pour pouvoir brancher d’autres contrôles d’intégrité Active Directory au fur et à mesure qu’ils surviennent.

Lectures supplémentaires

• Certaines choses que vous ne savez peut-être pas sur la reprise après sinistre et la reprise après sinistre
• Que fait réellement DCDIAG…?