Verificación del estado de Active Directory con el Marco de PowerShell – techsyncer

Esta es la parte II de una serie de dos partes sobre las verificaciones de salud de Active Directory. Aunque no es lectura obligatoria, si deseas aprender cómo se construyó el script de PowerShell del que aprenderás en este artículo, te animamos a consultar Construyendo una Herramienta de Verificación de Salud de Active Directory [En Profundidad]: Parte I.

En la Parte I, aprendiste cuántas pruebas múltiples diferentes existen y por qué son importantes. Ahora vamos a reunirlas todas y construir una herramienta. En esta parte, convertirás todas las verificaciones de salud de Active Directory explicadas en la Parte I en un marco de pruebas. También aprenderás cómo enviar los resultados de varias verificaciones de salud de AD a herramientas como Pester y una herramienta de monitoreo llamada PRTG.

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

Definición de la Salida

Tener un tipo de objeto común y una manera fácil de generarlo facilitará mucho la conversión de los resultados de las pruebas a la herramienta de tu elección.

Para crear una salida uniforme para todas las herramientas potenciales, he elegido usar una clase de PowerShell. Aunque no es necesario, es el enfoque que he decidido tomar aquí. El punto principal es asegurar que todas las verificaciones de salud de AD devuelvan el mismo tipo de salida.

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 agilizar la creación de esta clase, usaré una función auxiliar llamada New-AdhcResult. Esta función crea la clase y todo lo que necesitarás para seguir adelante. Esta función producirá un objeto de tipo [AdhcResult] personalizado.

Ejecutando la Herramienta de Verificación de Salud de AD

Primero, descarga y copia el script de verificación de salud de AD en un controlador de dominio. Ábrelo con PowerShell ISE y ejecútalo. Esta parte de la herramienta no devolverá ninguna información.

El script se ejecutará y almacenará el resultado de cada verificación en la variable $TestResults como múltiples objetos [AdhcResult]. Más adelante, usarás estos objetos para generar informes o enviarlos a varias herramientas. Mantener los resultados de la verificación de salud en una variable como esta te permite agregar más resultados si decides crear otro y usar el comando New-AdHcResult.

Una vez que el script termine de ejecutarse, ahora deberías tener un conjunto completo de objetos de verificación de salud de AD almacenados en la variable $TestResults. Ahora puedes ejecutar $TestResults desde la consola y ver los resultados en bruto.

Mostrando los Resultados de la Verificación de Salud de AD en Herramientas

Dado que todas las verificaciones están en un tipo de objeto común, puedes inspeccionarlas mejor a través de algunas herramientas como Pester y PRTG.

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

Creando un archivo XML de nUnit con Pester

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

Dado que estás trabajando con PowerShell, usarás el marco de pruebas Pester para leer la salida del script de comprobación de salud de AD y generar un archivo XML de nUnit

Empieza descargando la última versión de Pester. Puedes 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 está firmado 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, puedes ejecutar el script y crear dinámicamente un conjunto de pruebas Pester.

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

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

Guarda este archivo como Pester.ps1 en la misma carpeta que el script de verificación de salud de AD.

# Punto de origen en el archivo 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
                }
            }
        }
    }
}

Finalmente, ejecuta Invoke-Pester a continuación para invocar el archivo Pester.ps1 y guardar 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 tengas el archivo XML de NUnit, ahora puedes usar este archivo para pasarlo a una herramienta que pueda convertirlo a HTML. Una de esas herramientas se llama extent. Extent es una herramienta útil para crear informes HTML a partir de archivos XML de Nunit.

Primero, descarga extent en el mismo directorio que el archivo NunitReport.xml creado anteriormente. Luego ejecuta 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.

# Crear directorio de informes
PS51> mkdir .\HTMLReports

# Crear el informe
PS51> .\extent.exe -i .\NunitReport.xml -o .\HTMLReports\

Una vez completado, encontrarás dos archivos HTML en el directorio HTMLReports. Estos archivos se verán como las capturas de pantalla a continuación cuando los abras con un navegador web.

Ingestión de resultados de verificación de salud de AD en PRTG

PRTG es una herramienta de monitoreo popular desarrollada por Paessler que puedes usar para monitorear tu infraestructura y servicios. En esta sección, aprenderás cómo enviar los resultados de la verificación de salud a PRTG una vez que se haya ejecutado el script de verificación de salud.

Enviar resultados a PRTG requiere más trabajo que simplemente hacer que la herramienta recopile información, pero eventualmente verás que la configuración vale la pena el tiempo invertido.

Prerrequisitos

Para configurar con éxito PRTG como una herramienta de monitoreo para el script de verificación de salud de AD construido en este artículo, asegúrate de tener:

PRTG instalado y configurado
Todos los controladores de dominio configurados en PRTG
El script de PowerShell Send-AdhcResultToPrtg.ps1 descargado desde GitHub
La URL y el puerto de tu sensor PRTG

