Adam der Automator

Dies ist Teil II einer zweiteiligen Serie über Active Directory-Integritätsprüfungen. Obwohl Sie nicht unbedingt lesen müssen, wenn Sie erfahren möchten, wie das PowerShell-Skript, über das Sie in diesem Artikel erfahren werden, erstellt wurde, sollten Sie sich das Erstellen eines Active Directory-Integritätsprüfungstools ansehen : Teil I.

In Teil I haben Sie erfahren, wie viele verschiedene multiple Tests und warum sie wichtig sind. Lassen Sie uns nun alle zusammen ziehen und ein Werkzeug bauen. In diesem Teil konvertieren Sie alle in Teil I erläuterten Active Directory-Integritätsprüfungen in ein Testframework. Sie erfahren auch, wie Sie Ergebnisse verschiedener Anzeigenzustandsprüfungen an Tools wie Pester und ein Überwachungstool namens PRTG ausgeben.

Laden Sie das Skript ADHealthCheck-NoResult.ps1 von GitHub herunter, um zu folgen oder eine fertige Version des Tools zu sehen, über das Sie in diesem Artikel erfahren werden.

Definieren der Ausgabe

Wenn Sie einen gemeinsamen Objekttyp und eine einfache Möglichkeit zur Generierung haben, können Sie die Testergebnisse viel einfacher in das Tool Ihrer Wahl konvertieren.

Um eine einheitliche Ausgabe für alle potenziellen Tools zu erstellen, habe ich mich für eine PowerShell-Klasse entschieden. Obwohl dies nicht erforderlich ist, habe ich mich hier für diesen Ansatz entschieden. Der Hauptpunkt besteht darin, sicherzustellen, dass alle Anzeigenzustandsprüfungen denselben Ausgabetyp zurückgeben.

Eine PowerShell-Klasse ist ein Schema, das definiert, wie ein PowerShell-Objekt aussehen und was es tun soll. Jede Zeile, die Sie unten sehen, repräsentiert eine Eigenschaft, die die zurückgegebenen Objekte haben werden. Sie können unten sehen, dass ich bei jeder Anzeigenzustandsprüfung plane, zehn Eigenschaften zurückzugeben.

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

Um diese Klassenerstellung zu beschleunigen, verwende ich eine Hilfsfunktion namens New-AdhcResult . Diese Funktion erstellt die Klasse und alles, was Sie benötigen, um zu folgen. Diese Funktion gibt ein benutzerdefiniertes Objekt vom Typ aus.

Ausführen des AD-Integritätsprüfungstools

Laden Sie zunächst das AD-Integritätsprüfungsskript herunter und kopieren Sie es auf einen Domänencontroller. Öffnen Sie es mit der PowerShell ISE und führen Sie es aus. Dieser Teil des Tools gibt keine Informationen zurück.

Dieses Skript wird ausgeführt und speichert das Ergebnis jeder Prüfung in der Variablen $TestResults als mehrere Objekte. Sie verwenden diese Objekte später, um Berichte zu generieren oder in verschiedene Werkzeuge auszugeben. Wenn Sie health check results in einer Variablen wie dieser halten, können Sie weitere Ergebnisse hinzufügen, wenn Sie ein anderes erstellen und den Befehl New-AdHcResult verwenden.

Sobald das Skript ausgeführt wurde, sollten Sie nun einen vollständigen Satz von AD Health Check-Objekten in der Variablen $TestResults gespeichert haben. Sie können jetzt $TestResults von der Konsole aus ausführen und die Rohergebnisse anzeigen.

Anzeigen der Ergebnisse der Anzeigenintegritätsprüfung in Tools

Da sich alle Prüfungen in einem gemeinsamen Objekttyp befinden, können Sie sie besser mit einigen Tools wie Pester und PRTG überprüfen.

In diesem Abschnitt erfahren Sie, wie Sie einen HTML-Bericht mit dem Tool extent erstellen und in PRTG anzeigen.

Erstellen einer NUnit-XML-Datei mit Pester

Sie müssen zuerst die PowerShell-Objekte in ein Format konvertieren, das Ihre Tools verstehen können. Die meisten Tools verstehen XML oder genauer gesagt NUnit XML. Dies ist ein Format, das Sie in verschiedene Tools importieren können, um Ergebnisse anzuzeigen.

