Controllo dello stato di salute di Active Directory con il framework PowerShell

Tutorial
PowerShell

Questa è la parte II di una serie in due parti sugli Active Directory health checks. Sebbene non sia necessaria la lettura, se desideri scoprire come è stato creato lo script PowerShell che imparerai in questo articolo, ti incoraggio a dare un’occhiata a Building an Active Directory Health Check Tool [Approfondito]: Parte I.

Nella Parte I, hai appreso quanti diversi test multipli e perché sono importanti. Ora mettiamoli tutti insieme e creiamo uno strumento. In questa parte, convertirai tutti gli Active Directory health checks spiegati nella Parte I in un framework di test. Imparerai anche come visualizzare i risultati di vari controlli di salute AD in strumenti come Pester e un tool di monitoraggio chiamato PRTG.

Per seguire o vedere una versione completa dello strumento di cui parlerai in questo articolo, scarica lo script ADHealthCheck-NoResult.ps1 da GitHub.

Definizione dell’Output

Avere un tipo di oggetto comune e un modo semplice per generarli renderà molto più facile convertire i risultati dei test nello strumento da te scelto.

Per creare un output uniforme per tutti gli strumenti potenziali, ho scelto di utilizzare una classe PowerShell. Sebbene non sia necessario, è l’approccio che ho scelto qui. Il punto principale è assicurarsi che tutti i controlli di salute AD restituiscano lo stesso tipo di output.

A PowerShell class is a schema that defines how a PowerShell object should look and what it should do. Each line you see below represents a property the objects return will have. You can see below I’m planning on each AD health check to return ten properties.

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

Per velocizzare la creazione di questa classe, utilizzerò una funzione di aiuto chiamata New-AdhcResult. Questa funzione crea la classe e tutto ciò di cui avrai bisogno per seguirla. Questa funzione restituirà un oggetto di tipo [AdhcResult] personalizzato.

Esecuzione dello Strumento di Controllo della Salute AD

Per prima cosa, scarica e copia lo script di controllo della salute AD su un controller di dominio. Aprilo con PowerShell ISE ed eseguilo. Questa parte dello strumento non restituirà alcuna informazione.

Lo script verrà eseguito e memorizzerà il risultato di ciascun controllo nella variabile $TestResults come più oggetti [AdhcResult]. Utilizzerai questi oggetti in seguito per generare rapporti o per emetterli in vari strumenti. Conservare i risultati del controllo della salute in una variabile del genere ti consente di aggiungere ulteriori risultati se decidi di crearne un altro e utilizzare il comando New-AdHcResult.

Una volta completata l’esecuzione dello script, dovresti ora avere un set completo di oggetti di controllo della salute AD memorizzati nella variabile $TestResults. Ora puoi eseguire $TestResults dalla console e visualizzare i risultati grezzi.

Visualizzazione dei Risultati del Controllo della Salute AD negli Strumenti

Dato che tutti i controlli sono in un tipo di oggetto comune, puoi ispezionarli meglio attraverso un paio di strumenti come Pester e PRTG.

In questa sezione, imparerai come creare un rapporto HTML con uno strumento chiamato extent e visualizzare il rapporto in PRTG.

Creare un file XML nUnit con Pester

Prima di tutto, devi convertire gli oggetti PowerShell in un formato comprensibile dai tuoi strumenti. La maggior parte degli strumenti comprende XML o, più specificamente, XML nUnit. Questo è un formato che puoi importare in vari strumenti per visualizzare i risultati.

Dato che stai lavorando con PowerShell, userai il framework di test Pester per leggere l’output dello script di verifica della salute di AD e generare un file XML nUnit

Inizia scaricando l’ultima versione di Pester. Puoi scaricare Pester eseguendo Install-Module in una console PowerShell con privilegi elevati. Il comando seguente forzerà l’installazione dell’ultima versione di Pester. Poiché il certificato publisher con cui Pester è firmato è incluso in Windows 10, dovremo utilizzare il parametro SkipPublisherCheck per installarlo.

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

Una volta che Pester è disponibile, puoi eseguire lo script e creare dinamicamente un set di test Pester.

Nota: Puoi anche creare tu stesso i test Pester senza utilizzare lo script PowerShell che ho fornito.