Si tienes todos los prerrequisitos completados, entonces puedes seguir las siguientes instrucciones paso a paso sobre cómo recomiendo enviar estos resultados de verificación de salud de AD a PRTG.

Crea un dispositivo en PRTG llamado Dominio o cualquier otro nombre que prefieras.
Crea un sensor avanzado de empuje HTTP con un Token de Identidad de directory-adhealthcheck. ¡Ten en cuenta que distingue entre mayúsculas y minúsculas!
Para cada dispositivo de controlador de dominio en PRTG, crea un sensor avanzado de empuje HTTP. Para cada Token de Identidad, añade a cada sensor -adhealthcheck como por ejemplo dc01-adhealthcheck.
Agregue el contenido del script PowerShell Send-AdhcResultToPrtg.ps1 al final del script PowerShell ADHealthCheck-NoResult.ps1 que hemos cubierto.
Cambie la variable $PRTGUrl por la URL y el puerto de su sensor PRTG.
Ejecute el script.

Una vez completado, cuando el script de verificación de salud de AD se complete, ahora debería enviar el estado a sus sensores PRTG como se muestra a continuación.

Programando el Script de Verificación de Salud de Active Directory

Monitorear la salud de AD es un proceso continuo. Debería estar ejecutando pruebas todo el tiempo en lugar de instancias ad-hoc. Vamos a programar el script de verificación de salud de Active Directory para que se ejecute a intervalos frecuentes.

La forma más fácil de automatizar estas comprobaciones es agregando el script al programador de tareas y dejándolo ejecutar bajo una cuenta de usuario de AD o una Cuenta de Servicio Administrada por Grupo.

Usar una Cuenta de Servicio Administrada por Grupo (gMSA) es la forma más segura de ejecutar tareas programadas de manera 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.

Creando 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 vas a ejecutar una tarea programada como una cuenta de usuario, ¡por favor, no la ejecutes con tu propia cuenta! Siempre crea una cuenta de usuario separada para este propósito.

Para ahorrar tiempo, verás a continuación un script de PowerShell. Este es un ejemplo de script que puedes usar para crear una cuenta de usuario de Active Directory que forme parte del grupo Domain Admins. Luego puedes utilizar esta cuenta para ejecutar la tarea programada.

# Cambia esto por la OU de tus cuentas de servicio
$OU = "OU=Service Accounts,DC=contoso,DC=com"
# Cambia esto por la contraseña que quieres usar para la cuenta
$Password = "JägareTvå"
$SecureString = $Password | ConvertTo-SecureString -AsPlainText -Force
New-ADUser -Enabled $True -Path $OU -Name svcADHealthCheck -AccountPassword $SecureString
# Restringe la cuenta solo a Controladores de Dominio
$DomainControllers = (Get-ADDomainController -Filter *).Name

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

# Haciéndolo Administrador de Dominio (Lo siento)
Add-ADGroupMember -Identity "Domain Admins" -Members svcADHealthCheck

Creación de una cuenta de servicio gestionada por grupo

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

Creación de una Clave Raíz KDS

Para crear una cuenta gMSA para ejecutar el script de comprobación de salud de AD, primero agrega una clave raíz KDS si aún no tienes una. Puedes verificar si tienes una clave raíz KDS ejecutando el comando de PowerShell Get-KDSRootKey en un controlador de dominio.

Si no tienes una clave raíz de KDS, puedes crear una ejecutando Add-KDSRootKey -EffectiveImmediately bajo una cuenta de usuario que forme parte del grupo AD de Administradores del Dominio en un controlador de dominio de 2012R2 o posterior.

La clave necesita replicarse a los demás controladores de dominio para que tenga pleno efecto. Puedes encontrar más información sobre este proceso en la documentación de Microsoft.

Creando la gMSA

Una vez creada la clave raíz de KDS, estás listo para crear la cuenta gMSA con PowerShell. A continuación, puedes ver un ejemplo de script para crear la cuenta gMSA solo permitida para autenticarse desde un controlador de dominio en el grupo Administradores del Dominio.

# Cambia por tu dominio
$Domain = "contoso.com"

$AccountName = "svcadhealthcheck"

# Crea una GMSA llamada svcadhealthcheck (o en realidad svcadhealthcheck$) y permite que solo los Controladores de Dominio obtengan la contraseña
New-ADServiceAccount $AccountName -DNSHostName "$AccountName.$Domain" –PrincipalsAllowedToRetrieveManagedPassword "Domain Controllers"

# Agrega la GMSA a Administradores del Dominio
# Ten en cuenta que estamos agregando la cuenta por su verdadero SamAccountName 'svcadhealthcheck$'
Add-ADGroupMember -Identity "Domain Admins" -Members "$AccountName`$"

Instalación y prueba de la gMSA

Ahora que se ha creado el gMSA, el último paso es instalarlo y probarlo en todos los controladores de dominio. Una forma de hacer esto es utilizando el comando PowerShell Invoke-Command. A continuación, puedes ver un script de PowerShell que instalará el gMSA en todos los DCs y garantizará que funcione correctamente.

