Active Directory Health Check mit PowerShell Framework

Dies ist Teil II einer zweiteiligen Serie über Active Directory-Gesundheitsprüfungen. Obwohl dies nicht erforderlich ist, wenn Sie erfahren möchten, wie das PowerShell-Skript, über das Sie in diesem Artikel lesen werden, erstellt wurde, empfehle ich Ihnen, Building an Active Directory Health Check Tool [In-Depth]: Part I zu überprüfen.

In Teil I haben Sie gelernt, wie viele verschiedene Tests es gibt und warum sie wichtig sind. Lassen Sie uns sie nun alle zusammenführen und ein Tool erstellen. In diesem Teil werden alle im ersten Teil erklärten Active Directory-Gesundheitsprüfungen in ein Testframework umgewandelt. Sie lernen auch, wie Sie Ergebnisse verschiedener AD-Gesundheitsprüfungen an Tools wie Pester und ein Überwachungstool namens PRTG weiterleiten.

Um den Fortschritt zu verfolgen oder eine fertige Version des in diesem Artikel vorgestellten Tools zu sehen, laden Sie das Skript ADHealthCheck-NoResult.ps1 von GitHub herunter.

Definition der Ausgabe

Eine gemeinsame Objektart und eine einfache Möglichkeit zu deren Generierung zu haben, erleichtert die Umwandlung von Testergebnissen in das von Ihnen gewählte Tool erheblich.

Um eine einheitliche Ausgabe für alle möglichen Tools zu erstellen, habe ich mich für eine PowerShell-Klasse entschieden. Obwohl nicht erforderlich, ist dies der Ansatz, den ich hier gewählt habe. Der Hauptpunkt besteht darin, sicherzustellen, dass alle AD-Gesundheitsprüfungen denselben Typ von Ausgabe zurückgeben.

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
}

Um diese Klassen-Erstellung zu beschleunigen, werde ich eine Hilfsfunktion namens New-AdhcResult verwenden. Diese Funktion erstellt die Klasse und alles, was Sie benötigen, um fortzufahren. Diese Funktion gibt ein benutzerdefiniertes [AdhcResult]-Objekt aus.

Das Ausführen des AD Health Check-Tools

Zuerst laden Sie das AD Health Check-Skript herunter und kopieren 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.

Das Skript wird ausgeführt und das Ergebnis jeder Überprüfung wird in der Variablen $TestResults als mehrere [AdhcResult]-Objekte gespeichert. Sie werden diese Objekte später verwenden, um Berichte zu erstellen oder sie in verschiedene Tools auszugeben. Das Speichern von Health-Check-Ergebnissen in einer Variablen wie dieser ermöglicht es Ihnen, weitere Ergebnisse hinzuzufügen, falls Sie sich entscheiden, ein weiteres zu erstellen und den Befehl New-AdHcResult zu verwenden.

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

Anzeigen von AD Health Check-Ergebnissen in Tools

Da alle Überprüfungen einen gemeinsamen Objekttyp haben, können Sie sie besser durch ein paar Tools wie Pester und PRTG inspizieren.

In diesem Abschnitt lernen Sie, wie Sie einen HTML-Bericht mit einem Tool namens extent erstellen und den Bericht in PRTG anzeigen.

Erstellen einer nUnit XML-Datei mit Pester

Sie müssen zunächst 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 aus dem AD-Gesundheitsüberprüfungsskript zu lesen und eine nUnit-XML-Datei zu generieren

Beginnen Sie damit, die neueste Version von Pester herunterzuladen. 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 der Herausgeber 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 auch Pester-Tests 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 $TestResults-Variable 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.

# Punktquelle in der ADHealthCheck-Datei
. $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
                }
            }
        }
    }
}

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

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 weitergeben, das sie in HTML konvertieren kann. Eines dieser Tools nennt sich Extent. Extent ist ein praktisches Tool zur Erstellung von HTML-Berichten aus Nunit-XML-Dateien.

Zuerst laden Sie Extent herunter in das gleiche Verzeichnis wie die Datei NunitReport.xml, die zuvor erstellt wurde. 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 dann extent.exe zur Konvertierung aus.

# Berichtsverzeichnis erstellen
PS51> mkdir .\HTMLReports

# Bericht erstellen
PS51> .\extent.exe -i .\NunitReport.xml -o .\HTMLReports\

Wenn abgeschlossen, finden Sie zwei HTML-Dateien im Verzeichnis HTMLReports. Diese Dateien sehen ähnlich aus wie die unten dargestellten Screenshots, wenn Sie sie mit einem Webbrowser öffnen.

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

Einlesen der AD-Health-Check-Ergebnisse in PRTG

