Adam Automator

aceasta este partea II a unei serii din două părți privind controalele de sănătate Active Directory. Deși nu este necesară citirea, dacă doriți să aflați cum a fost construit scriptul PowerShell despre care veți învăța în acest articol, sunteți încurajat să consultați construirea unui instrument de verificare a sănătății Active Directory : Partea I.

în partea I, ați învățat câte teste multiple diferite și de ce sunt importante. Să le tragem acum împreună și să construim un instrument. În această parte, veți converti toate verificările de sănătate Active Directory explicate în partea I într-un cadru de testare. Veți învăța, de asemenea, cum să afișați rezultatele diferitelor controale de sănătate ale anunțurilor la instrumente precum Pester și un instrument de monitorizare numit PRTG.

pentru a urmări sau pentru a vedea o versiune finalizată a instrumentului despre care veți afla în acest articol, descărcați scriptul ADHealthCheck-NoResult.ps1 de la GitHub.

definirea ieșire

având un tip de obiect comun și o modalitate ușoară de a genera va face mult mai ușor pentru a converti rezultatele testelor la instrumentul de alegerea ta.

pentru a crea o ieșire uniformă pentru toate instrumentele potențiale, am ales să folosesc o clasă PowerShell. Deși nu este necesar, este abordarea pe care am optat să o iau aici. Principalul punct este să vă asigurați că toate controalele de sănătate AD returnează același tip de ieșire.

o clasă PowerShell este o schemă care definește cum ar trebui să arate un obiect PowerShell și ce ar trebui să facă. Fiecare linie pe care o vedeți mai jos reprezintă o proprietate pe care o vor avea obiectele returnate. Puteti vedea mai jos sunt de planificare pe fiecare verificare de sănătate anunț pentru a reveni zece proprietăți.

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

pentru a accelera această clasă de creație, voi folosi o funcție helper numit New-AdhcResult. Această funcție creează clasa și tot ce va trebui să urmeze de-a lungul. Această funcție va afișa un obiect de tip personalizat .

rularea instrumentului de verificare a stării anunțului

mai întâi, descărcați și copiați scriptul de verificare a stării anunțului într-un controler de domeniu. Deschideți-l cu PowerShell ISE și rulați-l. Această parte a instrumentului nu va returna nicio informație.

scriptul Ths va rula și va stoca rezultatul fiecărei verificări în variabila $TestResults ca mai multe obiecte . Veți folosi aceste obiecte mai târziu pentru a genera rapoarte sau pentru a le scoate în diverse instrumente. Menținerea rezultatelor verificării sănătății într-o variabilă ca aceasta vă permite să adăugați mai multe rezultate dacă alegeți să creați alta și să utilizați comanda New-AdHcResult.

odată ce scriptul se termină de rulat, ar trebui să aveți acum un set complet de obiecte ad health check stocate în variabila $TestResults. Acum Puteți rula $TestResults din consolă și puteți vedea rezultatele brute.

afișarea rezultatelor verificării de sănătate a anunțului în instrumente

deoarece toate verificările sunt într-un tip de obiect comun, le puteți inspecta mai bine printr-un cuplu de instrumente precum Pester și PRTG.

în această secțiune, Veți învăța cum să creați un raport HTML cu un instrument numit extindere și să afișați raportul în PRTG.

crearea unui fișier XML nUnit cu Pester

mai întâi trebuie să convertiți obiectele PowerShell într-un format pe care instrumentele dvs. îl pot înțelege. Majoritatea instrumentelor înțeleg XML sau, mai precis, nUnit XML. Acesta este un format pe care îl puteți importa în diverse instrumente pentru a afișa rezultatele.

deoarece lucrați cu PowerShell, veți utiliza Cadrul de testare Pester pentru a citi rezultatul din scriptul de verificare a stării de sănătate a anunțului și pentru a genera un fișier XML nUnit

începeți prin descărcarea celei mai recente versiuni de Pester. Puteți descărca Pester rulând Install-Module într-o consolă PowerShell ridicată. Comanda de mai jos va forța o instalare a celei mai recente versiuni Pester. Deoarece certificatul de editor cu care este semnat Pester vine cu Windows 10, va trebui să folosim parametrul SkipPublisherCheck pentru a-l instala.

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

odată ce Pester este disponibil, puteți rula scriptul și puteți crea dinamic un set de teste Pester.

Notă: puteți crea, de asemenea, teste Pester-te fără a utiliza chiar Script PowerShell am furnizat.

scriptul PowerShell de mai jos va folosi Pester pentru a genera un fișier XML nUnit din ieșirea variabilei $TestResults definită în scriptul ADHealthCheck-NoResult.ps1.

