Adam the Automator

Questa è la parte II di una serie in due parti sui controlli dello stato di Active Directory. Anche se non è necessaria la lettura, se vuoi imparare come lo script PowerShell che imparerai in questo articolo è stato costruito, sei incoraggiato a controllare la creazione di uno strumento di controllo dello stato di Active Directory: Parte I.

Nella parte I, hai imparato quanti diversi test multipli e perché sono importanti. Facciamo ora tirare tutti insieme e costruire uno strumento. In questa parte, convertirai tutti i controlli di integrità di Active Directory spiegati nella parte I in un framework di test. Imparerai anche come produrre i risultati di vari controlli dello stato degli annunci su strumenti come Pester e uno strumento di monitoraggio chiamato PRTG.

Per seguire o vedere una versione finita dello strumento che stai per conoscere in questo articolo, scarica lo script ADHealthCheck-NoResult.ps1 da GitHub.

Definire l’output

Avere un tipo di oggetto comune e un modo semplice per generarlo renderà molto più facile convertire i risultati dei test nello strumento di tua scelta.

Per creare un output uniforme per tutti i potenziali strumenti, ho scelto di utilizzare una classe PowerShell. Anche se non richiesto, è l’approccio che ho scelto di prendere qui. Il punto principale è garantire che tutti i controlli dello stato dell’ANNUNCIO restituiscano lo stesso tipo di output.

Una classe PowerShell è uno schema che definisce come dovrebbe apparire un oggetto PowerShell e cosa dovrebbe fare. Ogni riga che vedi sotto rappresenta una proprietà che gli oggetti restituiranno. Potete vedere qui sotto sto progettando su ogni controllo di salute ANNUNCIO per restituire dieci proprietà.

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

Per accelerare questa creazione di classi, userò una funzione di supporto chiamata New-AdhcResult. Questa funzione crea la classe e tutto il necessario per seguire. Questa funzione emetterà un oggetto di tipo personalizzato.

Esecuzione dello strumento di controllo dello stato dell’ANNUNCIO

Innanzitutto, scaricare e copiare lo script di controllo dello stato dell’ANNUNCIO in un controller di dominio. Aprilo con PowerShell ISE ed eseguilo. Questa parte dello strumento non restituirà alcuna informazione.

Lo script Ths verrà eseguito e memorizzerà il risultato di ogni controllo nella variabile $TestResults come più oggetti . Utilizzerai questi oggetti in seguito per generare report o inviarli in vari strumenti. Tenere i risultati del controllo dello stato in una variabile come questa consente di aggiungere altri risultati se si sceglie di crearne un altro e utilizzare il comando New-AdHcResult.

Una volta che lo script termina l’esecuzione, ora dovresti avere un set completo di oggetti di controllo dello stato di AD memorizzati nella variabile $TestResults. È ora possibile eseguire $TestResults dalla console e vedere i risultati grezzi.

Visualizzazione dei risultati del controllo dello stato degli ANNUNCI in Strumenti

Poiché tutti i controlli sono in un tipo di oggetto comune, è possibile ispezionarli meglio attraverso un paio di strumenti come Pester e PRTG.

In questa sezione, si sta andando a imparare come creare un report HTML con uno strumento chiamato extent e per visualizzare il report in PRTG.

Creazione di un file nUnit XML con Pester

Devi prima convertire gli oggetti PowerShell in un formato che i tuoi strumenti possono comprendere. La maggior parte degli strumenti comprende XML o, più specificamente, nUnit XML. Questo è un formato che è possibile importare in vari strumenti per visualizzare i risultati.

Poiché stai lavorando con PowerShell, userai il framework di test Pester per leggere l’output dallo script di controllo dello stato dell’ANNUNCIO e per generare un file XML nUnit

Inizia scaricando l’ultima versione di Pester. È possibile scaricare Pester eseguendo Install-Module in una console PowerShell elevata. Il comando sottostante forzerà l’installazione dell’ultima versione di Pester. Poiché il certificato del publisher con cui Pester è firmato viene fornito con Windows 10, sarà necessario utilizzare il parametro SkipPublisherCheck per installarlo.

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

Una volta che Pester è disponibile, è possibile eseguire lo script e creare dinamicamente una serie di test Pester.

Nota: Puoi anche creare test Pester da solo senza nemmeno usare lo script PowerShell che ho fornito.

Il seguente script PowerShell utilizzerà Pester per generare un file XML nUnit dall’output della variabile $TestResults definita nello script ADHealthCheck-NoResult.ps1.

