Active Directory : uso de un gMSA en una tarea programada

I. Introducción

En este tutorial, aprenderemos cómo crear una cuenta gMSA y utilizarla dentro de una tarea programada en Windows Server para ejecutar un script PowerShell (o cualquier otra cosa) de forma segura.

Ejecutar un script de PowerShell como parte de una tarea programada es una práctica muy habitual, incluso cuando se utiliza una cuenta con privilegios elevados en el dominio de Active Directory, para poder realizar las tareas adecuadas. Cuando configures la tarea programada, tendrás que asociar una cuenta de usuario que será utilizada por Windows para ejecutar la tarea. Para esta cuenta, tienes varias opciones, incluyendo :

• Asociar la cuenta de administrador del dominio (o equivalente), lo que es realmente malo;
• Asociar una cuenta de usuario con una convención de nomenclatura específica para que parezca una cuenta de servicio, por ejemplo "CDS-Srv-01", tampoco es lo ideal, ya que la contraseña de esta cuenta nunca se cambiará.
• Asociar una gMSA, es decir, una cuenta de servicio real almacenada en el Directorio Activo, con una contraseña que se renueva automáticamente a intervalos regulares (sin ninguna configuración por tu parte): ¡eso sí que es bueno!

Por supuesto, en este tutorial voy a presentarte la última opción: usar una cuenta gMSA para ejecutar una tarea programada en Windows. Si eres nuevo en el concepto de gMSA, te recomiendo que leas el siguiente artículo, publicado hace algún tiempo. Recuerda que las cuentas gMSA están disponibles desde Windows Server 2012.

II. Creación de una cuenta gMSA

Para crear una cuenta gMSA en nuestro Directorio Activo, necesitamos generar una clave raíz KDS: este es un prerrequisito. Sin detenerme en el tema, como ya he hecho anteriormente, aquí está el comando a ejecutar para crear esta famosa clave KDS (el comando Get-KdsRootKey le permitirá ver si ya tiene uno) en un entorno de producción(activo dentro de 10h, tiempo suficiente para permitir que la clave se replique en todos los DCs):

Add-KdsRootKey -EffectiveImmediately

Si quieres poder utilizar la clave KDS de inmediato sin tener que esperar 10 horas, puedes hacer trampa utilizando este comando:

Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))

El cmdlet New-ADServiceAccount nos permitirá crear una gMSA llamada "gMSA-SRV-APPS" que el servidor "SRV-APPS" podrá utilizar. La contraseña de esta cuenta gMSA se regenerará automáticamente cada 30 días. Aquí está el comando correspondiente:

