Cuenta con privilegios para instalar software sin administrar usuarios en Active Directory

En entornos corporativos es frecuente que los técnicos de soporte requieran instalar o desinstalar aplicaciones en servidores y equipos cliente, pero sin que ello les confiera facultades para crear, modificar o eliminar cuentas en Active Directory (AD). Este artículo describe paso a paso cómo otorgar privilegios de instalación limitados, manteniendo la seguridad y el principio de privilegio mínimo.

Índice

Contexto y objetivos

El reto consiste en balancear dos necesidades aparentemente contrapuestas:

Autonomía operativa: el personal de soporte debe poder desplegar, actualizar y retirar software con rapidez para no afectar la productividad.
Separación de funciones: las tareas de administración de identidades y los cambios de configuración de dominio deben quedar restringidos a un grupo reducido de administradores de AD.

Para lograrlo crearemos una cuenta (o, mejor, un grupo) con permisos precisos sobre los hosts destino, sin incluirla en los grupos integrados que otorgan privilegios extensivos sobre el dominio.

Principio de privilegio mínimo

El principio de privilegio mínimo dicta que cada identidad — usuario, servicio o proceso — disponga exclusivamente de los derechos indispensables para cumplir su función. Aplicado a nuestro caso, la cuenta debe:

Instalar, modificar o eliminar software en equipos selectos.
No poder leer ni escribir en contenedores críticos de AD (Usuarios, Equipos, Controladores de dominio, etc.).
No alterar la configuración de seguridad de nivel dominio o bosque.

Con estos lineamientos definiremos una estrategia de delegación compatible con auditoría, reversibilidad y escalabilidad.

Diseño de la solución

La arquitectura propuesta se basa en cuatro pilares:

Cuenta dedicada: se crea un usuario de AD exclusivo para tareas de instalación, desligado de credenciales personales.
Grupo de seguridad intermedio: dicha cuenta se integra en un grupo (por ejemplo, SW‑Installers), que será el objeto al que se asignen derechos; así evitamos dependencias directas y facilitamos futuras rotaciones de personal.
Delegación granular en los equipos destino mediante GPO, Restricted Groups o Local Group Policy (LGPO), limitando los privilegios al ámbito estrictamente necesario.
Controles compensatorios: registro de eventos, alertas SIEM y bloqueo de consolas MMC sensibles.

Resumen operativo

Paso	Qué hacer	Propósito
Crear la cuenta	Usar Active Directory Users and Computers para generar un usuario en la OU designada.	Punto de partida controlado.
Conceder derechos de instalación	No agregar a Domain Admins ni a Administrators locales. Crear un grupo de seguridad (SW‑Installers) y añadir la cuenta. En los servidores destino, añadir dicho grupo a Power Users o aplicar GPO «Always install with elevated privileges» únicamente a los equipos deseados.	Otorga permisos suficientes sin exponer todo el sistema.
Restringir la administración de identidades	Asegurar que la cuenta no forme parte de Account Operators, Backup Operators ni grupos equivalentes. Delegación de control en la OU de usuarios para denegar «Create/Delete user objects». Aplicar GPO que bloquee el acceso a dsa.msc y otras consolas de directorio.	Impide alteración de cuentas y refuerza el principio de mínimo privilegio.
Verificar	Iniciar sesión con la nueva cuenta en un servidor de laboratorio. Instalar y desinstalar un MSI o EXE. Intentar abrir ADUC o crear usuarios (debe fallar).	Confirma que la segregación de tareas funciona.

Creación de la cuenta

Para mantener un registro claro de auditoría se recomienda:

Asignar un prefijo identificativo, por ejemplo SVCSWINST_01.
Habilitar la opción «User must change password at next logon» y entregar la cuenta al responsable técnico.
Marcar «Password never expires» solo si existe un procedimiento de cambio programado documentado.

Si la organización utiliza flujos de aprovisionamiento (Identity Manager, SailPoint, etc.), insertar la cuenta en el proceso aprobado.

Asignación de derechos de instalación

Uso de grupos locales y Restricted Groups

El método más directo consiste en agregar SW‑Installers al grupo local Power Users de los servidores aplicables. Esto puede hacerse manualmente o mediante la directiva Computer Configuration ▶ Policies ▶ Windows Settings ▶ Security Settings ▶ Restricted Groups.

# Ejemplo de línea de comandos
net localgroup "Power Users" "DOMAIN\SW-Installers" /add

La ventaja de Power Users es que permite la instalación de aplicaciones compatibles con Windows Installer (MSI) y muchas basadas en EXE, sin conceder la capacidad de instalar controladores ni modificar configuraciones de sistema de alto impacto.

Delegación vía GPO “Always install with elevated privileges”

Si el software se despliega mediante MSI firmados, activar la directiva:

Computer Configuration ▶ Administrative Templates ▶ Windows Components ▶ Windows Installer ▶ Always install with elevated privileges

Con esta opción el proceso msiexec.exe se ejecutará con contexto System, habilitando instalaciones sin pertenecer a un grupo privilegiado. Es recomendable limitar el alcance de la GPO a una OU de «equipos destino de soporte», nunca a todo el dominio.

Permisos para controladores firmados

En escenarios donde sea indispensable instalar drivers, delegar únicamente:

Computer Configuration ▶ Windows Settings ▶ Security Settings ▶ User Rights Assignment ▶ Load and unload device drivers

Asignar SW‑Installers a esta directiva evita el uso de administradores locales, pero atención: un driver malicioso puede comprometer la máquina.

