Adam The Automator

ez az Active Directory állapotfelméréseiről szóló kétrészes sorozat II.része. Bár nem kötelező olvasmány, Ha meg szeretné tudni, hogyan készült a PowerShell szkript, amelyet ebben a cikkben megismerhet, javasoljuk, hogy nézze meg az Active Directory Állapotellenőrző eszközének elkészítését : I. rész.

az I. részben megtudta, hogy hány különböző teszt van, és miért fontosak. Most húzzuk össze őket, és építsünk egy eszközt. Ebben a részben az I. részben ismertetett összes Active Directory állapotellenőrzést teszt keretrendszerré alakítja. Azt is megtudhatja, hogyan adhatja ki a különböző hirdetési állapotellenőrzések eredményeit olyan eszközökhöz, mint a Pester és a PRTG nevű felügyeleti eszköz.

ha követni szeretné az eszköz kész verzióját, amelyet ebben a cikkben megismerhet, töltse le az ADHealthCheck-NoResult.ps1 szkriptet a Githubról.

a kimenet meghatározása

ha közös objektumtípust és egyszerű előállítási módot használ, sokkal könnyebbé válik a teszt eredményeinek konvertálása az Ön által választott eszközre.

az összes lehetséges eszköz egységes kimenetének létrehozásához egy PowerShell osztályt választottam. Bár nem szükséges, ezt a megközelítést választottam itt. A lényeg annak biztosítása, hogy az összes HIRDETÉSÁLLAPOT-ellenőrzés azonos típusú kimenetet adjon vissza.

a PowerShell osztály egy séma, amely meghatározza, hogyan kell kinéznie egy PowerShell objektumnak, és mit kell tennie. Az alábbiakban látható minden sor egy olyan tulajdonságot képvisel, amellyel az objektumok visszatérnek. Az alábbiakban láthatja, hogy minden hirdetés állapotfelmérését tervezem, hogy tíz tulajdonságot térjek vissza.

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

az osztály létrehozásának felgyorsítása érdekében egy új-AdhcResult nevű segítő funkciót fogok használni. Ez a funkció létrehozza az osztályt és mindent, amit követnie kell. Ez a függvény egy egyedi típusú objektumot ad ki.

a hirdetés állapotfelmérő eszközének futtatása

először töltse le és másolja át a hirdetés állapotfelmérő parancsfájlját egy tartományvezérlőre. Nyissa meg a PowerShell ISE-vel, és futtassa. Az eszköz ezen része nem ad vissza semmilyen információt.

a parancsfájl a $TestResults változóban több objektumként futtatja és tárolja az egyes ellenőrzések eredményét. Ezeket az objektumokat később jelentések készítésére vagy különféle eszközökbe történő kiadására fogja használni. Az állapotfelmérés eredményeinek egy ilyen változóban való tartása lehetővé teszi további eredmények hozzáadását, ha úgy dönt, hogy létrehoz egy másikat, és használja a New-AdHcResult parancsot.

miután a parancsfájl futása befejeződött, a $TestResults változóban tárolnia kell az AD állapotellenőrzési objektumok teljes készletét. Most már futtathatja a $TestResults parancsot a konzolról, és megtekintheti a nyers eredményeket.

a hirdetés állapotfelmérésének megjelenítése az eszközökben

mivel az összes ellenőrzés közös objektumtípusban van, jobban megvizsgálhatja őket néhány eszközzel, például a Pester és a PRTG segítségével.

ebben a részben megtudhatja, hogyan hozhat létre HTML-jelentést az Extension nevű eszközzel, és hogyan jelenítheti meg a jelentést PRTG-ben.

NUnit XML fájl létrehozása A Pester

használatával először át kell alakítania a PowerShell objektumokat olyan formátumban, amelyet az eszközök megértenek. A legtöbb eszköz megérti az XML-t, pontosabban a NUnit XML-t. Ez egy olyan formátum, amelyet különféle eszközökbe importálhat az eredmények megjelenítéséhez.

mivel a PowerShell-vel dolgozik, a Pester testing framework segítségével elolvashatja az AD állapotellenőrzési parancsfájl kimenetét, és létrehoz egy NUnit XML fájlt

először töltse le a Pester legújabb verzióját. A Pester letölthető a Install-Module futtatásával egy megemelt PowerShell konzolon. Az alábbi parancs kényszeríti a legújabb Pester verzió telepítését. Mivel a Pester által aláírt kiadói tanúsítvány A Windows 10 – hez tartozik, a telepítéshez a SkipPublisherCheck paramétert kell használnunk.

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

amint a Pester elérhető, futtathatja a szkriptet, és dinamikusan létrehozhat egy sor Pester tesztet.

Megjegyzés: saját maga is létrehozhat Pester teszteket anélkül, hogy az általam megadott PowerShell szkriptet használná.

az alábbi PowerShell szkript a Pester segítségével generál egy NUnit XML fájlt az ADHealthCheck-NoResult.ps1 szkriptben meghatározott $TestResults változó kimenetéből.

mentse ezt a fájlt Pester.ps1 fájlként ugyanabba a mappába, mint az AD állapotfelmérési parancsfájl.

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

