Adam the Automator

BY admin

| Agosto 30, 2021

This is part II of a two-part series on Active Directory health checks. Embora não seja necessária a leitura, se você gostaria de aprender como o script PowerShell que você vai aprender sobre este artigo foi construído, você é encorajado a verificar a construção de uma ferramenta de verificação de saúde de Diretório Ativo : Parte I.

na Parte I, você aprendeu quantos testes múltiplos diferentes e por que eles são importantes. Vamos agora juntá-los todos e construir uma ferramenta. Nesta parte, você vai converter todos os controles de saúde do Diretório Ativo explicados na Parte I em um framework de testes. Você também vai aprender a produzir resultados de vários exames de saúde para ferramentas como o Pester e uma ferramenta de monitoramento chamada PRTG.

para acompanhar ou ver uma versão final da ferramenta que irá aprender neste artigo, faça o download do script ADHealthCheck-NoResult.ps1 do GitHub.

Índice

definir a saída

ter um tipo de objeto comum e uma maneira fácil de gerá-lo irá tornar muito mais fácil converter os resultados do teste 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 seguir aqui. O ponto principal é assegurar que todos os controlos sanitários devolvam o mesmo tipo de produção.

uma classe PowerShell é um esquema que define como um objeto PowerShell deve olhar e o que ele deve fazer. Cada linha que você vê abaixo representa uma propriedade que os objetos retornam terá. Podem ver a seguir, estou a planear em cada exame de saúde para devolver dez propriedades.

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

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

executando a ferramenta AD Health Check

primeiro, baixar e copiar o script AD health check para um controlador de domínio. Abre-o com o “PowerShell ISE” e executa-o. Esta parte da ferramenta não irá devolver nenhuma informação.

o script irá rodar e armazenar o resultado de cada verificação na variável $TestResults como múltiplos objectos . Você vai usar estes objetos mais tarde para gerar relatórios ou outputá-lo em várias ferramentas. Manter o exame de saúde resulta numa variável como esta permite-lhe adicionar mais resultados se optar por criar outro e usar o comando New-AdHcResult.

uma vez que o programa termine a execução, deverá agora ter um conjunto completo de objectos AD health check armazenados na variável $TestResults. Agora você pode executar $TestResults a partir do console e ver os resultados brutos.

mostrar o exame de saúde resulta em Ferramentas

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

nesta secção, irá aprender a criar um relatório HTML com uma ferramenta chamada extensão e a mostrar o relatório no PRTG.

criação de um ficheiro XML nUnit com Tester

primeiro terá de converter os objectos PowerShell num formato que as suas ferramentas possam compreender. A maioria das ferramentas entende XML ou, mais especificamente, nUnit XML. Este é um formato que você pode importar em várias ferramentas para exibir resultados.

uma vez que está a trabalhar com o PowerShell, irá usar o framework de testes de tester para ler o resultado do programa AD health check e para gerar um ficheiro nUnit XML

comece por descarregar a última versão do Tester. Você pode baixar o Pester executando Install-Module em uma consola PowerShell elevada. O comando abaixo forçará uma instalação da última versão do Pester. Uma vez que o certificado de editor com o qual o Pester está assinado vem com o Windows 10, vamos precisar usar o parâmetro SkipPublisherCheck para instalá-lo.

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

uma vez que Pester está disponível, você pode então executar o script e criar dinamicamente um conjunto de testes de Pester.

Nota: Você também pode criar testes de tester sem mesmo usar o script PowerShell que eu forneci.

o programa PowerShell abaixo irá usar o Pester para gerar um ficheiro XML nUnit a partir da saída da variável $TestResults definida no programa ADHealthCheck-NoResult.ps1.

Guarde este ficheiro como Tester.ps1 na mesma pasta que o programa AD health check.

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

finalmente, executar Invoke-Pester abaixo para invocar o testador.ficheiro ps1 e gravar 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 extensão

uma vez que você tem o arquivo NUnit XML, você pode agora usar este arquivo para passar para uma ferramenta que pode converter isso para HTML. Uma dessas ferramentas é chamada extensão. Extensão é uma ferramenta útil para criar relatórios HTML a partir de arquivos Nunit XML.

primeiro, baixar extensão para o mesmo diretório que o NunitReport.ficheiro xml criado anteriormente. Em seguida, execute os seguintes comandos em uma sessão PowerShell. Estes comandos irão criar o diretório para armazenar os arquivos HTML e, em seguida, executar extensão.fazer a conversão.

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

quando completo, você encontrará dois arquivos HTML no diretório de relatórios HTML. Estes arquivos se parecerão com as imagens abaixo que você os abre com um navegador web.

relatório em HTML para Incomodar saída de teste — relatório em HTML para O teste de saída

A ingestão de ANÚNCIO de Saúde, a Verificação de Resultados em PRTG

PRTG é uma popular ferramenta de monitoramento desenvolvido pelo Paessler que você pode usar para monitorar sua infra-estrutura e serviços. Nesta seção, você aprenderá como empurrar os resultados do exame de saúde para o PRTG uma vez que o script do exame de saúde tenha corrido.

empurrar os resultados para o PRTG requer mais trabalho em vez de ter a ferramenta puxar a informação, mas você acabará por ver que a configuração vale bem o tempo gasto.

pré-requisitos

PRTG instalado e configurado
todos os controladores de domínio criados no PRTG
o Send-AdhcResultToPrtg.ps1 PowerShell script baixado a partir do GitHub
a URL e a porta de y0ur PRTG sensor

Se você tem cada uma das prereqs feito, você pode, em seguida, siga abaixo o passo-a-passo sobre como eu recomendo para empurrar esses ANÚNCIO de saúde, a verificação de resultados para PRTG.