# Esto se ejecutará en todos los controladores de dominio
Invoke-Command -ComputerName (Get-ADDomainController -Filter *).Name -ScriptBlock {
    $Account = Get-ADServiceAccount -Filter { Name -eq 'svcadhealthcheck'}
    Install-ADServiceAccount $Account

    # Prueba que el GMSA funcione en el equipo
    # Devuelve $True si las pruebas son correctas
    $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 permiso al gMSA para ejecutarse como un trabajo por lotes

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

Puedes establecer este permiso a través de un GPO existente o creando un nuevo GPO y vinculándolo a la OU Domain Controllers. Si aún no tienes un GPO para usar, a continuación se muestran algunos pasos que puedes seguir para crear uno.

Inicia el Editor de Directiva de grupo en un DC.
Haz clic derecho en la OU Domain Controllers y selecciona Crear GPO en este dominio y vincularlo aquí.
Nómbralo DC – Logon as batch o con otro nombre que prefieras
Haz clic derecho en el GPO y selecciona Editar.
Ve a Configuración del equipo –> Configuración de Windows –> Configuración de seguridad –> Asignación de derechos de usuario.
Haz clic izquierdo en Iniciar sesión como trabajo por lotes y haz clic en Propiedades.
Haz clic en Agregar usuario o grupo.
Haz clic en Tipos de objetos, selecciona solo Cuentas de servicio y haz clic en Aceptar.
Busca la cuenta de servicio svcADHealthCheck creada anteriormente, selecciónala y haz clic en Aceptar.

Ahora deberías ver la gMSA en la lista de objetos de AD como se muestra a continuación.

gMSA given rights to logon as a batch job

Creando la Tarea Programada

Ahora que tienes una cuenta creada para ejecutar las tareas programadas, puedes crear la tarea programada en sí en un servidor unido al dominio de tu elección.

Puedes crear la tarea programada a través de la GUI, ¡pero eso es demasiado clics! En su lugar, recomiendo crearla con PowerShell. ¿Por qué? Porque simplemente puedes copiar el código que ves a continuación y ¡listo!

A continuación encontrarás 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 apropiado según la cuenta que estés utilizando.

# Reemplace con la ruta de su script
$ScriptPath = "C:\Scripts\ADHealthCheck.ps1"
# Reemplace con el nombre de usuario de la cuenta que creó para ejecutar la tarea
$UserName = "svdADHealthCheck"

# Reemplace con la contraseña que estableció para la cuenta anterior
$Password = "JägareTvå!"
# Cree la acción que inicia el script
$Action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-ExecutionPolicy bypass -File '$ScriptPath'"
# Cree el desencadenante que inicia la tarea
$Trigger = New-ScheduledTaskTrigger -Once -At "12:00" -RepetitionInterval (New-TimeSpan -Hours 12)
# Cree configuraciones para la tarea programada
$Settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries -StartWhenAvailable -RunOnlyIfNetworkAvailable -DontStopOnIdleEnd
# Cree la tarea programada usando un splat para mayor legibilidad
$Splat = @{
    User = "$env:USERDOMAIN\$UserName"
    Password = $Password
    TaskName = "ADHealthCheck"
    Action = $Action
    Trigger = $Trigger
    RunLevel = "Highest"
    Settings = $Settings
}
Register-ScheduledTask @Splat

# Reemplace con la ruta de su script
$ScriptPath = "C:\Scripts\ADHealthCheck.ps1"
# Reemplace con el nombre de usuario de la cuenta que creó para ejecutar la tarea
$UserName = "svdADHealthCheck$"
# Cree la acción que inicia el script
$Action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-ExecutionPolicy bypass -File '$ScriptPath'"
# Cree el desencadenante que inicia la tarea
$Trigger = New-ScheduledTaskTrigger -Once -At "12:00" -RepetitionInterval (New-TimeSpan -Hours 12)
# Cree configuraciones para la tarea programada
$Settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries -StartWhenAvailable -RunOnlyIfNetworkAvailable -DontStopOnIdleEnd

# Cree el principal que define el GMSA
$Principal = New-ScheduledTaskPrincipal -UserID "$env:USERDOMAIN\$UserName" -LogonType Password -RunLevel Highest
# Cree la tarea programada usando un splat para mayor legibilidad
$Splat = @{
    Principal = $Principal
    TaskName = "ADHealthCheck"
    Action = $Action
    Trigger = $Trigger
    RunLevel = "Highest"
    Settings = $Settings
}
Register-ScheduledTask @Splat

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

Resumen

¡Uf! Si has seguido desde la Parte I, ahora deberías saber que la salud de AD es un tema profundo. Hay tanto en este tema que ni siquiera dos largas publicaciones de blog podrían cubrir.

Pero, para este punto, deberías tener suficiente conocimiento y un marco preconstruido de PowerShell que puedas integrar otros controles de salud de Active Directory según surjan.