Verificação de Saúde do Active Directory com o Framework PowerShell

Tutoriais
PowerShell

Esta é a parte II de uma série de duas partes sobre verificações de integridade do Active Directory. Embora não seja necessário ler, se você quiser aprender como o script do PowerShell sobre o qual você aprenderá neste artigo foi construído, você é encorajado a verificar Construindo uma Ferramenta de Verificação de Integridade do Active Directory [Em Profundidade]: Parte I.

Na Parte I, você aprendeu quantos testes diferentes múltiplos e por que eles são importantes. Agora vamos juntá-los todos e construir uma ferramenta. Nesta parte, você converterá todas as verificações de integridade do Active Directory explicadas na Parte I em um framework de teste. Você também aprenderá como produzir resultados de várias verificações de integridade do AD para ferramentas como o Pester e uma ferramenta de monitoramento chamada PRTG.

Para acompanhar ou ver uma versão final da ferramenta sobre a qual você aprenderá neste artigo, baixe o script ADHealthCheck-NoResult.ps1 do GitHub.

Definindo Saída

Ter um tipo de objeto comum e uma maneira fácil de gerá-lo facilitará muito a conversão dos resultados dos testes para a ferramenta de sua escolha.

Para criar uma saída uniforme para todas as ferramentas potenciais, escolhi usar uma classe PowerShell. Embora não seja necessário, é a abordagem que optei por tomar aqui. O ponto principal é garantir que todas as verificações de integridade do AD retornem o mesmo tipo de saída.

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
}

Para acelerar a criação desta classe, vou usar uma função auxiliar chamada New-AdhcResult. Esta função cria a classe e tudo o que você precisa para acompanhar. Esta função irá produzir um objeto do tipo [AdhcResult] personalizado.

Executando a Ferramenta de Verificação de Saúde do AD

Primeiro, baixe e copie o script de verificação de saúde do AD para um controlador de domínio. Abra-o com o PowerShell ISE e execute-o. Esta parte da ferramenta não retornará nenhuma informação.

Este script será executado e armazenará o resultado de cada verificação na variável $TestResults como múltiplos objetos [AdhcResult]. Você usará esses objetos mais tarde para gerar relatórios ou emitir em várias ferramentas. Manter os resultados da verificação de saúde em uma variável como esta permite adicionar mais resultados caso opte por criar outro e usar o comando New-AdHcResult.

Assim que o script terminar de ser executado, você deverá agora ter um conjunto completo de objetos de verificação de saúde do AD armazenados na variável $TestResults. Agora você pode executar $TestResults a partir do console e ver os resultados brutos.

Exibindo os Resultados da Verificação de Saúde do AD em Ferramentas

Como todas as verificações estão em um tipo de objeto comum, você pode inspecioná-las melhor através de algumas ferramentas como Pester e PRTG.

Nesta seção, você vai aprender como criar um relatório HTML com uma ferramenta chamada extent e exibir o relatório no PRTG.

Criando um Arquivo XML do nUnit com o Pester

Primeiro, você precisa converter os objetos do PowerShell em um formato que suas ferramentas possam entender. A maioria das ferramentas entende XML ou, mais especificamente, XML do nUnit. Este é um formato que você pode importar para várias ferramentas para exibir resultados.

Como você está trabalhando com PowerShell, usará o framework de teste Pester para ler a saída do script de verificação de saúde do AD e gerar um arquivo XML do nUnit

Comece baixando a versão mais recente do Pester. Você pode baixar o Pester executando Install-Module em um console do PowerShell elevado. O comando abaixo forçará uma instalação da versão mais recente do Pester. Como o certificado do editor certificate que o Pester é assinado vem com o Windows 10, precisaremos usar o parâmetro SkipPublisherCheck para instalá-lo.

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

Depois que o Pester estiver disponível, você poderá executar o script e criar dinamicamente um conjunto de testes do Pester.

Observação: Você também pode criar testes do Pester você mesmo sem nem mesmo usar o script do PowerShell que forneci.

O script do PowerShell abaixo usará o Pester para gerar um arquivo XML do nUnit a partir da saída da variável $TestResults definida no script ADHealthCheck-NoResult.ps1.

Guarde este arquivo como Pester.ps1 na mesma pasta que o script de verificação de saúde do AD. 

# inclua o arquivo 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
                }
            }
        }
    }
}

