Adam the Automator

Esta es la parte II de una serie de dos partes sobre comprobaciones de estado de Active Directory. Aunque no es una lectura obligatoria, si desea saber cómo se creó el script de PowerShell del que aprenderá en este artículo, le recomendamos que consulte la herramienta de creación de una comprobación de estado de Active Directory : Parte I.

En la Parte I, aprendió cuántas pruebas diferentes y por qué son importantes. Ahora vamos a juntarlos todos y construir una herramienta. En esta parte, convertirá todas las comprobaciones de mantenimiento de Active Directory que se explican en la parte I en un marco de prueba. También aprenderá a generar resultados de varias comprobaciones del estado de los anuncios en herramientas como Pester y una herramienta de supervisión llamada PRTG.

Para seguir o ver una versión terminada de la herramienta de la que aprenderás en este artículo, descarga el script ADHealthCheck-NoResult.ps1 de GitHub.

Definir Salida

Tener un tipo de objeto común y una forma fácil de generarlo hará que sea mucho más fácil convertir los resultados de las pruebas a la herramienta de su elección.

Para crear una salida uniforme para todas las herramientas potenciales, he elegido usar una clase PowerShell. Aunque no es obligatorio, es el enfoque que he optado por tomar aquí. El punto principal es garantizar que todas las comprobaciones de mantenimiento de anuncios devuelvan el mismo tipo de salida.

Una clase de PowerShell es un esquema que define cómo debe verse un objeto de PowerShell y qué debe hacer. Cada línea que ve a continuación representa una propiedad que tendrán los objetos devueltos. Puedes ver a continuación que planeo devolver diez propiedades en cada revisión de estado de ANUNCIO.

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

Para acelerar esta creación de clases, usaré una función auxiliar llamada New-AdhcResult. Esta función crea la clase y todo lo que necesita para seguir. Esta función generará un objeto de tipo personalizado .

Ejecutar la herramienta de comprobación de estado de anuncios

Primero, descargue y copie el script de comprobación de estado de anuncios en un controlador de dominio. Ábralo con ISE de PowerShell y ejecútelo. Esta parte de la herramienta no devolverá ninguna información.

Este script se ejecutará y almacenará el resultado de cada comprobación en la variable $TestResults como múltiples objetos . Utilizará estos objetos más adelante para generar informes o enviarlos a varias herramientas. Mantener los resultados de comprobación de estado en una variable como esta le permite agregar más resultados si decide crear otro y usar el comando New-AdHcResult.

Una vez que el script termine de ejecutarse, ahora debería tener un conjunto completo de objetos de comprobación de estado de ANUNCIOS almacenados en la variable $TestResults. Ahora puede ejecutar $TestResults desde la consola y ver los resultados sin procesar.

Mostrar los resultados de la comprobación de estado de anuncios en Herramientas

Dado que todas las comprobaciones se encuentran en un tipo de objeto común, puede inspeccionarlas mejor a través de un par de herramientas como Pester y PRTG.

En esta sección, aprenderá a crear un informe HTML con una herramienta llamada extent y a mostrar el informe en PRTG.

Crear un archivo XML NUnit con Pester

Primero debe convertir los objetos de PowerShell en un formato que las herramientas puedan entender. La mayoría de las herramientas entienden XML o, más específicamente, NUnit XML. Este es un formato que puede importar a varias herramientas para mostrar los resultados.

Dado que está trabajando con PowerShell, utilizará el marco de pruebas de Pester para leer el resultado del script de comprobación de estado de anuncios y generar un archivo XML NUnit

Comience descargando la última versión de Pester. Puede descargar Pester ejecutando Install-Module en una consola de PowerShell elevada. El siguiente comando forzará la instalación de la última versión de Pester. Dado que el certificado de editor con el que se firma Pester viene con Windows 10, necesitaremos usar el parámetro SkipPublisherCheck para instalarlo.

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

Una vez que Pester esté disponible, puede ejecutar el script y crear dinámicamente un conjunto de pruebas de Pester.

Nota: También puede crear pruebas de Pester usted mismo sin siquiera usar el script de PowerShell que he proporcionado.

El siguiente script de PowerShell utilizará Pester para generar un archivo XML NUnit a partir de la salida de la variable $TestResults definida en el script ADHealthCheck-NoResult.ps1.

Guarde este archivo como Pester. ps1 en la misma carpeta que el script de comprobación de estado del anuncio.

