Adam Automator

jest to część II dwuczęściowej serii dotyczącej kontroli stanu Active Directory. Chociaż czytanie nie jest wymagane, jeśli chcesz dowiedzieć się, jak powstał skrypt PowerShell, o którym dowiesz się z tego artykułu, zachęcamy do zapoznania się z narzędziem do sprawdzania stanu usługi Active Directory : Część I.

w części I nauczyłeś się, ile różnych testów wielokrotnych i dlaczego są ważne. Teraz zbierzmy je wszystkie razem i zbudujmy narzędzie. W tej części wszystkie testy stanu usługi Active Directory opisane w części I zostaną przekształcone w ramy testowe. Dowiesz się również, jak wysyłać wyniki różnych kontroli stanu reklam do narzędzi takich jak Pester i narzędzie monitorujące o nazwie PRTG.

aby śledzić lub zobaczyć gotową wersję narzędzia, o którym dowiesz się w tym artykule, Pobierz skrypt ADHealthCheck-NoResult.ps1 z GitHub.

zdefiniowanie wyjścia

posiadanie wspólnego typu obiektu i łatwego sposobu jego generowania znacznie ułatwi konwersję wyników testów na wybrane przez ciebie narzędzie.

aby stworzyć jednolite wyjście dla wszystkich potencjalnych narzędzi, zdecydowałem się użyć klasy PowerShell. Chociaż nie jest to wymagane, jest to podejście zdecydowałem się podjąć tutaj. Głównym celem jest zapewnienie, że wszystkie kontrole stanu reklam zwracają ten sam typ danych wyjściowych.

Klasa PowerShell jest schematem, który definiuje jak obiekt PowerShell powinien wyglądać i co powinien robić. Każda linia, którą widzisz poniżej, reprezentuje właściwość, którą będą miały zwrócone obiekty. Możesz zobaczyć poniżej planuję każdą kontrolę stanu reklamy, aby zwrócić dziesięć właściwości.

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

aby przyspieszyć tworzenie tej klasy, użyję funkcji pomocniczej o nazwie New-AdhcResult. Ta funkcja tworzy klasę i wszystko, czego potrzebujesz do naśladowania. Ta funkcja wyświetli niestandardowy obiekt typu .

Uruchamianie narzędzia sprawdzania stanu reklam

najpierw pobierz i skopiuj skrypt sprawdzania stanu reklam do kontrolera domeny. Otwórz go za pomocą PowerShell ISE i uruchom go. Ta część narzędzia nie zwróci żadnych informacji.

skrypt ths uruchomi i zapisze wynik każdego sprawdzenia w zmiennej $TestResults jako wiele obiektów . Będziesz później używać tych obiektów do generowania raportów lub wysyłania ich do różnych narzędzi. Trzymanie wyników kontroli stanu w zmiennej takiej jak ta pozwala dodać więcej wyników, jeśli zdecydujesz się utworzyć kolejny i użyjesz polecenia New-AdHcResult.

gdy skrypt zakończy działanie, w zmiennej $TestResults powinien być zapisany kompletny zestaw obiektów sprawdzania stanu reklamy. Możesz teraz uruchomić $TestResults z konsoli i zobaczyć surowe wyniki.

wyświetlanie wyników kontroli stanu reklam w narzędziach

ponieważ wszystkie kontrole są we wspólnym typie obiektu, można je lepiej sprawdzić za pomocą kilku narzędzi, takich jak Pester i PRTG.

w tej sekcji dowiesz się, jak utworzyć raport HTML za pomocą narzędzia o nazwie Range i wyświetlić raport w PRTG.

Tworzenie pliku XML nUnit za pomocą Pestera

najpierw musisz przekonwertować obiekty PowerShell w formacie, który są w stanie zrozumieć twoje narzędzia. Większość narzędzi rozumie XML, a dokładniej nUnit XML. Jest to format, który można zaimportować do różnych narzędzi, aby wyświetlić wyniki.

ponieważ pracujesz z PowerShell, będziesz korzystać z platformy testowej Pester, aby odczytać dane wyjściowe ze skryptu sprawdzania stanu reklam i wygenerować plik XML nUnit

zacznij od pobrania najnowszej wersji programu Pester. Możesz pobrać program Pester, uruchamiając Install-Modulew konsoli PowerShell. Poniższe polecenie wymusi zainstalowanie najnowszej wersji Pester. Ponieważ certyfikat wydawcy podpisany przez Pestera pochodzi z systemu Windows 10, aby go zainstalować, musimy użyć parametru SkipPublisherCheck.

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

gdy Pester będzie dostępny, możesz uruchomić skrypt i dynamicznie utworzyć zestaw testów Pester.

Uwaga: Możesz również tworzyć testy Pester samodzielnie, nawet bez użycia skryptu PowerShell, który podałem.

poniższy skrypt PowerShell użyje Pestera do wygenerowania pliku XML nUnit z wyjścia zmiennej $TestResults zdefiniowanej w skrypcie Adhealthcheck-NoResult.ps1.

