Control de acceso personalizado en Windows Server 2019/2022 sin privilegios de dominio

Asignar permisos de instalación de software sin otorgar control sobre usuarios en Active Directory es posible en Windows Server 2019/2022 si se combinan los principios de mínimo privilegio, los grupos de seguridad adecuados y políticas de grupo (GPO) bien diseñadas.

Índice

Resumen del desafío

En muchas organizaciones se requiere que técnicos o proveedores externos instalen o retiren aplicaciones y cambien determinados ajustes de servicio en servidores de producción, pero sin que estas cuentas puedan:

  • Crear, modificar o eliminar objetos de usuario o equipo en Active Directory.
  • Añadir o quitar administradores locales.
  • Tocar configuraciones de seguridad globales o directivas de dominio.

La solución pasa por delegar tareas concretas en cuentas con privilegios mínimos, reforzadas con GPO y auditoría.

Principios de mínimo privilegio

Antes de entrar en la configuración es importante recordar los fundamentos:

  1. Separación de tareas: cada cuenta debe tener acceso únicamente a los recursos y operaciones imprescindibles para su función.
  2. Containment: el alcance de los permisos se limita a equipos y rutas de archivos específicos.
  3. Auditoría y vigilancia: todo intento de escalada o cambio fuera de lo autorizado debe quedar registrado.

Aplicar estos principios reduce la superficie de ataque y cumple con requerimientos de normas como ISO 27001, PCI‑DSS o Esquema Nacional de Seguridad (ENS).

Pasos detallados para la implementación

Creación de las cuentas en Active Directory

En Active Directory Users and Computers (ADUC):

  • Crea cada usuario dentro de una OU específica para “Instaladores de software”. Esto facilita la aplicación de GPO exclusivas.
  • Evita agregar las cuentas a Domain Admins, Enterprise Admins o grupos incorporados como Administrators. Su poder es excesivo.

Diseño de un grupo de seguridad dedicado

Para no conceder privilegios locales de administrador global, crea un grupo de dominio:

New-ADGroup -Name "Install-Software" -GroupScope Global -Path "OU=Grupos,DC=contoso,DC=com"

Añade los usuarios técnicos a ese grupo. Más adelante será el sujeto sobre el que otorgar o denegar derechos.

Asignación de permisos de instalación sin escalar privilegios

En cada servidor destino (o mediante GPO de Seguridad) se conceden derechos específicos al grupo Install-Software:

Recurso / DerechoJustificación
Carpeta C:\Program Files (Modify)Escritura de binarios durante la instalación.
Carpeta C:\Windows\Temp (Modify)Algunos instaladores extraen ficheros temporales ahí.
Claves HKLM específicas (Full Control)Registro de ruta de instalación y servicios.
User Rights Assignment: Start, stop and pause servicesPermitir reiniciar servicios afectados.

La concesión se hace con ACLs o mediante Restricted Groups si es más cómodo centralizarlo.

Denegación explícita de administración de usuarios

Para bloquear cambios de cuentas:

  • Crea –o reutiliza– una GPO y ve a Computer Configuration → Policies → Windows Settings → Security Settings → User Rights Assignment.
  • Agrega el grupo Install-Software en las siguientes directivas, pero como Deny:
Add workstations to domainImpide unir equipos nuevos al dominio.
Create, delete, and manage user accountsBloquea la gestión en AD y en el SAM local.
Manage auditing and security logEvita cubrir sus propias huellas.

En servidores miembro (no DC) también es recomendable:

Software Restriction Policies → Additional Rules
Disallowed: %SystemRoot%\System32\lusrmgr.msc
Disallowed: %SystemRoot%\System32\compmgmt.msc

Así el usuario no lanzará las consolas de gestión local.

Configuración de la GPO completa

Se recomienda una sola GPO por cada rol de privilegios para simplificar auditoría. Dentro de la GPO:

  • User Rights Assignment: otorga únicamente SeServiceLogonRight y SeIncreaseBasePriorityPrivilege si el instalador lo requiere.
  • Security Options: revisa la directiva “User Account Control: Run all administrators in Admin Approval Mode”. No la desactives salvo que un instalador heredado lo exija y no exista alternativa.
  • File System: define ACLs para carpetas y ejecutables que reciban software frecuentemente.
  • Registry: protege claves críticas (HKLM\SAM, HKLM\SECURITY, etc.) con permisos Read para el grupo.

Vincula la GPO a la OU donde residen los servidores afectos y verifica que herede correctamente. Usa gpupdate /force tras los cambios.

