Adam de Automator

BY admin

| augustus 30, 2021

dit is deel II van een tweedelige serie over Active Directory health checks. Hoewel het niet nodig is om te lezen, als je wilt leren hoe het PowerShell-script dat je in dit artikel leert is gebouwd, wordt je aangeraden om een Active Directory-Statuscontroletool te maken : deel I.

in deel I heb je geleerd hoeveel verschillende meerdere tests en waarom ze belangrijk zijn. Laten we ze nu allemaal bij elkaar halen en een gereedschap bouwen. In dit deel converteert u alle in Deel I beschreven statuscontroles voor Active Directory naar een testkader. Je leert ook hoe je de resultaten van verschillende ad health checks kunt uitvoeren naar tools zoals Pester en een monitoring tool genaamd PRTG.

download het adhealthcheck-NoResult.ps1 script van GitHub om een voltooide versie van de tool te zien die je in dit artikel gaat leren.

inhoudsopgave:

het definiëren van Output

het hebben van een gemeenschappelijk objecttype en een eenvoudige manier om het te genereren zal het veel gemakkelijker maken om testresultaten om te zetten naar het gereedschap van uw keuze.

om een uniforme uitvoer te maken voor alle potentiële gereedschappen, heb ik ervoor gekozen om een PowerShell-klasse te gebruiken. Hoewel niet verplicht, het is de aanpak die ik heb gekozen om hier te nemen. Het belangrijkste punt is om ervoor te zorgen dat alle gezondheidscontroles van advertenties hetzelfde type output opleveren.

een PowerShell-klasse is een schema dat definieert hoe een PowerShell-object eruit moet zien en wat het moet doen. Elke regel die je hieronder ziet vertegenwoordigt een eigenschap die de objecten zullen hebben. U kunt hieronder zien Ik ben van plan op elke advertentie health check om tien eigenschappen terug te keren.

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

om deze klasse-creatie te versnellen, gebruik ik een helperfunctie genaamd New-AdhcResult. Deze functie creëert de klasse en alles wat je nodig hebt om mee te volgen. Deze functie zal een aangepast type object uitvoeren.

het uitvoeren van het hulpprogramma voor Ad-statuscontrole

download en kopieer eerst het script voor ad-statuscontrole naar een domeincontroller. Open het met de PowerShell ISE en voer het uit. Dit gedeelte van de tool zal geen informatie retourneren.

dit script zal het resultaat van elke controle in de variabele $TestResults uitvoeren en opslaan als meerdere objecten. U zult deze objecten later gebruiken voor het genereren van rapporten of het uitvoeren van het in verschillende tools. Als u de resultaten van de statuscontrole in een variabele als deze houdt, kunt u meer resultaten toevoegen als u ervoor kiest een andere te maken en het New-AdHcResult – commando te gebruiken.

zodra het script klaar is met draaien, moet u nu een complete set ad-statuscontrole-objecten hebben opgeslagen in de variabele $TestResults. U kunt nu $TestResults uitvoeren vanaf de console en de ruwe resultaten zien.

de resultaten van de statuscontrole weergeven in Tools

omdat alle controles in een gemeenschappelijk objecttype zijn, kunt u ze beter inspecteren met een paar tools zoals Pester en PRTG.

in deze sectie ga je leren hoe je een HTML-rapport maakt met een tool genaamd extent en het rapport in PRTG weergeeft.

een nUnit XML-bestand aanmaken met Pester

u moet eerst de PowerShell-objecten converteren in een formaat dat uw tools kunnen begrijpen. De meeste tools begrijpen XML of, meer specifiek, nUnit XML. Dit is een formaat dat u kunt importeren in verschillende tools om resultaten weer te geven.

aangezien u met PowerShell werkt, zult u het Testkader van Pester gebruiken om de uitvoer van het AD health check script te lezen en om een nUnit XML bestand

te genereren begin met het downloaden van de nieuwste versie van Pester. U kunt Pester downloaden door Install-Module uit te voeren in een verhoogde PowerShell-console. Het onderstaande commando zal een installatie van de nieuwste Pester versie forceren. Omdat het publisher certificaat waarmee Pester is ondertekend, wordt geleverd met Windows 10, moeten we de SkipPublisherCheck parameter gebruiken om het te installeren.

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

zodra Pester beschikbaar is, kunt u het script uitvoeren en dynamisch een set van Pester tests maken.

Opmerking: U kunt ook zelf Pester-tests maken zonder zelfs het PowerShell-script te gebruiken dat ik heb gegeven.

het onderstaande PowerShell-script zal Pester gebruiken om een nUnit XML-bestand te genereren uit de uitvoer van de $TestResults variabele gedefinieerd in het adhealthcheck-NoResult.ps1 script.