Salva questo file come Pester. ps1 nella stessa cartella dello script di controllo dello stato dell’ANNUNCIO.

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

Infine, eseguire Invoke-Pester sotto per richiamare il Pester.ps1 e salvare i risultati in formato NUnitXml.

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

Creazione di un report HTML con lo strumento Extent

Una volta ottenuto il file NUnit XML, è ora possibile utilizzare questo file per passare a uno strumento in grado di convertirlo in HTML. Uno di questi strumenti si chiama extent. Extent è uno strumento utile per la creazione di report HTML da file XML Nunit.

Innanzitutto, scarica extent nella stessa directory del NunitReport.file xml creato in precedenza. Quindi eseguire i seguenti comandi in una sessione PowerShell. Questi comandi creeranno la directory per archiviare i file HTML e quindi eseguiranno extent.exe per fare la conversione.

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

Al termine, troverete due file HTML nella directory HTMLReports. Questi file si presenta come gli screenshot qui sotto li si apre con un browser web.

L’ingestione di ANNUNCI di Salute e Controllare i Risultati in PRTG

PRTG è un popolare strumento di monitoraggio sviluppato da Paessler che è possibile utilizzare per monitorare le infrastrutture e i servizi. In questa sezione, imparerai come inviare i risultati del controllo dello stato a PRTG una volta eseguito lo script di controllo dello stato.

Spingere i risultati su PRTG richiede più lavoro piuttosto che avere le informazioni sullo strumento, ma alla fine vedrai che la configurazione vale il tempo speso.

Prerequisiti

Per impostare correttamente PRTG come strumento di monitoraggio per l’ANNUNCIO health check script creato in questo articolo, assicurarsi di aver:

• PRTG installato e configurato
• Tutti i controller di dominio impostare in PRTG
• Invio-AdhcResultToPrtg.ps1 PowerShell script scaricato da GitHub
• l’URL e la porta di y0ur PRTG sensor

Se hai fatto ciascuno dei prereq, puoi seguire le istruzioni passo-passo riportate di seguito su come consiglio di inviare questi risultati del controllo dello stato degli annunci a PRTG.

1. Crea un dispositivo in PRTG chiamato Domain o qualsiasi nome tu preferisca.
2. Crea un sensore push HTTP avanzato con un IdentityToken di directory-adhealthcheck. Si noti che questo è case sensitive!
3. Per ogni dispositivo controller di dominio in PRTG, creare un sensore push HTTP avanzato. Per ogni IdentityToken, aggiungere ogni sensore con-adhealthcheck come dc01-adhealthcheck.
4. Aggiungi il contenuto dello script PowerShell Send-AdhcResultToPrtg.ps1 alla fine dello script PowerShell ADHealthCheck-NoResult.ps1 che abbiamo trattato.
5. Modificare la variabile $PRTGUrl nell’URL e nella porta del sensore PRTG.
6. Esegui lo script.

Una volta completato, una volta completato lo script di controllo dello stato dell’ANNUNCIO, dovrebbe ora spingere lo stato ai sensori PRTG come mostrato di seguito.

La pianificazione dello script di controllo dello stato di Active Directory

Il monitoraggio dello stato degli annunci è un processo in corso. Dovresti eseguire test tutto il tempo piuttosto che istanze ad hoc. Pianifichiamo lo script di controllo dello stato di Active Directory per l’esecuzione a intervalli frequenti.

Il percorso più semplice per automatizzare questi controlli consiste nell’aggiungere lo script all’utilità di pianificazione e lasciarlo funzionare con un account utente AD o un account di servizio gestito dal gruppo.

L’utilizzo di un account di servizio gestito di gruppo (gMSA) è il modo più sicuro per eseguire autonomamente le attività pianificate poiché solo gli account di computer specificati possono recuperare la password da AD. Ma alcune organizzazioni potrebbero non avere questo lusso.

Creazione di un account utente AD

Analizziamo innanzitutto ciò che serve per impostare un account utente AD per eseguire l’attività pianificata.

Se stai per eseguire un’attività pianificata come account utente, con tutti i mezzi, non eseguirla come account personale! Crea sempre un account utente separato per questo scopo.

Per risparmiare tempo, vedrai uno script PowerShell di seguito. Questo è uno script di esempio che puoi utilizzare per creare un account utente AD che fa parte del gruppo Domain Admins. È quindi possibile utilizzare questo account per eseguire attività pianificate con.