PRTG ist ein beliebtes Überwachungstool, das von Paessler entwickelt wurde und das Sie zur Überwachung Ihrer Infrastruktur und Dienste verwenden können. In diesem Abschnitt erfahren Sie, wie Sie die Ergebnisse des Gesundheitschecks an PRTG senden, sobald das Skript für den Gesundheitscheck ausgeführt wurde.

Das Senden von Ergebnissen an PRTG erfordert mehr Arbeit, als Informationen abzurufen, aber Sie werden mit der Zeit feststellen, dass die Einrichtung die aufgewendete Zeit wert ist.

Voraussetzungen

Um PRTG erfolgreich als Überwachungstool für das in diesem Artikel erstellte AD-Gesundheitsprüfungsskript einzurichten, stellen Sie sicher, dass Sie folgendes haben:

  • PRTG installiert und konfiguriert
  • Alle Domänencontroller in PRTG eingerichtet
  • Das Send-AdhcResultToPrtg.ps1-PowerShell-Skript von GitHub heruntergeladen
  • Die URL und Port Ihres PRTG-Sensors

Wenn Sie alle Voraussetzungen erfüllt haben, können Sie den nachstehenden Schritt-für-Schritt-Anweisungen folgen, wie ich empfehle, diese AD-Gesundheitsprüfungsergebnisse an PRTG zu senden.

  1. Erstellen Sie in PRTG ein Gerät namens Domain oder einen anderen Namen Ihrer Wahl.
  2. Erstellen Sie einen Advanced HTTP push sensor mit einem IdentityToken von directory-adhealthcheck. Beachten Sie, dass dies Groß- und Kleinschreibung beachtet!
  3. Für jedes Domänencontroller-Gerät in PRTG erstellen Sie einen Advanced HTTP push sensor. Für jedes IdentityToken fügen Sie jedem Sensor -adhealthcheck hinzu, wie zum Beispiel dc01-adhealthcheck.
  4. Fügen Sie den Inhalt des PowerShell-Skripts Send-AdhcResultToPrtg.ps1 ans Ende des PowerShell-Skripts ADHealthCheck-NoResult.ps1, das wir behandelt haben.
  5. Ändern Sie die Variable $PRTGUrl auf die URL und den Port Ihres PRTG-Sensors.
  6. Führen Sie das Skript aus.

Nach Abschluss sollte das AD-Health-Check-Skript jetzt den Status an Ihre PRTG-Sensoren übertragen, wie unten gezeigt.

PRTG sensors showing AD health

Planen des Active Directory Health Check-Skripts

Die Überwachung der AD-Gesundheit ist ein fortlaufender Prozess. Sie sollten Tests ständig durchführen, anstatt Ad-hoc-Instanzen. Lassen Sie uns das Active Directory Health Check-Skript so planen, dass es in kurzen Abständen ausgeführt wird.

Der einfachste Weg, diese Überprüfungen zu automatisieren, besteht darin, das Skript zum Taskplaner hinzuzufügen und es unter einem AD-Benutzerkonto oder einem Gruppenverwalteten Dienstkonten

auszuführen. Die Verwendung eines Gruppenverwalteten Dienstkontos (gMSA) ist der sicherere Weg, um geplante Aufgaben autonom auszuführen, da nur festgelegte Computerkonten das Passwort aus AD abrufen können. Einige Organisationen haben jedoch möglicherweise nicht diesen Luxus.

Erstellen eines AD-Benutzerkontos

Lassen Sie uns zunächst analysieren, was erforderlich ist, um ein AD-Benutzerkonto einzurichten, um die geplante Aufgabe auszuführen.

Wenn Sie eine geplante Aufgabe als Benutzerkonto ausführen möchten, führen Sie es auf keinen Fall als Ihr eigenes Konto aus! Erstellen Sie immer ein separates Benutzerkonto für diesen Zweck.

Um Zeit zu sparen, finden Sie unten ein PowerShell-Skript. Dies ist ein Beispiel-Skript, das Sie verwenden können, um ein AD-Benutzerkonto zu erstellen, das Teil der Gruppe Domain-Administratoren ist. Sie können dann dieses Konto verwenden, um geplante Aufgaben auszuführen.

# Ändern Sie dies in die OU Ihrer Dienstkonten
$OU = "OU=Service Accounts,DC=contoso,DC=com"
# Ändern Sie dies in das Passwort, das Sie für das Konto verwenden möchten
$Password = "JägareTvå"
$SecureString = $Password | ConvertTo-SecureString -AsPlainText -Force
New-ADUser -Enabled $True -Path $OU -Name svcADHealthCheck -AccountPassword $SecureString
# Einschränken des Kontos auf nur Domain-Controller
$DomainControllers = (Get-ADDomainController -Filter *).Name

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