végül futtassa az alábbi Invoke-Pester parancsot a Pester meghívásához.ps1 fájlt, és mentse az eredményeket NUnitXml formátumban.

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

HTML-jelentés készítése a

Extension Tool eszközzel, Ha megvan a NUnit XML fájl, akkor ezt a fájlt továbbíthatja egy olyan eszközhöz, amely ezt HTML-re konvertálhatja. Az egyik ilyen eszköz a kiterjedés. Mértékben egy praktikus eszköz létrehozására HTML jelentéseket NUnit XML fájlokat.

először töltse le a terjedelmet ugyanabba a könyvtárba, mint a NunitReport.korábban létrehozott xml fájl. Ezután hajtsa végre a következő parancsokat egy PowerShell munkamenetben. Ezek a parancsok létrehozzák a könyvtárat a HTML fájlok tárolására, majd végrehajtják a kiterjedést.exe csinálni az átalakítás.

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

ha elkészült, két HTML fájlt talál a HTMLReports könyvtárban. Ezek a fájlok úgy néznek ki, mint az alábbi képernyőképek, amelyeket webböngészővel nyit meg.

az Ad állapotfelmérés eredményeinek bevitele a PRTG – be

a PRTG egy Paessler által kifejlesztett népszerű felügyeleti eszköz, amelyet infrastruktúrájának és szolgáltatásainak figyelemmel kísérésére használhat. Ebben a részben megtudhatja, hogyan kell az állapotfelmérés eredményeit a PRTG-re tolni, miután az állapotfelmérési parancsfájl lefutott.

az eredmények PRTG-hez való eljuttatása több munkát igényel, mint az eszköz húzási információi, de végül látni fogja, hogy a Beállítás megéri az eltöltött időt.

előfeltételek

ahhoz, hogy sikeresen beállíthassa a PRTG-t az ebben a cikkben felépített ad állapotfelmérési parancsfájl felügyeleti eszközeként, győződjön meg róla, hogy:

• a PRTG telepítette és konfigurálta
• az összes tartományvezérlőt, amelyet a PRTG
• Send-AdhcResultToPrtg-ben állítottak be.ps1 PowerShell script letölthető GitHub
• az URL és a port y0ur PRTG érzékelő

ha minden a prereqs tenni, akkor majd kövesse az alábbi lépésről-lépésre, hogyan ajánlom, hogy álljon ezek a hirdetések állapotfelmérés eredményeket PRTG.

1. hozzon létre egy eszközt a PRTG-ben tartomány vagy bármilyen név.
2. hozzon létre egy fejlett HTTP push érzékelő egy IdentityToken könyvtár-adhealthcheck. Vegye figyelembe, hogy ez nagybetűérzékeny!
3. a PRTG minden tartományvezérlő eszközéhez hozzon létre egy fejlett HTTP push érzékelőt. Minden IdentityToken, hozzáfűzni minden érzékelő-adhealthcheck mint dc01-adhealthcheck.
4. adja hozzá a Send-AdhcResultToPrtg.ps1 PowerShell szkript tartalmát az általunk lefedett ADHealthCheck-NoResult.ps1 PowerShell szkript végéhez.
5. módosítsa a $PRTGUrl változót a PRTG érzékelő URL-jére és portjára.
6. hajtsa végre a szkriptet.

miután elkészült, miután az AD állapotfelmérési parancsfájl befejeződött, az alább látható módon nyomja meg az állapotot a PRTG érzékelőinek.

az Active Directory állapotfelmérési parancsfájl ütemezése

a hirdetések állapotának figyelése folyamatos folyamat. Mindig teszteket kell futtatnia, nem pedig ad-hoc példányokat. Ütemezzük az Active Directory állapotfelmérési parancsfájlját gyakori időközönként.

az ellenőrzések automatizálásának legegyszerűbb módja az, ha hozzáadja a parancsfájlt a feladatütemezőhöz, és hagyja, hogy egy hirdetési felhasználói fiók vagy egy csoport által kezelt szolgáltatási fiók alatt fusson.

a csoportos felügyelt szolgáltatási fiók (gMSA) használata a biztonságosabb módja az ütemezett feladatok önálló végrehajtásának, mivel csak olyan számítógépes fiókok vannak, amelyek le tudják tölteni a jelszót az AD-ből. De egyes szervezetek nem rendelkeznek ezzel a luxussal.

hirdetési felhasználói fiók létrehozása

először bontsuk le, mi szükséges ahhoz, hogy egy hirdetési felhasználói fiókot beállítsunk az ütemezett feladat futtatásához.

ha egy ütemezett feladatot felhasználói fiókként fog futtatni, mindenképpen ne futtassa saját fiókként! Mindig hozzon létre egy külön felhasználói fiókot erre a célra.

időt takaríthat meg időt, akkor megjelenik egy PowerShell script alább. Ez egy példa parancsfájl, amellyel létrehozhat egy olyan hirdetési felhasználói fiókot, amely a Domain Admins csoport része. Ezután használhatja ezt a fiókot az ütemezett feladat futtatásához.

# 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

Csoportkezelt szolgáltatási fiók létrehozása