salvați acest fișier ca Pester.ps1 în același folder cu scriptul de verificare a sănătății anunțului.

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

în cele din urmă, rulați Invoke-Pester mai jos pentru a invoca Pesterul.PS1 și salvați rezultatele în format NUnitXml.

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

construirea unui raport HTML cu instrumentul de extindere

odată ce aveți fișierul NUnit XML, puteți utiliza acum acest fișier pentru a trece la un instrument care poate converti în HTML. Unul dintre aceste instrumente se numește măsură. Măsura este un instrument util pentru crearea de rapoarte HTML din fișiere XML Nunit.

mai întâi, descărcați măsura în același director ca NunitReport.fișier xml creat mai devreme. Apoi executați următoarele comenzi într-o sesiune PowerShell. Aceste comenzi vor crea directorul pentru a stoca fișierele HTML și apoi executa măsură.exe pentru a face conversia.

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

când este complet, veți găsi două fișiere HTML în directorul HTMLReports. Aceste fișiere vor arata ca capturile de ecran de mai jos le deschideți cu un browser web.

ingerarea rezultatelor verificării sănătății anunțurilor în PRTG

PRTG este un instrument popular de monitorizare dezvoltat de Paessler pe care îl puteți utiliza pentru a vă monitoriza infrastructura și serviciile. În această secțiune, Veți învăța cum să împingeți rezultatele verificării de sănătate la PRTG odată ce scriptul verificării de sănătate a rulat.

împingerea rezultatelor către PRTG necesită mai multă muncă decât să aveți informațiile de tragere a instrumentului, dar în cele din urmă veți vedea că configurarea merită timpul petrecut.

cerințe preliminare

pentru a configura cu succes PRTG ca instrument de monitorizare pentru scriptul de verificare a sănătății anunțurilor construit în acest articol, asigurați-vă că aveți:

• PRTG instalat și configurat
• toate controlerele de domeniu stabilite în PRTG
• trimite-AdhcResultToPrtg.PS1 PowerShell script descărcat de la GitHub
• URL-ul și portul senzorului y0ur PRTG

dacă aveți fiecare dintre prereqs făcut, puteți urma instrucțiunile pas cu pas de mai jos cu privire la modul în care recomand să împingeți aceste rezultate de verificare a sănătății anunțului la PRTG.

1. creați un dispozitiv în PRTG numit domeniu sau orice nume preferați.
2. creați un senzor avansat de împingere HTTP cu o IdentityToken de director-adhealthcheck. Rețineți că acest lucru este sensibil la majuscule!
3. pentru fiecare dispozitiv de controler de domeniu din PRTG, creați un senzor avansat de împingere HTTP. Pentru fiecare IdentityToken, adăugați fiecare senzor cu-adhealthcheck, cum ar fi dc01-adhealthcheck.
4. adăugați conținutul scriptului PowerShell trimite-AdhcResultToPrtg.ps1 la sfârșitul scriptului PowerShell ADHealthCheck-NoResult.ps1 pe care l-am acoperit.
5. schimbați variabila $PRTGUrl la adresa URL și portul senzorului PRTG.
6. executați scriptul.

odată finalizat, odată ce scriptul de verificare a sănătății anunțului se finalizează, acesta ar trebui să împingă acum starea senzorilor PRTG așa cum se arată mai jos.

programarea scriptului Active Directory Health Check

monitorizarea stării de sănătate a anunțurilor este un proces continuu. Tu ar trebui să fie difuzate teste tot timpul, mai degrabă decât ad-hoc instanțe. Să programați Active Directory health check script pentru a rula la intervale frecvente.

cea mai ușoară cale de automatizare a acestor verificări este prin adăugarea scriptului la Planificatorul de activități și lăsarea acestuia să ruleze sub un cont de utilizator AD sau un cont de serviciu gestionat de grup.

utilizarea unui cont de serviciu gestionat de grup (gMSA) este modalitatea mai sigură de a executa sarcinile programate în mod autonom, deoarece numai conturile de computer specificate care pot prelua parola din AD. Dar este posibil ca unele organizații să nu aibă acest lux.

crearea unui cont de utilizator AD

să detaliem mai întâi ce este necesar pentru a configura un cont de utilizator AD pentru a rula sarcina programată.

dacă veți rula o sarcină programată ca cont de utilizator, prin toate mijloacele, nu o rulați ca cont propriu! Creați întotdeauna un cont de utilizator separat în acest scop.

pentru a economisi timp, veți vedea mai jos un script PowerShell. Acesta este un exemplu de script pe care îl puteți utiliza pentru a crea un cont de utilizator AD care face parte din grupul Administratori de domenii. Puteți utiliza apoi acest cont pentru a rula sarcina programată cu.