# Machen Sie es zum Domänenadministrator (Entschuldigung)
Add-ADGroupMember -Identity "Domain Admins" -Members svcADHealthCheck

Erstellen eines gruppenverwalteten Dienstkontos

Die Verwendung eines gMSA zur Ausführung der Gesundheitsprüfung ist etwas kniffliger, wenn Sie gMSA in Ihrer Umgebung noch nicht verwenden, aber es ist viel sicherer.

Erstellen eines KDS-Stamm-Schlüssels

Um ein gMSA-Konto zur Ausführung des AD-Gesundheitsprüfungsskripts zu erstellen, fügen Sie zunächst einen KDS-Stamm-Schlüssel hinzu, wenn Sie noch keinen haben. Sie können überprüfen, ob Sie einen KDS-Stamm-Schlüssel haben, indem Sie den PowerShell-Befehl Get-KDSRootKey auf einem Domänencontroller ausführen.

Wenn Sie keinen KDS-Stammchlüssel haben, erstellen Sie einen, indem Sie Add-KDSRootKey -EffectiveImmediately unter einem Benutzerkonto ausführen, das zur Gruppe „Domänenadministratoren“ gehört, auf einem 2012R2- oder neueren Domänencontroller.

Der Schlüssel muss auf die anderen Domänencontroller repliziert werden, um vollständig wirksam zu werden. Weitere Informationen zu diesem Vorgang finden Sie in der Microsoft-Dokumentation.

Erstellen des gMSA

Nachdem der KDS-Stammchlüssel erstellt wurde, können Sie das gMSA-Konto mit PowerShell erstellen. Im Folgenden sehen Sie ein Beispiel-Skript, das verwendet werden kann, um das gMSA-Konto zu erstellen, das nur von einem Domänencontroller in der Gruppe „Domänenadministratoren“ authentifiziert werden darf.

# Ändern Sie auf Ihre Domäne
$Domain = "contoso.com"

$AccountName = "svcadhealthcheck"

# Erstellen Sie ein GMSA namens svcadhealthcheck (oder in Wirklichkeit svcadhealthcheck$) und erlauben Sie nur Domänencontrollern, das Passwort abzurufen
New-ADServiceAccount $AccountName -DNSHostName "$AccountName.$Domain" –PrincipalsAllowedToRetrieveManagedPassword "Domain Controllers"

# Fügen Sie das GMSA zu den Domänenadministratoren hinzu
# Beachten Sie, dass wir das Konto mit seinem wahren SamAccountName 'svcadhealthcheck$' hinzufügen
Add-ADGroupMember -Identity "Domain Admins" -Members "$AccountName`$"

Installation und Test des gMSA

Nun ist der gMSA erstellt, der letzte Schritt besteht darin, ihn auf allen Domänencontrollern zu installieren und zu testen. Eine Möglichkeit, dies zu tun, besteht darin, den PowerShell-Befehl Invoke-Command zu verwenden. Unten finden Sie ein PowerShell-Skript, mit dem der gMSA auf allen DCs installiert und sichergestellt wird, dass er ordnungsgemäß funktioniert.

# Dies wird auf allen Domänencontrollern ausgeführt
Invoke-Command -ComputerName (Get-ADDomainController -Filter *).Name -ScriptBlock {
    $Account = Get-ADServiceAccount -Filter { Name -eq 'svcadhealthcheck'}
    Install-ADServiceAccount $Account

    # Überprüft, ob der GMSA auf dem Computer funktioniert
    # Gibt $True zurück, wenn die Tests in Ordnung sind
    $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"
    }

}

Berechtigung für den gMSA, als Stapelauftrag ausgeführt zu werden

Sobald der gMSA installiert ist, müssen Sie ihm nun die Berechtigung geben, als Stapelauftrag auf den DCs ausgeführt zu werden. Das Konto benötigt dieses Recht, da es autonom im Hintergrund in einer geplanten Aufgabe ausgeführt wird.

Sie können diese Berechtigung über ein vorhandenes GPO festlegen oder indem Sie ein neues GPO erstellen und es mit der Domänencontroller-OU verknüpfen. Wenn Sie noch kein GPO haben, das Sie verwenden können, finden Sie unten einige Schritte, die Sie unternehmen können, um eines zu erstellen.

  1. Starten Sie den Gruppenrichtlinien-Editor auf einem DC.
  2. Klicken Sie mit der rechten Maustaste auf die Domänencontroller-OU und wählen Sie GPO in dieser Domäne erstellen und hier verknüpfen.
  3. Nennen Sie es DC – Ausführen als Stapel oder einen anderen Namen, den Sie bevorzugen
  4. Klicken Sie mit der rechten Maustaste auf das GPO und klicken Sie auf Bearbeiten.
  5. Wechseln Sie zu Computerkonfiguration –> Windows-Einstellungen –> Sicherheitseinstellungen –> Benutzerrechtezuweisung.
  6. Klicken Sie mit der linken Maustaste auf Als Stapelverarbeitung 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 Dienstkonten svcADHealthCheck, wählen Sie es aus und klicken Sie auf OK.