Pruebas de validación

  1. En un servidor de laboratorio, inicia sesión con una cuenta de prueba perteneciente a Install-Software.
  2. Instala un MSI o EXE firmado que requiera acceso a C:\Program Files. Debe completarse sin elevación de privilegios adicional.
  3. Intenta abrir ADUC o crear un nuevo usuario local con net user. El sistema debe denegar la operación con error de permisos.
  4. Consulta el Visor de eventos (Security) y comprueba que se registran los ID 4717 (SeAssignPrimaryTokenPrivilege) o 4672 (Special privileges assigned) si existieran intentos de escalada.
  5. Repite la prueba tras cada modificación para evitar regresiones.

Estrategias avanzadas

Just‑Enough Administration (JEA)

Cuando las instalaciones se orquestan mediante PowerShell, JEA permite publicar session configurations que exponen solo los cmdlets necesarios a cada operador. Ejemplo básico:

# Registro de una sesión JEA
New-PSSessionConfigurationFile `
  -Path "C:\ProgramData\JEA\InstallSoftware.pssc" `
  -RunAsVirtualAccount `
  -VisibleCmdlets @{
      Name = 'Start-Service','Stop-Service','Install-Package'
      Parameters = '*'
  }
Register-PSSessionConfiguration -Name InstallSoftware -Path "C:\ProgramData\JEA\InstallSoftware.pssc"

Con esta aproximación, incluso los cmdlets accesibles se ejecutan en un virtual account efímero sin derechos para tocar AD.

Delegated Administration en IIS, SQL Server y otros servicios

No confundas la delegación dentro del sistema operativo con la delegación de aplicaciones.

  • IIS Manager: otorga Site Delegation para que técnicos reinicien aplicaciones web sin ser Administrators.
  • SQL Server: usa roles como dbowner o dbddladmin y evita el rol de servidor sysadmin.
  • Servicios personalizados: emplea el cmdlet sc.exe sdset o la función de PowerShell Set-ServicePermissions para definir DACLs granulares.

Auditoría y supervisión

Activar auditoría exhaustiva es fundamental para detectar y probar el cumplimiento de la política. Las categorías mínimas son:

CategoríaEventos clave
Audit Policy ChangeID 4902 – Create basic audit policy; ID 4719 – System audit policy changed.
Audit Privilege UseID 4673 – Privileged service called; ID 4674 – Operation attempted on privileged object.
Audit Directory Service AccessID 4662 – An operation was performed on an object (solo en DC).

Envía los eventos a SIEM (Splunk, Sentinel, etc.) y configura alertas de uso atípico fuera de horario o desde direcciones IP no autorizadas.

Preguntas frecuentes (FAQ)

¿Es seguro usar el grupo integrado “Power Users”?

No. Este grupo se diseñó para Windows XP; hoy concede más privilegios de los necesarios y su comportamiento es inconsistente entre versiones de Windows Server.

¿Puedo usar UAC para mitigar en lugar de GPO?

UAC no es un modelo de control de acceso sino un mecanismo de elevación interactiva. Por tanto, no impide que la cuenta disponga del token de administrador si pertenece a un grupo privilegiado. La clave es no otorgarle ese grupo.

¿Qué ocurre si un instalador modifica las ACLs tras obtener acceso?

Como las ACLs están definidas en la GPO, se re‑aplicarán con cada actualización de directiva. Además, al no tener SeSecurityPrivilege ni SeTakeOwnershipPrivilege, la cuenta no podrá cambiar la DACL de archivos sensibles.

¿Cómo evitar que el usuario instale software malicioso?

Combina la solución con una política de Device Guard/Application Control o AppLocker que limite la ejecución a binarios firmados o aprobados. Así, aunque tenga permiso de escritura en C:\Program Files, no podrá lanzar código no confiable.

Checklist de implementación rápida

  • ✅ Crear grupo Install-Software en AD.
  • ✅ Agregar técnicos y proveedores externos al grupo.
  • ✅ Conceder ACLs específicas en carpetas y registro.
  • ✅ Crear GPO con User Rights mínimos + denegaciones.
  • ✅ Bloquear MMC de cuentas locales vía Software Restriction Policies.
  • ✅ Activar auditoría y enviar logs a SIEM.
  • ✅ Probar en entorno de laboratorio antes de producción.

Conclusión

La combinación de grupos de seguridad dedicados, GPO de mínimo privilegio y auditoría exhaustiva permite habilitar la instalación y mantenimiento de software en Windows Server 2019/2022 sin exponer el dominio a riesgos innecesarios. Esta estrategia se alinea con los marcos de ciberseguridad modernos, facilita la separación de tareas y cumple los principios de “Least Privilege” y “Need to Know”. Con una validación cuidadosa y documentación clara, tu equipo tendrá la agilidad necesaria para mantener los servidores actualizados y seguros.

Índice