sla dit bestand op als Pester. ps1 in dezelfde map als het AD health check script.

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

ten slotte, voer Invoke-Pester hieronder uit om de Pester aan te roepen.ps1 bestand en sla de resultaten op in NUnitXml formaat.

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

het bouwen van een HTML-rapport met het Extent Tool

zodra u het NUnit XML-bestand hebt, kunt u dit bestand nu gebruiken om door te geven aan een tool die dat naar HTML kan converteren. Een van die tools heet mate. Extent is een handig hulpmiddel voor het maken van HTML-rapporten van Nunit XML-bestanden.

eerst de downloadomvang naar dezelfde map als het Nunitrapport.eerder aangemaakt xml-bestand. Voer vervolgens de volgende commando ‘ s uit in een PowerShell sessie. Deze commando ‘ s zullen de directory maken om de HTML-bestanden op te slaan en vervolgens extent uit te voeren.exe om de conversie te doen.

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

als u klaar bent, vindt u twee HTML-bestanden in de htmlreports-map. Deze bestanden ziet eruit als de onderstaande screenshots je ze opent met een webbrowser.

Inname van AD Health Check Resultaten in PRTG

PRTG is een populaire monitoring tool ontwikkeld door Paessler die u kunt gebruiken voor het monitoren van de infrastructuur en diensten. In deze sectie leer je hoe je de resultaten van de statuscontrole naar PRTG pusht zodra het statuscontrolescript is uitgevoerd.

het pushen van resultaten naar PRTG kost meer werk dan het hebben van de tool pull informatie, maar je zult uiteindelijk zien dat de setup de moeite waard is.

Prerequisites

om PRTG succesvol in te stellen als monitoring tool voor het AD health check script dat in dit artikel is gebouwd, zorg ervoor dat u:

PRTG geïnstalleerd en geconfigureerd
alle domeincontrollers ingesteld in PRTG
de Send-AdhcResultToPrtg.ps1 PowerShell script gedownload van GitHub
de URL en poort van y0ur PRTG sensor

Als u elk van de prereqs klaar hebt, kunt u de onderstaande stap-voor-stap instructies volgen over hoe Ik adviseer om deze ad health check resultaten naar PRTG te pushen.

Maak een apparaat aan in PRTG genaamd Domain of welke naam u ook verkiest.
Maak een geavanceerde HTTP push sensor met een IdentityToken van directory-adhealthcheck. Merk op dat dit hoofdlettergevoelig is!
maak voor elk domeincontrollerapparaat in PRTG één geavanceerde HTTP push-sensor aan. Voor elke IdentityToken, voeg elke sensor met-adhealthcheck zoals dc01-adhealthcheck.
voeg de inhoud van het send-AdhcResultToPrtg.ps1 PowerShell script toe aan het einde van het ADHealthCheck-NoResult.ps1 PowerShell script dat we hebben behandeld.
Wijzig de variabele $PRTGUrl naar de URL en poort van uw PRTG-sensor.
voer het script uit.

zodra het AD statuscontrolescript is voltooid, moet het nu de status naar uw PRTG-sensoren pushen, zoals hieronder wordt getoond.

het plannen van het Active Directory-Statuscontrolescript

het controleren van de AD-status is een lopend proces. Je zou de hele tijd tests moeten uitvoeren in plaats van Ad-hoc instanties. Laten we het Active Directory health check-script plannen om regelmatig uit te voeren.

de gemakkelijkste manier om deze controles te automatiseren is door het script toe te voegen aan de Taakplanner en het te laten draaien onder een AD-gebruikersaccount of een Group Managed Service-Account.

het gebruik van een Group Managed Service-Account (gMSA) is de veiligere manier om geplande taken autonoom uit te voeren, aangezien alleen computeraccounts zijn opgegeven die het wachtwoord van AD kunnen ophalen. Maar sommige organisaties hebben deze luxe misschien niet.

een AD-gebruikersaccount aanmaken

laten we eerst uitzoeken wat er nodig is om een AD-gebruikersaccount in te stellen om de geplande taak uit te voeren.

als u een geplande taak gaat uitvoeren als een gebruikersaccount, Doe het dan zeker niet als uw eigen account! Maak hiervoor altijd een apart gebruikersaccount aan.

om tijd te besparen, ziet u hieronder een PowerShell-script. Dit is een voorbeeldscript waarmee u een AD-gebruikersaccount kunt maken dat deel uitmaakt van de groep Domeinadministrators. U kunt dit account vervolgens gebruiken om een geplande taak uit te voeren.

# 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

een Group Managed Service Account aanmaken