Da Sie mit PowerShell arbeiten, verwenden Sie das Pester-Testframework, um die Ausgabe des AD-Integritätsprüfungsskripts zu lesen und eine NUnit-XML-Datei zu generieren

Laden Sie zunächst die neueste Version von Pester herunter. Sie können Pester herunterladen, indem Sie Install-Module in einer erhöhten PowerShell-Konsole ausführen. Der folgende Befehl erzwingt die Installation der neuesten Pester-Version. Da das Publisher-Zertifikat, mit dem Pester signiert ist, mit Windows 10 geliefert wird, müssen wir den Parameter SkipPublisherCheck verwenden, um es zu installieren.

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

Sobald Pester verfügbar ist, können Sie das Skript ausführen und dynamisch eine Reihe von Pester-Tests erstellen.

Hinweis: Sie können Pester-Tests auch selbst erstellen, ohne das von mir bereitgestellte PowerShell-Skript zu verwenden.

Das folgende PowerShell-Skript verwendet Pester, um eine NUnit-XML-Datei aus der Ausgabe der Variablen $TestResults zu generieren, die im Skript ADHealthCheck-NoResult.ps1 definiert ist.

Speichern Sie diese Datei als Pester.ps1 im selben Ordner wie das AD Health Check-Skript.

# 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 } } } }}

Führen Sie schließlich Invoke-Pester aus, um den Pester aufzurufen.ps1-Datei und speichern Sie die Ergebnisse im Format NUnitXml.

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

Erstellen eines HTML-Berichts mit dem Extent-Tool

Sobald Sie die NUnit-XML-Datei haben, können Sie diese Datei jetzt an ein Tool übergeben, das diese in HTML konvertieren kann. Eines dieser Tools heißt extent. Extent ist ein praktisches Tool zum Erstellen von HTML-Berichten aus Nunit-XML-Dateien.

Laden Sie extent zunächst in dasselbe Verzeichnis wie den NunitReport herunter.zuvor erstellte XML-Datei. Führen Sie dann die folgenden Befehle in einer PowerShell-Sitzung aus. Diese Befehle erstellen das Verzeichnis zum Speichern der HTML-Dateien und führen es dann aus.exe, um die Konvertierung durchzuführen.

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

Wenn Sie fertig sind, finden Sie zwei HTML-Dateien im Verzeichnis HTMLReports. Diese Dateien sehen aus wie die folgenden Screenshots, wenn Sie sie mit einem Webbrowser öffnen.

AD Health Check-Ergebnisse in PRTG

PRTG ist ein beliebtes Monitoring-Tool von Paessler, mit dem Sie Ihre Infrastruktur und Services überwachen können. In diesem Abschnitt erfahren Sie, wie Sie die Ergebnisse der Integritätsprüfung nach Ausführung des Integritätsprüfungsskripts an PRTG übertragen.

Das Übertragen von Ergebnissen an PRTG erfordert zwar mehr Arbeit, als dass das Tool Informationen abrufen muss, aber Sie werden schließlich feststellen, dass sich das Setup lohnt.

Voraussetzungen

Um PRTG erfolgreich als Monitoring-Tool für das in diesem Artikel erstellte Skript AD Health Check einzurichten, müssen Sie:

• PRTG installiert und konfiguriert
• Alle Domänencontroller in PRTG einrichten
• Die Send-AdhcResultToPrtg.ps1 PowerShell-Skript von GitHub heruntergeladen
• die URL und der Port von y0ur PRTG Sensor

Wenn Sie alle Voraussetzungen erfüllt haben, können Sie den folgenden schrittweisen Anweisungen folgen, wie ich empfehle, diese Ergebnisse der Anzeigenzustandsprüfung an PRTG zu übertragen.