# 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

crearea unui cont de serviciu gestionat de grup

utilizarea unui gMSA pentru a rula verificarea de sănătate este un pic mai dificil dacă nu utilizați gMSA în mediul dvs. deja, dar este mult mai sigur.

crearea unei chei rădăcină KDS

pentru a crea un cont gMSA pentru a rula scriptul de verificare a stării anunțului, adăugați mai întâi o cheie rădăcină KDS dacă nu aveți deja una. Puteți verifica dacă aveți o cheie rădăcină KDS executând comanda PowerShell Get-KDSRootKey pe un controler de domeniu.

dacă nu aveți o cheie rădăcină KDS, creați una rulând Add-KDSRootKey -EffectiveImmediately sub un cont de utilizator parte a grupului de anunțuri Administratori de domeniu pe un controler de domeniu 2012R2 sau o versiune ulterioară.

cheia trebuie să se reproducă la alte controlere de domeniu pentru a avea efect deplin. Mai multe informații despre acest proces pot fi găsite în documentația Microsoft.

crearea gMSA

odată creată cheia rădăcină KDS, sunteți gata să creați contul gMSA cu PowerShell. Mai jos puteți vedea un exemplu de script de utilizat pentru a crea contul gMSA permis doar să se autentifice de la un controler de domeniu din grupul Administratori de domeniu.

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

instalarea și testarea gMSA

acum gMSA este creat, ultimul pas este de a instala și testa pe toate controlerele de domeniu. O modalitate de a face acest lucru este folosind comanda Invoke-Command PowerShell. Mai jos puteți vedea un script PowerShell care va instala gMSA pe toate DCs și vă va asigura că funcționează corect.

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

acordarea permisiunea gMSA pentru a rula ca un loc de muncă lot

odată ce gMSA este instalat, va trebui acum să-i dea permisiunea de a rula ca un loc de muncă lot pe DCs. Contul are nevoie de acest drept, deoarece va rula autonom în fundal într-o sarcină programată.

puteți seta această permisiune printr-un GPO existent sau prin crearea unui nou GPO și conectarea acestuia la controlerele de domeniu OU. Dacă nu aveți deja un GPO de utilizat, mai jos sunt câțiva pași pe care îi puteți face pentru a crea unul.

1. lansați editorul de Politici de grup pe un DC.
2. faceți clic dreapta pe controlerele de domeniu OU și selectați Creați GPO în acest domeniu și conectați-l aici.
3. denumiți – l DC-Logon ca lot sau alt nume pe care îl preferați
4. faceți clic dreapta pe GPO și faceți clic pe Editare.
5. accesați Configurare Computer –> Setări Windows –> Setări de securitate – > atribuirea drepturilor Utilizatorului.
6. Faceți clic stânga pe Log on ca lot job și faceți clic pe Proprietăți.
7. Faceți clic pe Adăugare utilizator sau grup.
8. Faceți clic pe tipuri de obiecte, selectați numai conturi de servicii și faceți clic pe OK.
9. căutați contul de serviciu svcADHealthCheck creat anterior, selectați-l și faceți clic pe OK.

ar trebui să vedeți acum gMSA sub lista de obiecte de anunțuri, cum ar fi prezentat mai jos.

crearea activității programate

acum, că aveți un cont creat pentru a rula activitățile programate, puteți crea acum activitatea programată în sine pe un server asociat domeniului la alegere.

puteți crea sarcina programată prin GUI, dar asta e prea mult clic! În schimb, vă recomand să îl creați cu PowerShell. De ce? Pentru că puteți copia pur și simplu codul pe care îl vedeți mai jos și puteți termina cu acesta.

mai jos veți găsi două scripturi; ambele scripturi sunt similare, dar unul presupune un cont de utilizator AD, iar celălalt presupune un gMSA. Asigurați-vă că utilizați scriptul corespunzător în funcție de contul pe care îl utilizați.

# 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

ai terminat! În acest moment, sarcina programată se va executa la intervalul furnizat într-unul din scripturile de mai sus.

Rezumat

Whew! Dacă ați urmat de-a lungul tot drumul de la Partea I, ar trebui să știți de acum că AD sănătate este un subiect profund. Există atât de multe în acest subiect încât nici măcar două postări lungi pe blog nu ar putea acoperi.

dar, până acum, ar trebui să aveți suficiente cunoștințe și un cadru PowerShell pre-construit pe care îl puteți conecta la alte verificări de sănătate Active Directory pe măsură ce apar.

lecturi suplimentare

• unele lucruri pe care s-ar putea să nu le știți despre AD și recuperarea în caz de dezastru
• ce face de fapt DCDIAG…?