# 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, ejecute Invoke-Pester a continuación para invocar el Pester.archivo ps1 y guarde los resultados en formato NUnitXml.

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

Creación de un informe HTML con la Herramienta Extent

Una vez que tenga el archivo XML NUnit, ahora puede usar este archivo para pasarlo a una herramienta que pueda convertirlo en HTML. Una de esas herramientas se llama extensión. Extent es una herramienta útil para crear informes HTML a partir de archivos XML Nunit.

Primero, descargue extent en el mismo directorio que NunitReport.archivo xml creado anteriormente. A continuación, ejecute los siguientes comandos en una sesión de PowerShell. Estos comandos crearán el directorio para almacenar los archivos HTML y luego ejecutarán extent.exe para hacer la conversión.

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

Cuando se complete, encontrará dos archivos HTML en el directorio HTMLReports. Estos archivos se verán como las capturas de pantalla a continuación que se abren con un navegador web.

La incorporación de resultados de comprobación de estado de anuncios en PRTG

PRTG es una herramienta de monitoreo popular desarrollada por Paessler que puede usar para monitorear su infraestructura y servicios. En esta sección, aprenderá a enviar los resultados de la comprobación de estado a PRTG una vez que se haya ejecutado el script de comprobación de estado.

Enviar resultados a PRTG requiere más trabajo en lugar de tener la información de extracción de la herramienta, pero eventualmente verá que la configuración vale la pena el tiempo invertido.

Requisitos previos

Para configurar PRTG correctamente como herramienta de supervisión para el script de comprobación de estado de anuncios integrado en este artículo, asegúrese de tener:

• PRTG instalado y configurado
• Todos los controladores de dominio configurados en PRTG
• El Send-AdhcResultToPrtg.script de ps1 PowerShell descargado de GitHub
• la URL y el puerto del sensor PRTG de y0ur

Si ha realizado cada uno de los prerrequisitos, puede seguir las instrucciones paso a paso a continuación sobre cómo recomiendo enviar estos resultados de comprobación de estado de anuncios a PRTG.

1. Cree un dispositivo en PRTG llamado Dominio o el nombre que prefiera.
2. Cree un sensor push HTTP avanzado con un IdentityToken de comprobación de adhesión de directorios. Tenga en cuenta que esto distingue entre mayúsculas y minúsculas.
3. Para cada dispositivo controlador de dominio en PRTG, cree un sensor push HTTP avanzado. Para cada IdentityToken, agregue cada sensor con-adhealthcheck, como dc01-adhealthcheck.
4. Agregue el contenido del script de PowerShell Send-AdhcResultToPrtg.ps1 al final del script de PowerShell ADHealthCheck-NoResult.ps1 que hemos cubierto.
5. Cambie la variable $PRTGUrl por la URL y el puerto de su sensor PRTG.
6. Ejecuta el script.

Una vez completado, una vez que se complete el script de comprobación de estado del anuncio, ahora debería enviar el estado a sus sensores PRTG como se muestra a continuación.

Programar el script de comprobación de estado de Active Directory

Supervisar el estado de los anuncios es un proceso continuo. Debería estar ejecutando pruebas todo el tiempo en lugar de instancias ad hoc. Programemos el script de comprobación de estado de Active Directory para que se ejecute a intervalos frecuentes.

La forma más fácil de automatizar estas comprobaciones es agregar el script al programador de tareas y permitir que se ejecute en una cuenta de usuario de AD o en una Cuenta de Servicio Administrado por Grupo.

El uso de una Cuenta de Servicio Administrado de Grupo (gMSA) es la forma más segura de ejecutar tareas programadas de forma autónoma, ya que solo las cuentas de equipo especificadas pueden obtener la contraseña de AD. Pero algunas organizaciones pueden no tener este lujo.

Creación de una cuenta de usuario de AD

Primero desglosemos lo que se necesita para configurar una cuenta de usuario de AD para ejecutar la tarea programada.

Si va a ejecutar una tarea programada como cuenta de usuario, por supuesto, no la ejecute como su propia cuenta. Cree siempre una cuenta de usuario separada para este propósito.

Para ahorrar tiempo, verá un script de PowerShell a continuación. Este es un script de ejemplo que puede usar para crear una cuenta de usuario de AD que forme parte del grupo Administradores de dominio. A continuación, puede usar esta cuenta para ejecutar la tarea programada.

# 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

Crear una Cuenta de Servicio Administrado por Grupo