1. Erstellen Sie in PRTG ein Gerät namens Domain oder einen beliebigen Namen.
2. Erstellen Sie einen erweiterten HTTP-Push-Sensor mit einem IdentityToken von directory-adhealthcheck. Beachten Sie, dass dies case sensitive ist!
3. Erstellen Sie für jedes Domänencontroller-Gerät in PRTG einen erweiterten HTTP-Push-Sensor. Hängen Sie für jedes IdentityToken jeden Sensor mit -adhealthcheck an, z. B. dc01-adhealthcheck.
4. Fügen Sie den Inhalt des PowerShell-Skripts Send-AdhcResultToPrtg.ps1 am Ende des PowerShell-Skripts ADHealthCheck-NoResult.ps1 hinzu, das wir behandelt haben.
5. Ändern Sie die Variable $PRTGUrl in die URL und den Port Ihres PRTG Sensors.
6. Führen Sie das Skript aus.

Sobald das AD Health Check-Skript abgeschlossen ist, sollte es nun den Status wie unten gezeigt an Ihre PRTG-Sensoren senden.

Planen des Active Directory-Integritätsprüfungsskripts

Die Überwachung des AD-Zustands ist ein fortlaufender Prozess. Sie sollten die ganze Zeit Tests ausführen, anstatt Ad-hoc-Instanzen. Lassen Sie uns das Active Directory-Integritätsprüfungsskript so planen, dass es in regelmäßigen Abständen ausgeführt wird.

Der einfachste Weg, diese Prüfungen zu automatisieren, besteht darin, das Skript zum Taskplaner hinzuzufügen und es unter einem AD-Benutzerkonto oder einem gruppenverwalteten Dienstkonto ausführen zu lassen.

Die Verwendung eines gruppenverwalteten Dienstkontos (Group Managed Service Account, gMSA) ist die sicherere Methode zur autonomen Ausführung geplanter Aufgaben, da nur bestimmte Computerkonten das Kennwort von AD abrufen können. Aber einige Organisationen haben diesen Luxus möglicherweise nicht.

Erstellen eines AD-Benutzerkontos

Lassen Sie uns zunächst aufschlüsseln, was erforderlich ist, um ein AD-Benutzerkonto für die Ausführung der geplanten Aufgabe einzurichten.

Wenn Sie eine geplante Aufgabe als Benutzerkonto ausführen, führen Sie sie auf keinen Fall als Ihr eigenes Konto aus! Erstellen Sie zu diesem Zweck immer ein separates Benutzerkonto.

Um Zeit zu sparen, sehen Sie unten ein PowerShell-Skript. Dies ist ein Beispielskript, mit dem Sie ein AD-Benutzerkonto erstellen können, das Teil der Gruppe Domänenadministratoren ist. Mit diesem Konto können Sie dann geplante Aufgaben ausführen.

# 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

Erstellen eines gruppenverwalteten Dienstkontos

Die Verwendung einer gMSA zum Ausführen der Integritätsprüfung ist etwas schwieriger, wenn Sie gMSA in Ihrer Umgebung nicht bereits verwenden, aber es ist viel sicherer.

Erstellen eines KDS-Stammschlüssels

Um ein gMSA-Konto für die Ausführung des AD-Integritätsprüfungsskripts zu erstellen, fügen Sie zunächst einen KDS-Stammschlüssel hinzu, falls Sie noch keinen haben. Sie können überprüfen, ob Sie über einen KDS-Stammschlüssel verfügen, indem Sie den PowerShell-Befehl Get-KDSRootKey auf einem Domänencontroller ausführen.

Wenn Sie keinen KDS-Stammschlüssel haben, erstellen Sie einen, indem Sie Add-KDSRootKey -EffectiveImmediately unter einem Benutzerkonto der AD-Gruppe Domänenadministratoren auf einem Domänencontroller 2012R2 oder höher ausführen.

Der Schlüssel muss auf die anderen Domänencontroller repliziert werden, damit er voll wirksam wird. Weitere Informationen zu diesem Prozess finden Sie in der Microsoft-Dokumentation.

Erstellen der gMSA

Sobald der KDS-Stammschlüssel erstellt wurde, können Sie das gMSA-Konto mit PowerShell erstellen. Unten sehen Sie ein Beispielskript zum Erstellen des gMSA-Kontos, das nur von einem Domänencontroller in der Gruppe Domänenadministratoren authentifiziert werden darf.

# 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`$"

Installieren und Testen der gMSA