Control de acceso y delegación en Active Directory

Bloqueo de grupos privilegiados

Verificar regularmente que la cuenta o el grupo SW‑Installers no se encuentre en:

Domain Admins
Enterprise Admins
Administrators de cada servidor (salvo casos excepcionales con justificación)
Account Operators
Backup Operators

Una tarea programada en PowerShell puede emitir alertas si detecta pertenencia no autorizada:

Import-Module ActiveDirectory
$criticalGroups = "Domain Admins","Enterprise Admins","Administrators","Account Operators","Backup Operators"
$user = "DOMAIN\SVCSWINST_01"
foreach ($grp in $criticalGroups) {
  if (Get-ADGroupMember -Identity $grp -Recursive | Where-Object {$_.SamAccountName -eq $user.Split("\")[1]}) {
    Write-Warning "$user aparece en $grp"
  }
}

Delegación de control para impedir administración de usuarios

En la OU que contiene los objetos de usuario se puede ejecutar el asistente «Delegate Control» y denegar explícitamente:

Create, delete or manage user accounts
Reset user passwords and force password change at next logon
Modify permissions

Otra capa adicional es la configuración Permissions > Advanced donde se revocan todos los Extended Rights sobre ese contenedor a SW‑Installers.

Bloqueo de consolas sensibles

Para evitar que la cuenta abra herramientas administrativas, aplicar GPO:

User Configuration ▶ Administrative Templates ▶ System ▶ Don’t run specified Windows applications

Lista de aplicaciones a bloquear:

dsa.msc (Active Directory Users and Computers)
adsiedit.msc (ADSI Edit)
ldp.exe (LDAP Utility)
gpmc.msc (Group Policy Management)

Validación y pruebas

Antes de liberar la cuenta a producción, montar un entorno de ensayo:

Clonar un servidor o estación de trabajo estándar.
Aplicar la GPO y pertenencia a grupos tal como se hará en vivo.
Loguearse con la credencial SVCSWINST_01.
Instalar un paquete MSI empresarial y confirmar que se registra en Programs and Features.
Desinstalar la aplicación.
Intentar crear un objeto en ADUC y verificar que se recibe «Access Denied».

Documentar resultados y firmarlos por el gestor de seguridad.

Escenarios avanzados y herramientas de administración moderna

Microsoft Endpoint Configuration Manager (SCCM)

Si su organización posee SCCM, conviene delegar la distribución de software desde la consola de Configuration Manager. Se crean roles específicos (Application Administrator, Application Author) que permiten empaquetar y publicar sin otorgar derechos sobre el sistema operativo subyacente.

Intune y Windows Autopatch

Para estaciones Windows 10/11 administradas por Intune, asigne el rol integrado Application Manager, que concede acceso al blade «Apps» pero no al nodo de usuarios ni a la configuración de dispositivos fuera del alcance.

Uso de LAPS y Just‑in‑Time (JIT)

La solución Local Administrator Password Solution (LAPS) puede combinarse con PIM (Privileged Identity Management) para activar el administrador local — o un rol equivalente — solo durante el tiempo estrictamente necesario, reduciendo aún más la superficie de ataque.

Buenas prácticas y mantenimiento continuo

Rotación de contraseñas: aplicar políticas de longitud y complejidad equivalentes a cuentas privilegiadas, con rotación semestral o más frecuente según el análisis de riesgo.
Autenticación multifactor (MFA): habilitar MFA para cualquier cuenta con permisos elevados, incluso si no es administradora de dominio.
Auditoría y correlación SIEM: capturar los eventos 11707 (instalación), 11724 (desinstalación) y 4624/4634 (inicios de sesión) y enviarlos a la plataforma de monitoreo.
Segregación de entornos: disponer de OU o grupos de dispositivos diferenciados (producción, pruebas, desarrollo) y aplicar la GPO de instalación solo donde corresponda.
Documentación viva: cada modificación (alta, baja, cambio) sobre la cuenta o el grupo debe registrarse en un CMDB o sistema de tickets.

Preguntas frecuentes

¿Por qué no basta con agregar la cuenta a «Administrators» locales?

Porque Administrators otorga control total sobre el sistema, incluyendo la capacidad de habilitar RDP, cambiar políticas de seguridad, instalar drivers no firmados y crear backdoors. El objetivo es reducir privilegios.

Un instalador requiere permisos completos de administrador, ¿qué hago?

Empaquetar la aplicación para SCCM/Intune ejecutándola en contexto de sistema, o realizar la instalación bajo supervisión con credenciales de un administrador autorizado, documentando la excepción.

¿Puedo usar Run As Administrator con credenciales diferenciadas?

Sí, siempre que las credenciales introducidas correspondan al usuario de instalación (SVCSWINST_01) y que el equipo valide las GPO aplicadas. Evitar almacenar contraseñas en scripts de forma reversible.

¿Cómo evitar que la cuenta eleve privilegios por UAC?

Configurar User Account Control: Behavior of the elevation prompt for standard users como «Automatically deny elevation requests» en la GPO de la OU de destino.

Conclusión

Delegar la instalación de software sin exponer la administración de Active Directory es completamente viable combinando grupos de seguridad, directivas de grupo y buenas prácticas de auditoría. La clave radica en diseñar la delegación con rigor, validar exhaustivamente en laboratorio y monitorizar de forma continua. Con el enfoque descrito su organización reducirá la superficie de ataque y cumplirá los principios de gobierno de TI sin sacrificar agilidad operativa.