Por fim, execute Invoke-Pester abaixo para invocar o arquivo Pester.ps1 e salvar os resultados no formato NUnitXml. 

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

Construindo um Relatório HTML com a Ferramenta Extent

Depois de obter o arquivo XML do NUnit, você pode usá-lo para passar para uma ferramenta que possa convertê-lo em HTML. Uma dessas ferramentas é chamada de extent. Extent é uma ferramenta útil para criar relatórios HTML a partir de arquivos XML do Nunit.

Primeiro, baixe o extent para o mesmo diretório que o arquivo NunitReport.xml criado anteriormente. Em seguida, execute os seguintes comandos em uma sessão do PowerShell. Esses comandos criarão o diretório para armazenar os arquivos HTML e, em seguida, executarão extent.exe para fazer a conversão. 

# Criar diretório de relatório
PS51> mkdir .\HTMLReports

# Criar o relatório
PS51> .\extent.exe -i .\NunitReport.xml -o .\HTMLReports\

Quando concluído, você encontrará dois arquivos HTML no diretório HTMLReports. Esses arquivos terão a aparência das capturas de tela abaixo quando abertos em um navegador da web.

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

Ingerindo Resultados de Verificação de Saúde do AD no PRTG

O PRTG é uma ferramenta de monitoramento popular desenvolvida pela Paessler que você pode usar para monitorar sua infraestrutura e serviços. Nesta seção, você aprenderá como enviar os resultados da verificação de integridade para o PRTG assim que o script de verificação de integridade for executado.

Enviar resultados para o PRTG requer mais trabalho do que ter a ferramenta puxando informações, mas você eventualmente verá que a configuração vale o tempo gasto.

Pré-requisitos

Para configurar com sucesso o PRTG como uma ferramenta de monitoramento para o script de verificação de integridade do AD construído neste artigo, certifique-se de ter:

  • O PRTG instalado e configurado
  • Todos os controladores de domínio configurados no PRTG
  • O Send-AdhcResultToPrtg.ps1 script do PowerShell baixado do GitHub
  • A URL e a porta do seu sensor PRTG

Se você tiver cada um dos pré-requisitos concluídos, então você pode seguir as instruções passo a passo abaixo sobre como eu recomendo enviar esses resultados da verificação de integridade do AD para o PRTG.

  1. Crie um dispositivo no PRTG chamado Domain ou qualquer nome que você preferir.
  2. Crie um sensor de envio HTTP avançado com um Token de Identidade de directory-adhealthcheck. Note que isso diferencia maiúsculas de minúsculas!
  3. Para cada dispositivo do controlador de domínio no PRTG, crie um sensor de envio HTTP avançado. Para cada Token de Identidade, acrescente cada sensor com -adhealthcheck como dc01-adhealthcheck.
  4. Adicione o conteúdo do script PowerShell Send-AdhcResultToPrtg.ps1 ao final do script PowerShell ADHealthCheck-NoResult.ps1 que abordamos anteriormente.
  5. Altere a variável $PRTGUrl para o URL e porta do seu sensor PRTG.
  6. Execute o script.

Uma vez concluído, após a conclusão do script de verificação de saúde do AD, ele deverá agora enviar o status para seus sensores PRTG conforme mostrado abaixo.

PRTG sensors showing AD health

Agendando o Script de Verificação de Saúde do Active Directory

Monitorar a saúde do AD é um processo contínuo. Você deve estar executando testes o tempo todo em vez de instâncias ad hoc. Vamos agendar o script de verificação de saúde do Active Directory para ser executado em intervalos frequentes.

A maneira mais fácil de automatizar essas verificações é adicionando o script ao agendador de tarefas e permitindo que ele seja executado sob uma conta de usuário AD ou uma Conta de Serviço Gerenciada em Grupo.

Usar uma Conta de Serviço Gerenciada em Grupo (gMSA) é a maneira mais segura de executar tarefas agendadas autonomamente, pois apenas as contas de computador especificadas podem buscar a senha do AD. Mas algumas organizações podem não ter esse luxo.

Criando uma Conta de Usuário AD

Vamos primeiro analisar o que é necessário para configurar uma conta de usuário AD para executar a tarefa agendada.

Se você vai executar uma tarefa agendada como uma conta de usuário, por favor, não a execute como sua própria conta! Sempre crie uma conta de usuário separada para esse fim.