Nachdem die gMSA erstellt wurde, besteht der letzte Schritt darin, sie auf allen Domänencontrollern zu installieren und zu testen. Eine Möglichkeit, dies zu tun, ist die Verwendung des PowerShell-Befehls Invoke-Command. Unten sehen Sie ein PowerShell-Skript, das die gMSA auf allen DCs installiert und sicherstellt, dass sie ordnungsgemäß funktioniert.

# 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" }}

Erteilen der gMSA-Berechtigung zur Ausführung als Batchjob

Sobald die gMSA installiert ist, müssen Sie ihr nun die Berechtigung zur Ausführung als Batchjob auf dem DCs erteilen. Das Konto benötigt dieses Recht, da es in einer geplanten Aufgabe autonom im Hintergrund ausgeführt wird.

Sie können diese Berechtigung über ein vorhandenes Gruppenrichtlinienobjekt festlegen oder ein neues Gruppenrichtlinienobjekt erstellen und mit der Organisationseinheit Domänencontroller verknüpfen. Wenn Sie noch kein Gruppenrichtlinienobjekt verwenden möchten, finden Sie im Folgenden einige Schritte zum Erstellen eines Gruppenrichtlinienobjekts.

1. Starten Sie den Gruppenrichtlinien-Editor auf einem DC.
2. Klicken Sie mit der rechten Maustaste auf die Organisationseinheit Domänencontroller, wählen Sie Gruppenrichtlinienobjekt in dieser Domäne erstellen aus und verknüpfen Sie es hier.
3. Nennen Sie es DC – Logon als batch oder einen anderen Namen, den Sie bevorzugen
4. Klicken Sie mit der rechten Maustaste auf das Gruppenrichtlinienobjekt und klicken Sie auf Bearbeiten.
5. Gehen Sie zu Computerkonfiguration -> Windows–Einstellungen –> Sicherheitseinstellungen -> Zuweisung von Benutzerrechten.
6. Klicken Sie mit der linken Maustaste auf Als Stapelauftrag anmelden und klicken Sie auf Eigenschaften.
7. Klicken Sie auf Benutzer oder Gruppe hinzufügen.
8. Klicken Sie auf Objekttypen, wählen Sie nur Dienstkonten aus und klicken Sie auf OK.
9. Suchen Sie nach dem zuvor erstellten svcADHealthCheck-Dienstkonto, wählen Sie es aus und klicken Sie auf OK.

Sie sollten nun die gMSA unter der Liste der Anzeigenobjekte sehen, wie unten gezeigt.

Erstellen der geplanten Aufgabe

Nachdem Sie nun ein Konto zum Ausführen der geplanten Aufgaben erstellt haben, können Sie die geplante Aufgabe selbst auf einem domänengebundenen Server Ihrer Wahl erstellen.

Sie können die geplante Aufgabe über die GUI erstellen, aber das ist zu viel Klicken! Stattdessen empfehle ich, es mit PowerShell zu erstellen. Warum? Weil Sie einfach den Code kopieren können, den Sie unten sehen, und damit fertig sind.

Unten finden Sie zwei Skripte; beide Skripte sind ähnlich, aber eines geht von einem AD-Benutzerkonto und das andere von einem gMSA aus. Stellen Sie sicher, dass Sie das entsprechende Skript verwenden, je nachdem, welches Konto Sie verwenden.

# 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

Du bist fertig! Zu diesem Zeitpunkt wird die geplante Aufgabe in dem in einem der obigen Skripte angegebenen Intervall ausgeführt.

Zusammenfassung

Puh! Wenn Sie den ganzen Weg von Teil I gefolgt sind, sollten Sie inzwischen wissen, dass AD Health ein tiefes Thema ist. Es gibt so viel zu diesem einen Thema, dass nicht einmal zwei lange Blogbeiträge abdecken könnten.

Inzwischen sollten Sie jedoch über ausreichende Kenntnisse und ein vorgefertigtes PowerShell-Framework verfügen, mit dem Sie andere Active Directory-Integritätsprüfungen bei Bedarf einbinden können.

Weiterführende Literatur

• Einige Dinge, die Sie möglicherweise nicht über AD und Disaster Recovery wissen
• Was macht DCDIAG eigentlich …?