Usar una gMSA para ejecutar la comprobación de estado es un poco más complicado si no está utilizando gMSA en su entorno ya, pero es mucho más seguro.

Creación de una clave raíz de KDS

Para crear una cuenta gMSA para ejecutar el script de comprobación de estado de ANUNCIOS, agregue primero una clave raíz de KDS si aún no tiene una. Puede comprobar si tiene una clave raíz KDS ejecutando el comando PowerShell Get-KDSRootKey en un controlador de dominio.

Si no tiene una clave raíz de KDS, cree una ejecutando Add-KDSRootKey -EffectiveImmediately en una cuenta de usuario que forme parte del grupo de anuncios Administradores de dominio en un controlador de dominio 2012R2 o posterior.

La clave necesita replicarse a los otros controladores de dominio para tener pleno efecto. Puede encontrar más información sobre este proceso en la documentación de Microsoft.

Creación de gMSA

Una vez creada la clave raíz de KDS, estará listo para crear la cuenta de gMSA con PowerShell. A continuación, puede ver un script de ejemplo que se puede usar para crear la cuenta gMSA que solo se puede autenticar desde un controlador de dominio en el grupo Administradores de dominio.

# 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 y probar gMSA

Ahora que se crea gMSA, el último paso es instalarlo y probarlo en todos los controladores de dominio. Una forma de hacerlo es mediante el comando Invoke-Command PowerShell. A continuación, puede ver un script de PowerShell que instalará gMSA en todos los DCs y se asegurará de que funcione correctamente.

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

Dar permiso a gMSA para ejecutarse como un trabajo por lotes

Una vez que gMSA esté instalado, ahora deberá darle permiso para ejecutarse como un trabajo por lotes en el DCs. La cuenta necesita este derecho, ya que se ejecutará de forma autónoma en segundo plano en una tarea programada.

Puede establecer este permiso a través de un GPO existente o creando un nuevo GPO y vinculándolo a la unidad organizativa de controladores de dominio. Si aún no tiene un GPO para usar, a continuación se muestran algunos pasos que puede seguir para crear uno.

1. Inicie el Editor de directivas de grupo en un DC.
2. Haga clic con el botón derecho en la unidad organizativa de Controladores de dominio y seleccione Crear GPO en este dominio y vincularlo aquí.
3. Llámelo DC-Logon como lote u otro nombre que prefiera
4. Haga clic con el botón derecho en el GPO y haga clic en Editar.
5. Vaya a Configuración del equipo – > Configuración de Windows – > Configuración de seguridad – > Asignación de derechos de usuario.
6. Haga clic con el botón izquierdo del ratón en Iniciar sesión como trabajo por lotes y haga clic en Propiedades.
7. Haga clic en Agregar usuario o Grupo.
8. Haga clic en Tipos de objetos, seleccione solo Cuentas de servicio y haga clic en Aceptar.
9. Busque la cuenta de servicio svcADHealthCheck creada anteriormente, selecciónela y haga clic en Aceptar.

Ahora debería ver el gMSA debajo de la lista de objetos de anuncio como se muestra a continuación.

Creación de la Tarea programada

Ahora que tiene una cuenta creada para ejecutar las tareas programadas, ahora puede crear la tarea programada en un servidor unido al dominio de su elección.

Puede crear la tarea programada a través de la interfaz gráfica de usuario, ¡pero eso es hacer demasiado clic! En su lugar, recomiendo crearlo con PowerShell. ¿Por qué? Porque simplemente puede copiar el código que ve a continuación y terminar con él.

A continuación encontrará dos scripts; ambos scripts son similares, pero uno asume una cuenta de usuario de AD y el otro asume una gMSA. Asegúrate de usar el script adecuado en función de la cuenta que estés 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

estás hecho! En este momento, la tarea programada se ejecutará en el intervalo proporcionado en uno de los scripts anteriores.

Resumen

¡Uf! Si ha seguido todo el camino desde la Parte I, ya debe saber que la salud del anuncio es un tema profundo. Hay tanto en este tema que ni siquiera dos publicaciones de blog largas podrían cubrir.

Pero, a estas alturas, ya debería tener suficientes conocimientos y un marco de trabajo de PowerShell predefinido para poder conectar otras comprobaciones de estado de Active Directory a medida que surjan.

Lectura adicional

• Algunas cosas que tal vez no sepa sobre AD y Recuperación ante desastres
• ¿Qué hace DCDIAG en realidad do?