En muchos entornos corporativos se exige que la automatización no se convierta en un “usuario dios” dentro del dominio. Esta guía muestra cómo otorgar a la cuenta de servicio que emplea Ansible exactamente los privilegios que necesita para instalar software, aplicar actualizaciones de Windows y reiniciar DC y Exchange, pero sin convertirla en administradora del dominio completo.
Contexto y objetivos
El reto consiste en equilibrar agilidad y seguridad cuando:
- Ansible orquesta tareas críticas sobre Windows Server.
- Se debe respetar el principio de menor privilegio.
- Los equipos incluyen Controladores de Dominio (DC) y servidores Exchange.
El objetivo final es una cuenta que pueda desplegar, parchear y reiniciar, pero que no tenga poder para crear usuarios, replicar atributos sensibles de Active Directory o leer buzones.
Principio de menor privilegio con Ansible
Al proteger una cuenta de servicio de Ansible debes pensar en tres planos:
- Superficie de tareas: exactamente qué cmdlets, binarios o API va a invocar.
- Ubicación: sobre qué equipos u OU se aplicarán los privilegios.
- Duración: que los derechos sean permanentes solo si es imprescindible; de lo contrario, usa elevación temporal.
Diseño de la cuenta de servicio
Buenas prácticas:
- Tipo de cuenta: gMSA (Group Managed Service Account). El KDS rota la clave cada 30 días sin intervención humana.
- Nombre descriptivo:
gMSAansibleops. Evita “svc” genéricos. - Inicio de sesión: bloquea el logon interactivo (
Deny log on locally). Solo debe autenticarse por WinRM. - MFA o restricción por estaciones: si tu solución MFA tolera cuentas de servicio, aplícala; si no, restringe
Log On Toa los nodos de control de Ansible.
Tabla resumen de la solución
| Fase | Acción | Detalles clave |
|---|---|---|
| Definir el alcance de permisos | Instalación/ejecución de binarios, gestión de Windows Update y reinicio remoto. | Un documento de alcance agiliza auditorías y pruebas. |
| Crear/seleccionar la cuenta de servicio | gMSA dedicada, contraseña gestionada, sin logon interactivo. | Un gMSA elimina la rotación manual de claves. |
| Delegar en DC | GPO + derechos SeShutdownPrivilege, SeRemoteShutdownPrivilege, membresía Remote Management Users o JEA. | No agregues al grupo Administrators; vincula la GPO solo a la OU Domain Controllers. |
| Delegar en Exchange | RBAC personalizado, permisos sobre carpetas de instalación y WinRM idéntico a DC. | Evita Organization Management completo. |
| Ajustes avanzados | Delegación restringida Kerberos, atributos TrustedForDelegation. | Solo si la arquitectura salta entre hosts. |
| Pruebas | Entorno de ensayo, check mode de Ansible. | Verifica que no modifica objetos fuera de alcance. |
| Auditoría y monitoreo | Advanced Security Audit, revisión de SIEM. | Alertas ante escaladas. |
| Documentación y mantenimiento | Registro de cambios y revisiones semestrales. | Facilita auditorías y traspaso de personal. |
Delegación en Controladores de Dominio
GPO dedicada
- Crea una GPO llamada GPOAnsibleDC y víncula solo a la OU Domain Controllers.
- En la pestaña Delegation añade la cuenta
gMSAansibleops$con permiso Edit settings.
User Rights Assignment
Dentro de la misma GPO, modifica Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → User Rights Assignment:
- Shut down the system (
SeShutdownPrivilege). - Force shutdown from a remote system (
SeRemoteShutdownPrivilege). - Log on as a service, en caso de ejecutar tareas como servicio.
WinRM y PowerShell Remoting
Opciones:
- Añade la cuenta al grupo local
Remote Management Userspor GPO de Preferencias. - Configura Just Enough Administration (JEA) con un endpoint que solo exponga los cmdlets que Ansible invoca (por ejemplo
Restart-Computer,Get-HotFix,Start-Process).
# En un DC, como administrador del dominio
Install-Module -Name JEA
New-PSRoleCapabilityFile -Path "C:\Program Files\WindowsPowerShell\Modules\JEA\RoleCapabilities\AnsibleOps.psrc" -VisibleCmdlets Restart-Computer, Get-HotFix, Start-Process
Register-PSSessionConfiguration -Name AnsibleOps -RunAsVirtualAccount -RoleDefinitions @{ 'contoso\gMSAansibleops$' = @{ RoleCapabilities = 'AnsibleOps' } }
Delegación en servidores Exchange
RBAC granular
Crea un grupo de roles personalizado:
# Con permisos de Org Management
New-RoleGroup -Name "AnsibleOps-Exchange" -Roles "Server Management","Mailbox Import Export","View-Only Configuration"
Add-RoleGroupMember -Identity "AnsibleOps-Exchange" -Member "CONTOSO\gMSAansibleops$"
Permisos de sistema de archivos
- Concede Modify sobre
C:\InstallTempy la ruta de logs que use tu playbook. - Mantén NTFS y Audit ACE para rastrear uso no autorizado.
WinRM idéntico al paso de DC
Reutiliza el endpoint JEA o, si lo prefieres, limita el puerto 5985/5986 a la VLAN del controlador de Ansible mediante firewall.
Ejemplo de implementación paso a paso
El siguiente flujo sirve como “runbook” reproducible:
- Solicitar la gMSA (incluye justificación de negocio).
# Ejecutar en un DC Add-KdsRootKey -EffectiveImmediately $true # Solo la primera vez New-ADServiceAccount -Name gMSAansibleops -DNSHostName gMSAansibleops.contoso.com -PrincipalsAllowedToRetrieveManagedPassword "CN=Ansible Controllers,CN=Computers,DC=contoso,DC=com" - Instalar la gMSA en cada nodo de control de Ansible.
Install-ADServiceAccount -Identity gMSAansibleops - Crear la GPO y vincularla solo a Domain Controllers.
- Añadir el gMSA al grupo RBAC en Exchange.
- Registrar el endpoint JEA con los cmdlets mínimos.
- Configurar la conexión en Ansible (inventory):
[windows] dc01.contoso.com exch01.contoso.com \[windows\:vars] ansible\user=CONTOSO\gMSA\ansible\_ops\$ ansible\_password="" ansible\_port=5986 ansible\_connection=winrm ansible\winrm\transport=kerberos ansible\winrm\server\cert\validation=ignore ansible\become\method=runas ansible\become\user="NT AUTHORITY\SYSTEM" - Ejecutar playbook en check mode y revisar resultados.
- Promover a producción solo tras superar validaciones.
Pruebas y validación
Incluye siempre un entorno que refleje la topología real pero con datos sintéticos:
- Lanza tareas de instalación (win_package) y confirma que el software aparece en Apps & Features.
- Aplica
win_updatesapuntando a tu WSUS/Patch API y verifica códigos de reinicio. - Reinicia un DC (
win_reboot); confirma replicación y tiempos de arranque. - Ejecuta pruebas negativas: intento de
New-ADUserdebe fallar con Access Denied.
Auditoría y monitoreo continuo
Políticas de auditoría
Activa estas subcategorías en Advanced Security Audit:
- DS Access → Directory Service Changes.
- Object Access → File Share, Other Object Access.
- Privilege Use → Sensitive Privilege Use.
Reenvía eventos a tu SIEM y genera alertas automáticas si la cuenta intenta escalar privilegios o acceder fuera de los OU esperados.
Integración con Ansible Tower/AWX
Habilita Job Events y Activity Stream para correlacionar cada ejecución con su auditoría en el DC o Exchange. Mantén los tokens de Tower cifrados con Fernet y rota la SECRET_KEY.
Mantenimiento y revisión periódica
- Revisión semestral de permisos comparando desired state (repositorio IaC) frente a ACL reales con
Compare-Object. - Rotación de gMSA gestionada automáticamente; revisa que los controladores de dominio no estén desincronizados más de 10 horas (requisito para la rotación).
- Documentación viva: usa Markdown en tu repositorio Git y requiere pull requests para cambios.
Conclusión
Al delegar con precisión quirúrgica, la cuenta de Ansible mantiene la automatización de despliegues, parches y reinicios, sin exponer el dominio a un compromiso total. Adoptar gMSA, JEA y RBAC reduce la superficie de ataque, simplifica la gestión de credenciales y cumple los requisitos de auditoría. Una estrategia de menor privilegio no solo protege hoy, sino que crea la base para escalar la automatización con confianza mañana.