crie um dispositivo no PRTG chamado domínio ou qualquer nome que preferir.
crie um sensor avançado de pressão HTTP com uma IdentityToken de directório-teste de adesão. Note que este é o caso sensível!
para cada controlador de domínio no PRTG, crie um sensor avançado de pressão HTTP. Para cada Identitotoken, adicione cada sensor com-controlo de saúde como o dc01-controlo de saúde.
Add the contents of the Send-AdhcResultToPrtg. ps1 PowerShell script to the end of the ADHealthCheck-NoResult. ps1 PowerShell script we’ve covered.
mude a variável $PRTGUrl para a URL e porta do seu sensor PRTG.
Execute o script.

uma vez concluído, uma vez que o script AD de exame de saúde completa, ele deve agora empurrar o status para seus sensores PRTG como mostrado abaixo.

PRTG sensores mostrando ANÚNCIO de saúde

Programação do Active Directory de Saúde Verifique o Script

Monitoramento ANÚNCIO de saúde é um processo contínuo. Você deve estar executando testes o tempo todo, em vez de instâncias ad-hoc. Vamos agendar o programa de verificação de saúde do directório activo para correr a intervalos frequentes.

a rota mais fácil de automatizar essas verificações é adicionando o script ao escalonador de tarefas e deixando-o correr sob uma conta de usuário de AD ou uma conta de Serviço gerenciada por grupo.

usar uma conta de Serviço gerenciada por grupo (gMSA) é a forma mais segura de executar tarefas agendadas autonomamente, uma vez que apenas contas de computador especificadas que podem obter a senha a partir de AD. Mas algumas organizações podem não ter esse luxo.

criar uma conta de utilizador de AD

vamos primeiro quebrar o que é preciso para criar uma conta de utilizador de AD para executar a tarefa agendada.

se você vai estar executando uma tarefa agendada como uma conta de usuário, por todos os meios, não executá-la como sua própria conta! Criar sempre uma conta de utilizador separada para este fim.

para economizar tempo, você verá um script PowerShell abaixo. Este é um script de exemplo que você pode usar para criar uma conta de usuário de AD que é parte do grupo Admins domínio. Você pode então usar esta conta para executar a tarefa agendada com.

# 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

criar uma conta de Serviço gerenciada por grupos

usar um gMSA para executar o exame de saúde é um pouco mais complicado se você não está usando gMSA em seu ambiente já, mas é muito mais seguro.

criando uma chave raiz do KDS

para criar uma conta gMSA para executar o programa de verificação de saúde do AD, adicione primeiro uma chave raiz do KDS se ainda não tiver uma. Poderá verificar se tem uma chave raiz do KDS, executando o comando PowerShell Get-KDSRootKey num controlador de domínio.

se você não tem uma chave raiz do KDS, você cria uma executando Add-KDSRootKey -EffectiveImmediately sob uma conta de usuário parte do grupo AD do domínio administra em um 2012R2 ou controlador de domínio posterior.

a chave precisa replicar-se aos outros controladores de domínio para fazer todo o efeito. Mais informações sobre este processo podem ser encontradas na documentação da Microsoft.

criando o gMSA

uma vez criada a chave raiz do KDS, você está pronto para criar a conta gMSA com PowerShell. Abaixo você pode ver um script de exemplo a usar para criar a conta gMSA apenas permitido para autenticar a partir de um controlador de domínio no grupo Admins domínio.

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

instalar e testar o gMSA

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

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

dando a permissão do gMSA para executar como um trabalho em lote

uma vez que o gMSA está instalado, você agora vai precisar dar-lhe permissão para executar como um trabalho em lote no DCs. A conta precisa deste direito, uma vez que estará funcionando autonomamente em segundo plano em uma tarefa agendada.

pode definir esta permissão através de um GPO existente ou criando um novo GPO e ligando-o aos controladores de domínio OU. Se você ainda não tem um GPO para usar, abaixo estão alguns passos que você pode tomar para criar um.

lance o editor de Políticas de grupo em uma DC.
clique com o botão direito sobre os controladores de domínio OU e seleccione Criar GPO neste domínio e ligue-o aqui.
nomeie-o DC-Logon como lote ou outro nome que prefira
carregue com o botão direito no GPO e carregue em Editar.
Go to Computer Configuration- > Windows Settings –> Security Settings – > User Rights Assignment.
carregue com o botão esquerdo no botão direito como trabalho em lote e carregue em Propriedades.
Carregue em Adicionar utilizador ou grupo.
Carregue nos tipos de objectos, seleccione apenas as contas de Serviço e carregue em OK.
procure pela conta de serviço svcadhealth criada anteriormente, seleccione-a e carregue em OK.

deve agora ver o gMSA sob a lista de objectos AD, como mostrado abaixo.

gMSA dada direitos de logon como um trabalho em lotes

Criar a Tarefa Agendada

Agora que você tem uma conta criada para executar as tarefas agendadas, você pode agora criar a tarefa agendada se sobre um domínio de servidor de sua escolha.

pode criar a tarefa agendada através da interface gráfica,mas isso é carregar demasiado! Em vez disso, recomendo criá-lo com PowerShell. Por quê? Porque você pode simplesmente copiar o código que você vê abaixo e ser feito com ele.

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

# 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

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

Resumo

Whew! Se você seguiu todo o caminho desde a parte i, você já deve saber que a saúde publicitária é um assunto profundo. Há tanto para este tópico que nem dois posts longos poderia cobrir.

mas, por agora, você deve ter conhecimento suficiente e um framework PowerShell pré-construído que você pode plug em outros controles de saúde Diretório Ativo à medida que eles surgem.

Leitura Adicional

algumas coisas que você pode não saber sobre AD e recuperação de desastres
o que DCDIAG realmente … faz?