Zapisz ten plik jako Pester. ps1 w tym samym folderze co skrypt sprawdzania stanu reklamy.

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

na koniec uruchom Invoke-Pester poniżej, aby wywołać Tester.plik ps1 i zapisać wyniki w formacie NUnitXml.

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

budowanie raportu HTML za pomocą narzędzia zakres

Gdy Masz plik XML NUnit, możesz teraz użyć tego pliku, aby przekazać go do narzędzia, które może przekonwertować go na HTML. Jedno z tych narzędzi nazywa się range. Extent jest przydatnym narzędziem do tworzenia raportów HTML z plików XML Nunit.

najpierw pobierz plik do tego samego katalogu co NunitReport.plik XML utworzony wcześniej. Następnie wykonaj następujące polecenia w sesji PowerShell. Polecenia te utworzą katalog do przechowywania plików HTML, a następnie wykonają zakres.exe do konwersji.

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

po zakończeniu znajdziesz dwa pliki HTML w katalogu HTMLReports. Pliki te będą wyglądać jak poniższe zrzuty ekranu, które otwierasz za pomocą przeglądarki internetowej.

pobieranie wyników kontroli stanu reklam do PRTG

PRTG to popularne narzędzie monitorujące opracowane przez Paessler, które można wykorzystać do monitorowania infrastruktury i usług. W tej sekcji dowiesz się, jak przenieść wyniki kontroli stanu zdrowia do PRTG po uruchomieniu skryptu kontroli stanu zdrowia.

popychanie wyników do PRTG wymaga więcej pracy niż informacji o narzędziu, ale w końcu zobaczysz, że konfiguracja jest warta poświęconego czasu.

wymagania wstępne

aby pomyślnie skonfigurować PRTG jako narzędzie do monitorowania skryptu sprawdzania stanu reklam wbudowanego w tym artykule, upewnij się, że masz:

• PRTG zainstalowane i skonfigurowane
• wszystkie kontrolery domeny skonfigurowane w PRTG
• Send-AdhcResultToPrtg.ps1 PowerShell script pobrany z GitHub
• adres URL i port y0ur czujnika PRTG

jeśli masz każde z wymagań wstępnych zrobione, możesz następnie wykonać poniższe instrukcje krok po kroku, jak zalecam, aby wysłać te wyniki kontroli stanu reklam do PRTG.

1. Utwórz urządzenie w PRTG o nazwie domena lub jakakolwiek nazwa wolisz.
2. Utwórz Zaawansowany czujnik push HTTP z identyfikatorem katalogu-adhealthcheck. Zauważ, że wielkość liter jest wrażliwa!
3. dla każdego urządzenia kontrolera domeny w PRTG Utwórz jeden Zaawansowany czujnik push HTTP. Dla każdego Identitoken, Dołącz każdy czujnik z -adhealthcheck, takich jak dc01-adhealthcheck.
4. dodaj zawartość skryptu PowerShell Send-Adhcresulttoprtg.ps1 na koniec skryptu PowerShell Adhealthcheck-NoResult. ps1, który omówiliśmy.
5. Zmień zmienną $PRTGUrl na adres URL i port czujnika PRTG.
6. wykonaj skrypt.

po zakończeniu, po zakończeniu skryptu sprawdzania stanu reklamy, powinien teraz wysyłać status do czujników PRTG, jak pokazano poniżej.

planowanie skryptu sprawdzania stanu usługi Active Directory

monitorowanie stanu reklam jest procesem ciągłym. Powinieneś uruchamiać testy cały czas, a nie instancje ad-hoc. Zaplanujmy uruchamianie skryptu sprawdzania stanu usługi Active Directory w częstych odstępach czasu.

najprostszą drogą automatyzacji tych kontroli jest dodanie skryptu do harmonogramu zadań i Zezwolenie na uruchomienie go pod kontem użytkownika reklamy lub kontem usługi zarządzanej przez grupę.

Korzystanie z konta usługi zarządzanej przez grupę (gMSA) jest bezpieczniejszym sposobem samodzielnego wykonywania zaplanowanych zadań, ponieważ tylko określone konta komputerowe mogą pobrać hasło z AD. Ale niektóre organizacje mogą nie mieć tego luksusu.

Tworzenie konta użytkownika reklamy

najpierw omówmy, czego potrzeba, aby skonfigurować konto użytkownika reklamy, aby uruchomić zaplanowane zadanie.

jeśli masz zamiar uruchomić zaplanowane zadanie jako konto użytkownika, zdecydowanie nie uruchamiaj go jako własnego konta! W tym celu należy zawsze utworzyć osobne konto użytkownika.

aby zaoszczędzić czas, zobaczysz skrypt PowerShell poniżej. Jest to przykładowy skrypt, którego można użyć do utworzenia konta użytkownika reklamy należącego do grupy Administratorzy domeny. Następnie możesz użyć tego konta, aby uruchomić zaplanowane zadanie.

# 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