gMSA használata az állapotfelmérés futtatásához kissé trükkösebb, ha még nem használja a gMSA-t a környezetében, de sokkal biztonságosabb.

KDS-Gyökérkulcs létrehozása

gMSA-fiók létrehozásához az AD állapotellenőrzési parancsfájl futtatásához először adjon hozzá egy KDS-gyökérkulcsot, ha még nem rendelkezik ilyennel. A Get-KDSRootKey PowerShell parancs tartományvezérlőn történő futtatásával ellenőrizheti, hogy rendelkezik-e KDS gyökérkulccsal.

ha nem rendelkezik KDS gyökérkulccsal, akkor hozzon létre egyet a Add-KDSRootKey -EffectiveImmediately futtatásával a Tartománygazdák hirdetéscsoport felhasználói fiók része alatt egy 2012R2 vagy újabb tartományvezérlőn.

a kulcsnak a többi tartományvezérlőnek is replikálnia kell a teljes hatás eléréséhez. További információ erről a folyamatról a Microsoft dokumentációjában található.

a gMSA létrehozása

a KDS gyökérkulcs létrehozása után készen áll a gMSA-fiók létrehozására a PowerShell segítségével. Az alábbiakban egy példa szkriptet láthat a Gmsa-fiók létrehozásához, amelyet csak a Tartománygazdák csoport tartományvezérlőjéből lehet hitelesíteni.

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

a gMSA telepítése és tesztelése

a gMSA létrehozása után az utolsó lépés az összes tartományvezérlőn történő telepítés és tesztelés. Ennek egyik módja a Invoke-Command PowerShell parancs használata. Az alábbiakban egy PowerShell szkript látható, amely telepíti a gMSA-t az összes DCs-re, és biztosítja, hogy megfelelően működjön.

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

a gMSA engedélyének megadása kötegelt feladatként történő futtatáshoz

miután a gMSA telepítve van, most engedélyt kell adnia neki, hogy kötegelt feladatként fusson a DCs-n. A fióknak szüksége van erre a jogra, mivel önállóan fut a háttérben egy ütemezett feladat során.

ezt az engedélyt beállíthatja egy meglévő csoportházirend-objektumon keresztül, vagy létrehozhat egy új csoportházirend-objektumot, és összekapcsolhatja azt a tartományvezérlőkkel. Ha még nem rendelkezik GPO-val, akkor az alábbiakban néhány lépést megtehet annak létrehozásához.

1. indítsa el a csoportházirend-szerkesztőt egy DC-n.
2. kattintson a jobb gombbal a tartományvezérlőkre, majd válassza a GPO létrehozása ebben a tartományban lehetőséget, és kapcsolja ide.
3. nevezze el DC – Logon tételként vagy más néven
4. kattintson a jobb gombbal a csoportházirend-objektumra, majd kattintson a Szerkesztés parancsra.
5. lépjen a Számítógép konfigurációja –> Windows beállítások –> Biztonsági beállítások –> felhasználói jogok hozzárendelése menüpontra.
6. kattintson a bal egérgombbal a bejelentkezés kötegelt feladatként elemre, majd kattintson a Tulajdonságok parancsra.
7. kattintson a felhasználó vagy Csoport hozzáadása elemre.
8. kattintson az Objektumtípusok elemre, válassza a csak szolgáltatásfiókok lehetőséget, majd kattintson az OK gombra.
9. keresse meg a korábban létrehozott svcADHealthCheck szolgáltatási fiókot, jelölje ki, majd kattintson az OK gombra.

Most látnia kell a gMSA-t az alább látható hirdetési objektumok listája alatt.

ütemezett feladat létrehozása

most, hogy létrehozott egy fiókot az ütemezett feladatok futtatásához, most létrehozhatja magát az ütemezett feladatot egy választott tartományhoz csatlakoztatott kiszolgálón.

az ütemezett feladatot a GUI-n keresztül hozhatja létre, de ez túl sok kattintás! Ehelyett azt javaslom, hogy hozza létre a PowerShell-vel. Miért? Mert egyszerűen lemásolhatja az alább látható kódot, és elvégezheti vele.

az alábbiakban két szkriptet talál; mindkét szkript hasonló, de az egyik feltételez egy hirdetési felhasználói fiókot, a másik pedig egy gMSA-t. Ügyeljen arra, hogy a megfelelő szkriptet használja annak alapján, hogy melyik fiókot használja.

# 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

végeztél! Ekkor az ütemezett feladat a fenti szkriptek egyikében megadott időközönként fog végrehajtani.

Összefoglaló

Hú! Ha az I. résztől kezdve végig követte, mostanra tudnia kell, hogy az AD egészség mély téma. Annyi minden van ebben a témában, hogy még két hosszú blogbejegyzés sem képes lefedni.

de mostanra már elegendő tudással és egy előre elkészített PowerShell-keretrendszerrel kell rendelkeznie ahhoz, hogy az Active Directory állapotellenőrzéseihez is csatlakozhasson.

további olvasmányok

• néhány dolog, amit nem tudhat az AD-ről és a katasztrófa utáni helyreállításról
• mit csinál valójában a DCDIAG…?