Para economizar tempo, você verá abaixo um script do PowerShell. Este é um exemplo de script que você pode usar para criar uma conta de usuário do AD que faça parte do grupo Domain Admins. Você pode então usar essa conta para executar tarefas agendadas.

# Altere isso para a OU de suas contas de serviço
$OU = "OU=Service Accounts,DC=contoso,DC=com"
# Altere isso para a senha que você deseja usar para a conta
$Password = "JägareTvå"
$SecureString = $Password | ConvertTo-SecureString -AsPlainText -Force
New-ADUser -Enabled $True -Path $OU -Name svcADHealthCheck -AccountPassword $SecureString
# Restringir conta apenas a Controladores de Domínio
$DomainControllers = (Get-ADDomainController -Filter *).Name

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

# Tornando-o Administrador de Domínio (Desculpe)
Add-ADGroupMember -Identity "Domain Admins" -Members svcADHealthCheck

Criando uma Conta de Serviço Gerenciada por Grupo

Usar uma gMSA para executar a verificação de integridade é um pouco mais complicado se você ainda não estiver usando gMSA em seu ambiente, mas é muito mais seguro.

Criando uma Chave Raiz do KDS

Para criar uma conta gMSA para executar o script de verificação de integridade do AD, primeiro adicione uma chave raiz do KDS se você ainda não tiver uma. Você pode verificar se tem uma chave raiz do KDS executando o comando do PowerShell Get-KDSRootKey em um controlador de domínio.

Se você não tiver uma chave raiz KDS, você pode criar uma executando Add-KDSRootKey -EffectiveImmediately sob uma conta de usuário que faça parte do grupo AD de Administradores de Domínio em um controlador de domínio 2012R2 ou posterior.

A chave precisa ser replicada para os outros controladores de domínio para ter efeito total. Mais informações sobre este processo podem ser encontradas na documentação da Microsoft.

Criando o gMSA

Depois que a chave raiz KDS for criada, você estará pronto para criar a conta gMSA com o PowerShell. Abaixo você pode ver um exemplo de script para criar a conta gMSA permitida apenas para autenticar de um controlador de domínio no grupo Administradores de Domínio.

# Altere para o seu domínio
$Domain = "contoso.com"

$AccountName = "svcadhealthcheck"

# Crie um GMSA chamado svcadhealthcheck (ou na realidade svcadhealthcheck$) e permita apenas que Controladores de Domínio busquem a senha
New-ADServiceAccount $AccountName -DNSHostName "$AccountName.$Domain" –PrincipalsAllowedToRetrieveManagedPassword "Domain Controllers"

# Adicione o GMSA aos Administradores de Domínio
# Note que estamos adicionando a conta pelo seu verdadeiro SamAccountName 'svcadhealthcheck$'
Add-ADGroupMember -Identity "Domain Admins" -Members "$AccountName`$"

Instalando e Testando o gMSA

Agora que o gMSA está criado, o último passo é instalá-lo e testá-lo em todos os controladores de domínio. Uma maneira de fazer isso é usando o comando PowerShell Invoke-Command. Abaixo você pode ver um script PowerShell que instalará o gMSA em todos os DCs e garantirá que esteja funcionando corretamente.

# Isso será executado em todos os controladores de domínio
Invoke-Command -ComputerName (Get-ADDomainController -Filter *).Name -ScriptBlock {
    $Account = Get-ADServiceAccount -Filter { Name -eq 'svcadhealthcheck'}
    Install-ADServiceAccount $Account

    # Testa se o GMSA funciona no computador
    # Retorna $True se os testes estiverem 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"
    }

}

Dando permissão ao gMSA para ser executado como um trabalho em lote

Depois que o gMSA estiver instalado, você precisará dar permissão a ele para ser executado como um trabalho em lote nos DCs. A conta precisa desse direito, pois será executada autonomamente em segundo plano em uma tarefa agendada.