Tworzenie konta usługi zarządzanej przez grupę

Korzystanie z gMSA do uruchomienia oceny funkcjonowania jest nieco trudniejsze, jeśli nie używasz gMSA w swoim środowisku, ale jest o wiele bezpieczniejsze.

tworzenie klucza głównego KDS

aby utworzyć konto gMSA, aby uruchomić skrypt sprawdzania stanu reklamy, najpierw dodaj klucz główny KDS, jeśli go jeszcze nie masz. Możesz sprawdzić, czy masz klucz główny KDS, uruchamiając polecenie PowerShell Get-KDSRootKey na kontrolerze domeny.

jeśli nie masz klucza głównego KDS, utwórz go, uruchamiając Add-KDSRootKey -EffectiveImmediately pod kontem użytkownika w grupie Ad Admins domeny na kontrolerze domeny 2012R2 lub nowszym.

klucz musi się replikować do innych kontrolerów domeny, aby uzyskać pełny efekt. Więcej informacji na temat tego procesu można znaleźć w dokumentacji firmy Microsoft.

Tworzenie gMSA

po utworzeniu klucza głównego KDS możesz utworzyć konto gMSA za pomocą PowerShell. Poniżej znajduje się przykładowy skrypt, którego można użyć do utworzenia konta gMSA, które można uwierzytelnić tylko z kontrolera domeny w grupie administratorów domeny.

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

instalacja i testowanie gMSA

teraz gMSA jest tworzony, ostatnim krokiem jest zainstalowanie i przetestowanie go na wszystkich kontrolerach domeny. Jednym ze sposobów jest użycie polecenia PowerShell Invoke-Command. Poniżej możesz zobaczyć skrypt PowerShell, który zainstaluje gMSA na wszystkich DCs i upewni się, że działa poprawnie.

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

nadawanie gMSA uprawnienia do uruchamiania jako zadanie wsadowe

po zainstalowaniu gMSA musisz teraz dać mu uprawnienia do uruchamiania jako zadanie wsadowe na DCs. Konto potrzebuje tego prawa, ponieważ będzie działać autonomicznie w tle w zaplanowanym zadaniu.

możesz ustawić to uprawnienie za pomocą istniejącego GPO lub tworząc nowy GPO i łącząc go z kontrolerami domeny. Jeśli nie masz jeszcze GPO do użycia, poniżej znajduje się kilka kroków, które możesz wykonać, aby go utworzyć.

1. uruchom Edytor zasad grupy na DC.
2. kliknij prawym przyciskiem myszy kontrolery domeny OU i wybierz Utwórz GPO w tej domenie i połącz ją tutaj.
3. nazwij go DC-Logon jako batch lub inną preferowaną nazwę
4. kliknij prawym przyciskiem myszy GPO i kliknij Edytuj.
5. przejdź do Konfiguracja komputera – > Ustawienia systemu Windows –> ustawienia zabezpieczeń –> przypisanie praw Użytkownika.
6. kliknij lewym przyciskiem myszy Zaloguj się jako zadanie wsadowe i kliknij Właściwości.
7. kliknij Dodaj użytkownika lub grupę.
8. kliknij typy obiektów, wybierz tylko konta usług i kliknij OK.
9. wyszukaj wcześniej utworzone konto usługi svcADHealthCheck, zaznacz je i kliknij OK.

powinieneś teraz zobaczyć gMSA pod listą obiektów reklamowych, jak pokazano poniżej.

Tworzenie zaplanowanego zadania

teraz, gdy masz konto utworzone do uruchamiania zaplanowanych zadań, możesz teraz utworzyć zaplanowane zadanie na wybranym serwerze połączonym z domeną.

możesz utworzyć zaplanowane zadanie za pomocą GUI, ale to za dużo klikania! Zamiast tego polecam stworzenie go za pomocą PowerShell. Dlaczego? Ponieważ możesz po prostu skopiować kod, który widzisz poniżej i zrobić to z nim.

Poniżej znajdziesz dwa skrypty; oba skrypty są podobne, ale jeden zakłada konto użytkownika reklamy, a drugi zakłada gMSA. Pamiętaj, aby użyć odpowiedniego skryptu w zależności od tego, z którego konta korzystasz.

# 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

jesteś skończony! W tym czasie zaplanowane zadanie zostanie wykonane w odstępach podanych w jednym z powyższych skryptów.

Podsumowanie

Jeśli śledziłeś całą drogę od części I, powinieneś już wiedzieć, że zdrowie reklamy jest głębokim tematem. Jest tak wiele w tym jednym temacie,że nawet dwa długie posty na blogu nie mogłyby objąć.

ale do tej pory powinieneś mieć wystarczającą wiedzę i wstępnie zbudowany framework PowerShell, który możesz podłączyć do innych kontroli stanu Active Directory w miarę ich powstawania.

Czytaj dalej

• niektóre rzeczy, których możesz nie wiedzieć o ad i Disaster Recovery
• co właściwie robi DCDIAG?