New-ADServiceAccount -Name "gMSA-SRV-APPS" `
 -Description "gMSA pour tâches planifiées SRV-APPS" `
 -DNSHostName "gmsa-srv-apps.it-connect.local" `
 -ManagedPasswordIntervalInDays 30 `
 -PrincipalsAllowedToRetrieveManagedPassword "SRV-APPS$" `
 -Enabled $True

• Microsoft Docs - New-ADServiceAccount

La cuenta gMSA llamada "gMSA-SRV-APPS" está creada en mi Directorio Activo. Aún nos quedan dos cosas por hacer:

• Asociarlo con el servidor SRV-APPS en el Directorio Activo.

Add-ADComputerServiceAccount -Identity "SRV-APPS" -ServiceAccount "gMSA-SRV-APPS

• Añádalo al grupo "Administradores de dominio", ya que debe poder realizar tareas que requieran privilegios elevados.

Add-ADGroupMember -Identity "Domain Admins" -Members "gMSA-SRV-APPS$"

Por supuesto, el grupo "Domain Admins" puede añadirse a través de la consola gráfica de gestión de Active Directory, como cualquier otro objeto. De hecho, puedes comprobar que el gMSA está en el directorio :

Cambiemos al servidor SRV-APPS y utilicémoslo en una tarea programada.

III. Añadir gMSA al servidor

El gMSA debe estar "instalado" en el servidor, para utilizar el término del comando "Install-ADServiceAccount" que vamos a utilizar. Para usar este cmdlet, necesitas el módulo PowerShell Active Directory en el host local (Add-WindowsFeature RSAT-AD-PowerShell). A continuación, instálalo, llamándolo por su nombre:

Install-ADServiceAccount "gMSA-SRV-APPS"

Sólo queda crear la tarea programada y utilizar gMSA.

IV. Creación de una tarea programada con gMSA

Para crear la tarea programada, verás que es, salvo un detalle, un procedimiento clásico para crear una tarea programada en una máquina Windows. Abre la consola "Administración de equipos" y, en el menú de la izquierda, "Programador de tareas". Haga clic con el botón derecho y seleccione "Crear nueva tarea". Podríamos crear la tarea programada utilizando PowerShell, pero no es la forma más intuitiva.

Se iniciará el asistente y podremos configurar la tarea programada. Por mi parte, llamo a la tarea "PowerShell Script - Copiar un archivo a todos los ordenadores", ¡pero no te importará! 🙂

Esta tarea programada ejecutará el script "C:\Scripting\Copier-Fichier-PC.ps1", que tiene un objetivo muy simple: copiar un fichero a cada máquina AD contenida bajo la OU "PC". Aquí está el código, para su información:

$PCList = (Get-ADComputer -Filter * -SearchBase "OU=PC,DC=it-connect,DC=local").name

Foreach($PC in $PCList){
 Copy-Item -Path "C:PartageIT-Connect.txt" -Destination "\$PCPartage"
}

Lo importante son las opciones de seguridad. Haga clic en el botón "Usuario o grupo" para seleccionar gMSA como la cuenta utilizada por la tarea programada. Se abrirá una ventana... Haga clic en "Ubicaciones" y seleccione "Todo el directorio" (no su dominio) luego "Tipos de objetos" para seleccionar "Cuentas de servicio".

Una vez hecho esto, introduzca el nombre de su gMSA (o el principio de su nombre) y haga clic en "Comprobar nombres". La gMSA ya debería estar localizada: sólo queda hacer clic en "Aceptar".

Ya está, ¡la tarea programada se ejecutará con nuestra cuenta gMSA! 🙂

En la pestaña "General", marque "Ejecutar aunque el usuario no esté conectado" y "Configurar para:", y elija la versión de Windows más alta de la lista.

Por lo demás, tenemos que definir un activador y, a continuación, una acción. Para la acción, utilizaremos nuestro script PowerShell: haga clic en la pestaña "Acciones" y, a continuación, en "Nuevo". Especifique :

• Programa/script: powershell.exe
• Añadir argumentos: Archivo "<ruta al script>" (para mí: -File "C:\Scripting\Copier-Fichier-PC.ps1")

Lo que da:

Todo lo que tiene que hacer es confirmar, y la tarea programada estará lista. Por último, le dejo que ajuste los demás parámetros para adaptarlos a sus necesidades, si lo desea.

V. Permitir que gMSA se conecte como una tarea

Para que la cuenta gMSA pueda ejecutar el script a través de la tarea programada, debe estar autorizada para iniciar sesión como tarea. De lo contrario, el script no podrá ejecutarse en principio (pero me he encontrado casos en los que funciona sin este parámetro). Para ello, es necesario crear una GPO y aplicarla al servidor o servidores que vayan a utilizar el gMSA, o modificar la política local (gpedit.msc).

Si se utiliza un GPO, que será el caso en producción, este parámetro debe modificarse:

Configuración del ordenador > Estrategias > Configuración de Windows > Configuración de seguridad > Asignación de derechos de usuario > Inicio de sesión como tarea

Este parámetro debe ser definido y el gMSA seleccionado, de la misma manera que para la selección dentro de la tarea programada.

Gracias a este cambio adicional, el script PowerShell se ejecutará como una tarea programada sin ninguna dificultad. 🙂

Le recomiendo encarecidamente que ejecute sus tareas programadas (y otros servicios) con cuentas gMSA para reforzar la seguridad de su infraestructura basada en Active Directory.

Florian Burnel Co-founder of IT-Connect

Systems and network engineer, co-founder of IT-Connect and Microsoft MVP "Cloud and Datacenter Management". I'd like to share my experience and discoveries through my articles. I'm a generalist with a particular interest in Microsoft solutions and scripting. Enjoy your reading.

See Full Bio