Lo script PowerShell seguente 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 della salute di AD.

# Includi nel file ADHealthCheck
. $PSScriptRoot\ADHealthCheck-NoResult.ps1
$Grouped = $TestResults | Group-Object Category

Foreach($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, esegui Invoke-Pester qui sotto per invocare il file Pester.ps1 e salvare i risultati nel formato NUnitXml.

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

Creazione di un rapporto HTML con lo strumento Extent

Una volta ottenuto il file XML di NUnit, puoi ora utilizzarlo per passarlo a uno strumento che può convertirlo in HTML. Uno di quegli strumenti si chiama extent. Extent è uno strumento utile per creare rapporti HTML da file XML di Nunit.

Prima di tutto, scarica extent nella stessa directory del file NunitReport.xml creato in precedenza. Quindi esegui i seguenti comandi in una sessione di PowerShell. Questi comandi creeranno la directory per memorizzare i file HTML e quindi eseguiranno extent.exe per effettuare la conversione.

# Crea la directory del rapporto
PS51> mkdir .\HTMLReports

# Crea il rapporto
PS51> .\extent.exe -i .\NunitReport.xml -o .\HTMLReports\

Una volta completato, troverai due file HTML nella directory HTMLReports. Questi file assomiglieranno alle schermate sottostanti quando li apri con un browser web.

HTML report for Pester test output
HTML report for Pester test output

Incorporazione dei risultati del controllo della salute di AD in PRTG

PRTG è un popolare strumento di monitoraggio sviluppato da Paessler che puoi utilizzare per monitorare la tua infrastruttura e i tuoi servizi. In questa sezione, imparerai come inviare i risultati del controllo di salute a PRTG una volta eseguito lo script di controllo di salute.

Inviare i risultati a PRTG richiede più lavoro rispetto a far sì che lo strumento prelevi le informazioni, ma alla fine vedrai che la configurazione varrà il tempo impiegato.

Prerequisiti

Per impostare correttamente PRTG come strumento di monitoraggio per lo script di controllo di salute AD creato in questo articolo, assicurati di avere:

  • PRTG installato e configurato
  • Tutti i controller di dominio configurati in PRTG
  • Lo script PowerShell Send-AdhcResultToPrtg.ps1 scaricato da GitHub
  • L’URL e la porta del tuo sensore PRTG

Se hai completato ognuno dei prerequisiti, puoi seguire le istruzioni passo passo di seguito su come consiglio di inviare questi risultati del controllo di salute AD a PRTG.

  1. Crea un dispositivo in PRTG chiamato Domain o con il nome che preferisci.
  2. Crea un sensore push HTTP avanzato con un IdentityToken di directory-adhealthcheck. Nota che è sensibile alle maiuscole e minuscole!
  3. Per ogni dispositivo controller di dominio in PRTG, crea un sensore push HTTP avanzato. Per ogni IdentityToken, aggiungi a ciascun sensore -adhealthcheck come ad esempio dc01-adhealthcheck.
  4. Aggiungi i contenuti dello script PowerShell Send-AdhcResultToPrtg.ps1 alla fine dello script PowerShell ADHealthCheck-NoResult.ps1 che abbiamo trattato.
  5. Modifica la variabile $PRTGUrl con l’URL e la porta del tuo sensore PRTG.
  6. Esegui lo script.

Una volta completato, quando lo script di controllo della salute di AD completa l’esecuzione, dovrebbe ora inviare lo stato ai tuoi sensori PRTG come mostrato di seguito.

PRTG sensors showing AD health

Programmazione dello Script di Controllo della Salute di Active Directory

Monitorare la salute di AD è un processo continuo. Dovresti eseguire test tutto il tempo piuttosto che istanze ad-hoc. Vediamo come programmare lo script di controllo della salute di Active Directory per eseguirsi a intervalli frequenti.

Il modo più semplice di automatizzare questi controlli è aggiungere lo script al pianificatore attività e farlo eseguire con un account utente AD o un Account di Servizio Gestito dal Gruppo.

Utilizzare un Account di Servizio Gestito dal Gruppo (gMSA) è il modo più sicuro per eseguire attività pianificate autonomamente poiché solo gli account computer specificati possono recuperare la password da AD. Tuttavia, alcune organizzazioni potrebbero non avere questa opportunità.

Creazione di un Account Utente AD

Iniziamo analizzando cosa serve per configurare un account utente AD per eseguire il compito pianificato.

Se prevedi di eseguire un’attività pianificata come account utente, per favore, non farlo come tuo account personale! Crea sempre un account utente separato a questo scopo.

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

# Cambia questo con l'OU dei tuoi account di servizio
$OU = "OU=Service Accounts,DC=contoso,DC=com"
# Cambia questo con la password che desideri utilizzare per l'account
$Password = "JägareTvå"
$SecureString = $Password | ConvertTo-SecureString -AsPlainText -Force
New-ADUser -Enabled $True -Path $OU -Name svcADHealthCheck -AccountPassword $SecureString
# Limita l'account solo ai controller di dominio
$DomainControllers = (Get-ADDomainController -Filter *).Name

Set-ADAccount -Identity svcADHealthCheck -LogonWorkstations ($DomainControllers -Join ",")

# Rendendolo Amministratore di Dominio (Spiacente)
Add-ADGroupMember -Identity "Domain Admins" -Members svcADHealthCheck

Creazione di un Account di Servizio Gestito dal Gruppo

Utilizzare un gMSA per eseguire il controllo dello stato di salute è un po’ più complicato se non stai già utilizzando gMSA nel tuo ambiente, ma è molto più sicuro.

Creazione di una Chiave Radice KDS

Per creare un account gMSA per eseguire lo script di controllo dello stato di salute di AD, aggiungi prima una chiave radice KDS se non ne hai già una. Puoi verificare se hai una chiave radice KDS eseguendo il comando PowerShell Get-KDSRootKey su un controller di dominio.

Se non si dispone di una chiave radice KDS, è possibile crearne una eseguendo Add-KDSRootKey -EffectiveImmediately con un account utente che fa parte del gruppo Domain Admins AD su un controller di dominio 2012R2 o successivo.

La chiave deve essere replicata agli altri controller di dominio per avere pieno effetto. Ulteriori informazioni su questo processo sono disponibili nella documentazione Microsoft.

Creazione del gMSA

Una volta creata la chiave radice KDS, è possibile 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.

# Cambiare con il proprio dominio
$Domain = "contoso.com"

$AccountName = "svcadhealthcheck"

# Creare un GMSA chiamato svcadhealthcheck (o in realtà svcadhealthcheck$) e consentire solo ai controller di dominio di recuperare la password
New-ADServiceAccount $AccountName -DNSHostName "$AccountName.$Domain" –PrincipalsAllowedToRetrieveManagedPassword "Domain Controllers"

# Aggiungere il GMSA a Domain Admins
# Nota che stiamo aggiungendo l'account con il vero SamAccountName 'svcadhealthcheck$'
Add-ADGroupMember -Identity "Domain Admins" -Members "$AccountName`$"

Installazione e test del gMSA

Ora che il gMSA è stato creato, l’ultimo passo è installarlo e testarlo su tutti i controller di dominio. Un modo per farlo è utilizzare il comando PowerShell Invoke-Command. Di seguito puoi vedere uno script PowerShell che installerà il gMSA su tutti i DC e garantirà che funzioni correttamente.

# Questo verrà eseguito su tutti i controller di dominio
Invoke-Command -ComputerName (Get-ADDomainController -Filter *).Name -ScriptBlock {
    $Account = Get-ADServiceAccount -Filter { Name -eq 'svcadhealthcheck'}
    Install-ADServiceAccount $Account

    # Testa che il GMSA funzioni sul computer
    # Restituisce $True se i test sono 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 al gMSA di eseguire un lavoro batch

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

Puoi impostare questo permesso tramite una GPO esistente o creandone una nuova e collegandola all’OU Controller di dominio. Se non hai già una GPO da utilizzare, di seguito sono riportati alcuni passaggi che puoi seguire per crearne una.

  1. Avvia l’Editor delle Policy del Gruppo su un DC.
  2. Fai clic con il pulsante destro del mouse sull’OU Controller di dominio e seleziona Crea GPO in questo dominio e collegalo qui.
  3. Dagli un nome come DC – Esegui come batch o un altro nome che preferisci
  4. Fai clic con il pulsante destro del mouse sulla GPO e seleziona Modifica.
  5. Vai su Configurazione computer –> Impostazioni Windows –> Impostazioni di sicurezza –> Diritti utente assegnati.
  6. Fare clic sinistro su Accedi come attività batch e fare clic su Proprietà.
  7. Fare clic su Aggiungi utente o Gruppo
  8. Fare clic su Tipo di Oggetto, selezionare solo Account Servizio e fare clic su OK.
  9. Cercare l’account del servizio svcADHealthCheck creato in precedenza, selezionarlo e fare clic su OK.

Ora dovresti vedere la gMSA nell’elenco degli oggetti AD come mostrato di seguito.

gMSA given rights to logon as a batch job

Creazione dell’attività pianificata

Ora che hai creato un account per eseguire le attività pianificate, puoi creare l’attività pianificata stessa su un server connesso al dominio a tua scelta.

Puoi creare l’attività pianificata tramite l’interfaccia grafica, ma ciò richiede troppi clic! Invece, ti consiglio di crearla con PowerShell. Perché? Perché puoi semplicemente copiare il codice che vedi qui sotto e basta.

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

# Sostituisci con il percorso del tuo script
$ScriptPath = "C:\Scripts\ADHealthCheck.ps1"
# Sostituisci con il nome utente dell'account che hai creato per eseguire il compito
$UserName = "svdADHealthCheck"

# Sostituisci con la password che hai impostato per l'account sopra
$Password = "JägareTvå!"
# Crea l'azione che avvia lo script
$Action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-ExecutionPolicy bypass -File '$ScriptPath'"
# Crea il trigger che avvia il compito
$Trigger = New-ScheduledTaskTrigger -Once -At "12:00" -RepetitionInterval (New-TimeSpan -Hours 12)
# Crea le impostazioni per il compito pianificato
$Settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries -StartWhenAvailable -RunOnlyIfNetworkAvailable -DontStopOnIdleEnd
# Crea il compito pianificato utilizzando uno splat per la leggibilità
$Splat = @{
    User = "$env:USERDOMAIN\$UserName"
    Password = $Password
    TaskName = "ADHealthCheck"
    Action = $Action
    Trigger = $Trigger
    RunLevel = "Highest"
    Settings = $Settings
}
Register-ScheduledTask @Splat
# Sostituisci con il percorso del tuo script
$ScriptPath = "C:\Scripts\ADHealthCheck.ps1"
# Sostituisci con il nome utente dell'account che hai creato per eseguire il compito
$UserName = "svdADHealthCheck$"
# Crea l'azione che avvia lo script
$Action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-ExecutionPolicy bypass -File '$ScriptPath'"
# Crea il trigger che avvia il compito
$Trigger = New-ScheduledTaskTrigger -Once -At "12:00" -RepetitionInterval (New-TimeSpan -Hours 12)
# Crea le impostazioni per il compito pianificato
$Settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries -StartWhenAvailable -RunOnlyIfNetworkAvailable -DontStopOnIdleEnd

# Crea il principale che definisce il GMSA
$Principal = New-ScheduledTaskPrincipal -UserID "$env:USERDOMAIN\$UserName" -LogonType Password -RunLevel Highest
# Crea il compito pianificato utilizzando uno splat per la leggibilità
$Splat = @{
    Principal = $Principal
    TaskName = "ADHealthCheck"
    Action = $Action
    Trigger = $Trigger
    RunLevel = "Highest"
    Settings = $Settings
}
Register-ScheduledTask @Splat

Hai finito! In questo momento, il compito pianificato verrà eseguito con l’intervallo fornito in uno dei script sopra.

Summary

Uff! Se hai seguito fino a qui dalla Parte I, dovresti ormai sapere che la salute di AD è un argomento complesso. C’è così tanto da dire su questo argomento che nemmeno due lunghi post potrebbero coprire tutto.

Ma, a questo punto, dovresti avere abbastanza conoscenza e un framework PowerShell pre-costruito che puoi utilizzare per altri controlli di salute di Active Directory che possono sorgere.

Ulteriori letture

Source:
https://adamtheautomator.com/active-directory-health-check-2/