Você pode definir essa permissão por meio de uma GPO existente ou criando uma nova GPO e vinculando-a à OU de Controladores de Domínio. Se você ainda não tem uma GPO para usar, abaixo estão alguns passos que você pode seguir para criar uma.

  1. Inicie o Editor de Política de Grupo em um DC.
  2. Clique com o botão direito do mouse na OU de Controladores de Domínio e selecione Criar GPO neste domínio e vinculá-lo aqui.
  3. Dê a ele o nome de DC – Logon como lote ou outro nome de sua preferência
  4. Clique com o botão direito do mouse na GPO e clique em Editar.
  5. Vá para Configuração do Computador –> Configurações do Windows –> Configurações de Segurança –> Atribuição de Direitos de Usuário.
  6. Clique com o botão esquerdo do mouse em Logon como lote de tarefas e clique em Propriedades.
  7. Clique em Adicionar usuário ou Grupo.
  8. Clique em Tipos de objeto, selecione apenas Contas de Serviço e clique em OK.
  9. Procure a conta de serviço svcADHealthCheck criada anteriormente, selecione-a e clique em OK.

Agora você deve ver a gMSA na lista de objetos AD como mostrado abaixo.

gMSA given rights to logon as a batch job

Criando a Tarefa Agendada

Agora que você tem uma conta criada para executar as tarefas agendadas, você pode criar a própria tarefa agendada em um servidor associado ao domínio de sua escolha.

Você pode criar a tarefa agendada via GUI, mas isso requer muitos cliques! Em vez disso, recomendo criar com PowerShell. Por quê? Porque você pode simplesmente copiar o código abaixo e pronto.

Abaixo você encontrará dois scripts; ambos são semelhantes, mas um assume uma conta de usuário AD e o outro assume uma gMSA. Certifique-se de usar o script apropriado com base na conta que você está usando.

# Substitua pelo caminho para o seu script
$ScriptPath = "C:\Scripts\ADHealthCheck.ps1"
# Substitua pelo nome de usuário da conta que você criou para executar a tarefa
$UserName = "svdADHealthCheck"

# Substitua pela senha que você definiu para a conta acima
$Password = "JägareTvå!"
# Crie a ação que inicia o script
$Action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-ExecutionPolicy bypass -File '$ScriptPath'"
# Crie o gatilho que inicia a tarefa
$Trigger = New-ScheduledTaskTrigger -Once -At "12:00" -RepetitionInterval (New-TimeSpan -Hours 12)
# Crie configurações para a tarefa agendada
$Settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries -StartWhenAvailable -RunOnlyIfNetworkAvailable -DontStopOnIdleEnd
# Crie a tarefa agendada usando um splat para legibilidade
$Splat = @{
    User = "$env:USERDOMAIN\$UserName"
    Password = $Password
    TaskName = "ADHealthCheck"
    Action = $Action
    Trigger = $Trigger
    RunLevel = "Highest"
    Settings = $Settings
}
Register-ScheduledTask @Splat
# Substitua pelo caminho para o seu script
$ScriptPath = "C:\Scripts\ADHealthCheck.ps1"
# Substitua pelo nome de usuário da conta que você criou para executar a tarefa
$UserName = "svdADHealthCheck$"
# Crie a ação que inicia o script
$Action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-ExecutionPolicy bypass -File '$ScriptPath'"
# Crie o gatilho que inicia a tarefa
$Trigger = New-ScheduledTaskTrigger -Once -At "12:00" -RepetitionInterval (New-TimeSpan -Hours 12)
# Crie configurações para a tarefa agendada
$Settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries -StartWhenAvailable -RunOnlyIfNetworkAvailable -DontStopOnIdleEnd

# Crie o principal que define o GMSA
$Principal = New-ScheduledTaskPrincipal -UserID "$env:USERDOMAIN\$UserName" -LogonType Password -RunLevel Highest
# Crie a tarefa agendada usando um splat para legibilidade
$Splat = @{
    Principal = $Principal
    TaskName = "ADHealthCheck"
    Action = $Action
    Trigger = $Trigger
    RunLevel = "Highest"
    Settings = $Settings
}
Register-ScheduledTask @Splat

Você concluiu! Neste momento, a tarefa agendada será executada no intervalo fornecido em um dos scripts acima.

Resumo

Whew! Se você acompanhou tudo desde a Parte I, agora deve saber que a saúde do AD é um assunto profundo. Há tanto nesse tópico que nem mesmo dois posts extensos de blog poderiam cobrir completamente.

Mas, até agora, você deve ter conhecimento suficiente e um framework predefinido do PowerShell que pode ser adaptado para outros checks de saúde do Active Directory conforme surgem.

Leitura Adicional

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