# 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

Creare un account di servizio gestito dal gruppo

Utilizzare un gMSA per eseguire il controllo dello stato è un po ‘ più complicato se non si utilizza già gMSA nel proprio ambiente, ma è molto più sicuro.

Creazione di una chiave root KDS

Per creare un account gMSA per eseguire lo script di controllo dello stato dell’ANNUNCIO, prima aggiungi una chiave root KDS se non ne hai già una. È possibile verificare se si dispone di una chiave root KDS eseguendo il comando PowerShell Get-KDSRootKey su un controller di dominio.

Se non si dispone di una chiave root KDS, crearne una eseguendo Add-KDSRootKey -EffectiveImmediately in un account utente parte del gruppo di ANNUNCI Domain Admins su un controller di dominio 2012R2 o successivo.

La chiave deve replicarsi agli altri controller di dominio per avere pieno effetto. Ulteriori informazioni su questo processo possono essere trovate nella documentazione di Microsoft.

Creazione di gMSA

Una volta creata la chiave root di KDS, si è pronti a creare l’account gMSA con PowerShell. Di seguito è riportato uno script di esempio da utilizzare per creare l’account gMSA consentito solo per l’autenticazione da un controller di dominio nel gruppo Domain Admins.

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

Installazione e test del gMSA

Ora il gMSA viene creato, l’ultimo passo è quello di installare e testare su tutti i controller di dominio. Un modo per farlo è usare il comando Invoke-Command PowerShell. Di seguito puoi vedere uno script PowerShell che installerà gMSA su tutti i DCS e assicurerà che funzioni correttamente.

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

Dare il permesso gMSA per eseguire come un lavoro batch

Una volta che il gMSA è installato, è ora necessario dare il permesso di eseguire come un lavoro batch sul DCS. L’account ha bisogno di questo diritto poiché verrà eseguito autonomamente in background in un’attività pianificata.

È possibile impostare questa autorizzazione tramite un GPO esistente o creando un nuovo GPO e collegandolo ai Controller di dominio OU. Se non hai già un GPO da usare, di seguito sono riportati alcuni passaggi che puoi eseguire per crearne uno.

1. Avviare l’editor criteri di gruppo su un DC.
2. Fare clic destro sul Controller di dominio OU e selezionare Crea GPO in questo dominio e collegarlo qui.
3. Denominalo DC-Logon come batch o un altro nome che preferisci
4. Fai clic con il pulsante destro del mouse sul GPO e fai clic su Modifica.
5. Vai a Configurazione computer –> Impostazioni di Windows –> Impostazioni di sicurezza – > Assegnazione diritti utente.
6. Fare clic con il tasto sinistro del mouse su Accedi come lavoro batch e fare clic su Proprietà.
7. Fare clic su Aggiungi utente o gruppo.
8. Fare clic su Tipi di oggetto, selezionare solo account di servizio e fare clic su OK.
9. Cerca l’account del servizio svcADHealthCheck creato in precedenza, selezionalo e fai clic su OK.

Ora dovresti vedere il gMSA sotto l’elenco degli oggetti AD come mostrato di seguito.

Creazione di Attività Pianificate

Ora che si dispone di un account creato per eseguire le operazioni pianificate, è ora possibile creare un’operazione pianificata su un dominio server di vostra scelta.

È possibile creare l’attività pianificata tramite la GUI, ma è troppo clic! Invece, consiglio di crearlo con PowerShell. Perché? Perché si può semplicemente copiare il codice che vedete qui sotto ed essere fatto con esso.

Di seguito troverai due script; entrambi gli script sono simili, ma uno assume un account utente AD e l’altro assume un gMSA. Assicurati di utilizzare lo script appropriato in base all’account che stai utilizzando.

# 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

Hai finito! A questo punto, l’attività pianificata verrà eseguita all’intervallo fornito in uno degli script sopra.

Sommario

Whew! Se avete seguito lungo tutta la strada dalla parte I, si dovrebbe sapere ormai che la salute ANNUNCIO è un argomento profondo. C’è così tanto in questo argomento che nemmeno due lunghi post del blog potrebbero coprire.

Ma, ormai, dovresti avere abbastanza conoscenza e un framework PowerShell pre-costruito che puoi collegare ad altri controlli di integrità di Active Directory man mano che si presentano.

Ulteriori letture

• Alcune cose che potresti non sapere su AD e Disaster Recovery
• Cosa fa effettivamente DCDIAG do?