Sie sollten jetzt das gMSA in der Liste der AD-Objekte sehen, wie unten dargestellt.

gMSA given rights to logon as a batch job

Erstellen der geplanten Aufgabe

Jetzt, da Sie ein Konto erstellt haben, um die geplanten Aufgaben auszuführen, können Sie die geplante Aufgabe selbst auf einem Domänenbeitrittsserver Ihrer Wahl erstellen.

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

Unten finden Sie zwei Skripte; beide Skripte sind ähnlich, aber eines setzt ein AD-Benutzerkonto voraus und das andere setzt ein gMSA voraus. Stellen Sie sicher, dass Sie das entsprechende Skript verwenden, basierend auf dem Konto, das Sie verwenden.

# Ersetzen Sie durch den Pfad zu Ihrem Skript
$ScriptPath = "C:\Scripts\ADHealthCheck.ps1"
# Ersetzen Sie durch den Benutzernamen des Kontos, das Sie zum Ausführen der Aufgabe erstellt haben
$UserName = "svdADHealthCheck"

# Ersetzen Sie durch das Passwort, das Sie für das oben genannte Konto festgelegt haben
$Password = "JägareTvå!"
# Erstellen Sie die Aktion, die das Skript startet
$Action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-ExecutionPolicy bypass -File '$ScriptPath'"
# Erstellen Sie den Auslöser, der die Aufgabe startet
$Trigger = New-ScheduledTaskTrigger -Once -At "12:00" -RepetitionInterval (New-TimeSpan -Hours 12)
# Erstellen Sie Einstellungen für die geplante Aufgabe
$Settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries -StartWhenAvailable -RunOnlyIfNetworkAvailable -DontStopOnIdleEnd
# Erstellen Sie die geplante Aufgabe unter Verwendung eines Splat für bessere Lesbarkeit
$Splat = @{
    User = "$env:USERDOMAIN\$UserName"
    Password = $Password
    TaskName = "ADHealthCheck"
    Action = $Action
    Trigger = $Trigger
    RunLevel = "Highest"
    Settings = $Settings
}
Register-ScheduledTask @Splat
# Ersetzen Sie durch den Pfad zu Ihrem Skript
$ScriptPath = "C:\Scripts\ADHealthCheck.ps1"
# Ersetzen Sie durch den Benutzernamen des Kontos, das Sie zum Ausführen der Aufgabe erstellt haben
$UserName = "svdADHealthCheck$"
# Erstellen Sie die Aktion, die das Skript startet
$Action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-ExecutionPolicy bypass -File '$ScriptPath'"
# Erstellen Sie den Auslöser, der die Aufgabe startet
$Trigger = New-ScheduledTaskTrigger -Once -At "12:00" -RepetitionInterval (New-TimeSpan -Hours 12)
# Erstellen Sie Einstellungen für die geplante Aufgabe
$Settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries -StartWhenAvailable -RunOnlyIfNetworkAvailable -DontStopOnIdleEnd

# Erstellen Sie das Prinzip, das das GMSA definiert
$Principal = New-ScheduledTaskPrincipal -UserID "$env:USERDOMAIN\$UserName" -LogonType Password -RunLevel Highest
# Erstellen Sie die geplante Aufgabe unter Verwendung eines Splat für bessere Lesbarkeit
$Splat = @{
    Principal = $Principal
    TaskName = "ADHealthCheck"
    Action = $Action
    Trigger = $Trigger
    RunLevel = "Highest"
    Settings = $Settings
}
Register-ScheduledTask @Splat

Sie sind fertig! Zu diesem Zeitpunkt wird die geplante Aufgabe in dem Intervall ausgeführt, das in einem der obigen Skripte angegeben ist.

Zusammenfassung

Whew! Wenn Sie bis jetzt alles seit Teil I verfolgt haben, sollten Sie nun wissen, dass die AD-Gesundheit ein tiefgreifendes Thema ist. Es gibt so viel zu diesem einen Thema, dass nicht einmal zwei lange Blog-Beiträge ausreichen würden, um alles abzudecken.

Aber jetzt sollten Sie genug Wissen haben und ein vordefiniertes PowerShell-Framework, das Sie einsetzen können, wenn andere Active Directory-Gesundheitschecks auftauchen.

Weiterführende Literatur

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