een gMSA gebruiken om de statuscontrole uit te voeren is wat lastiger als u gMSA niet al in uw omgeving gebruikt, maar het is veel veiliger.

een KDS-Rootsleutel

om een gMSA-account aan te maken om het AD-statuscontrolescript uit te voeren, voegt u eerst een KDS-rootsleutel toe als u er nog geen hebt. U kunt controleren of u een KDS-rootsleutel hebt door het PowerShell-commando Get-KDSRootKey op een domeincontroller uit te voeren.

als u geen KDS-rootsleutel hebt, maakt u er een aan door Add-KDSRootKey -EffectiveImmediately uit te voeren onder een gebruikersaccount van de admins-groep op een 2012R2-of later-domeincontroller.

de sleutel moet worden gerepliceerd naar de andere domeincontrollers om volledig effect te hebben. Meer informatie over dit proces is te vinden in de Microsoft documentatie.

gMSA

als de KDS-rootsleutel eenmaal is aangemaakt, bent u klaar om het gMSA-account aan te maken met PowerShell. Hieronder ziet u een voorbeeldscript waarmee u het gMSA-account kunt maken dat alleen kan worden geverifieerd bij een domeincontroller in de groep Domeinadministrators.

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

installeren en testen van de gMSA

nu de gMSA is aangemaakt, is de laatste stap het installeren en testen op alle domeincontrollers. Een manier om dit te doen is door het Invoke-Command PowerShell commando te gebruiken. Hieronder zie je een PowerShell script dat de gMSA zal installeren op alle DCs en ervoor zorgen dat het goed werkt.

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

de gMSA toestemming geven om als Batch-taak

als de gMSA eenmaal is geïnstalleerd, moet u het nu toestemming geven om als batch-taak op het DCs uit te voeren. Het account heeft dit recht nodig omdat het autonoom op de achtergrond zal draaien in een geplande taak.

u kunt deze machtiging instellen via een bestaand groepsbeleidsobject of door een nieuw groepsbeleidsobject aan te maken en deze te koppelen aan de OU van de domeincontrollers. Als u nog geen groepsbeleidsobject hebt om te gebruiken, kunt u hieronder enkele stappen nemen om een groepsbeleidsobject aan te maken.

start de Editor voor Groepsbeleid op een DC.
Klik met de rechtermuisknop op de domeincontrollers OU en selecteer GPO maken in dit domein en link het hier.
noem het DC-Logon as batch of een andere naam die u verkiest
Klik met de rechtermuisknop op het groepsbeleidsobject en klik op Bewerken.
Ga naar Computerconfiguratie –> Windows –instellingen –> beveiligingsinstellingen – > toewijzing van gebruikersrechten.
Klik met de linkermuisknop op aanmelden als batch-taak en klik op Eigenschappen.
klik op gebruiker of groep toevoegen.
klik op Objecttypen, selecteer Alleen Service Accounts en klik op OK.
zoek naar het svcADHealthCheck-serviceaccount dat eerder is aangemaakt, selecteer het en klik op OK.

u ziet nu de gMSA onder de lijst met AD-objecten zoals hieronder weergegeven.

gMSA gegeven rechten om aan te melden als een batch-taak

de geplande taak

Nu u een account hebt aangemaakt om de geplande taken uit te voeren, kunt u de geplande taak zelf aanmaken op een server van uw keuze die deel uitmaakt van het domein.

u kunt de geplande taak aanmaken via de GUI, maar dat is te veel klikken! In plaats daarvan adviseer ik het te maken met PowerShell. Waarom? Omdat je gewoon de code kunt kopiëren die je hieronder ziet en er klaar mee bent.

hieronder vindt u twee scripts; beide scripts zijn vergelijkbaar, maar de ene gaat uit van een AD gebruikersaccount en de andere gaat uit van een gMSA. Zorg ervoor dat u het juiste script gebruikt op basis van welk account u gebruikt.

# 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

je bent klaar! Op dit moment wordt de geplande taak uitgevoerd met het interval dat in een van de bovenstaande scripts is opgegeven.

Samenvatting

Whew! Als je helemaal vanaf Deel I gevolgd bent, zou je inmiddels moeten weten dat AD gezondheid een diep onderwerp is. Er is zo veel aan dit ene onderwerp dat zelfs niet twee lange blog posts kon dekken.

maar nu moet u voldoende kennis en een vooraf gebouwd PowerShell-framework hebben om andere Active Directory-statuscontroles aan te sluiten wanneer deze zich voordoen.

verder lezen

sommige dingen die u misschien niet weet over AD en Disaster Recovery
wat doet DCDIAG eigenlijk…?