Active Directory: gestiona usuarios y equipos a escala

Active Directory es el servicio de directorio que organiza y controla el acceso a los recursos en prácticamente todos los entornos Windows empresariales del mundo. Después de más de veinticinco años desde su introducción en Windows 2000, sigue siendo el pilar central de la gestión de identidades en miles de organizaciones, desde pequeñas empresas hasta corporaciones multinacionales con decenas de miles de empleados.

Gestionar Active Directory a escala no es lo mismo que administrarlo en un entorno pequeño. Cuando el directorio crece hasta cientos o miles de usuarios, grupos, equipos y políticas, la falta de planificación y de buenas prácticas se convierte en deuda técnica que se acumula hasta hacer el sistema inmanejable. Los problemas más comunes son estructuras de OU caóticas, GPOs contradictorias, proliferación de grupos sin propietario claro y cuentas huérfanas de usuarios que ya no están en la empresa.

Esta guía aborda la administración de Active Directory desde la perspectiva de la escala: cómo diseñar correctamente desde el principio, cómo automatizar la gestión con PowerShell, cómo delegar sin perder el control, y cómo asegurar el directorio contra las amenazas más comunes. Tanto si gestionas un AD heredado que necesita orden como si estás diseñando uno nuevo, estos principios y prácticas son directamente aplicables.

Diseño de la estructura de Unidades Organizativas (OU)

La estructura de Unidades Organizativas es la base sobre la que se construye todo lo demás: la delegación de administración, la aplicación de GPOs y la organización lógica de los objetos del directorio. Un diseño de OU bien pensado facilita enormemente la gestión a largo plazo; uno caótico hace que cada cambio sea un ejercicio de arqueología.

Existen dos enfoques principales para estructurar las OUs: por geografía/localización o por función/tipo de objeto. En la práctica, la mayoría de los entornos empresariales maduros adoptan una estructura híbrida: una primera capa geográfica (por país, región o sede) y dentro de cada geografía, una separación por tipo de objeto (Usuarios, Equipos, Servidores, Grupos, Cuentas de servicio). Esta estructura facilita la delegación regional y la aplicación de políticas diferenciadas por localización.

Un principio fundamental es separar los objetos por tipo dentro de cada OU: nunca mezclar usuarios con equipos o grupos en la misma OU. Esta separación permite aplicar GPOs de usuario y de equipo de forma independiente, facilita las consultas LDAP y hace más intuitiva la delegación. Las cuentas de servicio merecen su propia OU específica, separada de los usuarios normales, para poder aplicarles políticas de contraseña diferenciadas y facilitar su auditoría.

Ejemplo de estructura de OU recomendada para empresa mediana

1. Raíz del dominio: contiene las OUs de primer nivel y nada más
2. CORP > Madrid: usuarios, equipos, grupos, servidores, cuentas de servicio de la sede de Madrid
3. CORP > Barcelona: misma estructura para la sede de Barcelona
4. CORP > Telerabajo: usuarios y equipos de trabajadores remotos sin sede fija
5. CORP > Administracion TI: cuentas administrativas segregadas, PAWs y grupos de TI
6. CORP > Desactivados: usuarios y equipos deshabilitados pendientes de eliminación definitiva

Gestión de usuarios: ciclo de vida completo

La gestión del ciclo de vida de los usuarios en AD abarca desde la creación de la cuenta en el día de incorporación hasta su deshabilitación definitiva y eliminación tras la salida. Un proceso mal definido aquí genera los problemas de seguridad más comunes: cuentas activas de empleados que ya no están en la empresa, usuarios con permisos que ya no necesitan por cambios de rol, y cuentas cuya contraseña nunca ha cambiado.

El proceso de altas (onboarding) debe estar integrado con el sistema de RRHH. En entornos avanzados, Microsoft Identity Manager (MIM) o soluciones SaaS como Entra ID Governance automatizan la creación de cuentas basándose en los datos del ERP de RRHH. En entornos más sencillos, un script de PowerShell que cree la cuenta, la añada a los grupos adecuados según el departamento y envíe las credenciales temporales al responsable es una solución eficiente y perfectamente válida.

El proceso de bajas es igual o más crítico que el de altas. En el mismo día en que un empleado deja la empresa, su cuenta debe deshabilitarse (no eliminarse inmediatamente, ya que puede haber ficheros o recursos asociados que necesiten transferirse). La práctica recomendada es deshabilitar la cuenta, mover el objeto a la OU de Desactivados, eliminar todos los grupos excepto el primario, establecer la contraseña a un valor aleatorio y revisar la pertenencia a grupos privilegiados. La eliminación definitiva puede realizarse después de 90 días.

Gestión de grupos: nomenclatura, ámbito y limpieza

Los grupos de Active Directory son el mecanismo principal para gestionar el acceso a recursos a escala. Sin una estrategia clara de grupos, el resultado inevitable es la proliferación descontrolada: grupos sin propietario identificable, grupos que nadie sabe para qué sirven y usuarios con membresías que nadie revisó en años. Esta situación es un riesgo de seguridad y un problema de cumplimiento.

La estrategia AGDLP (Account → Global group → Domain Local group → Permission) es el modelo recomendado por Microsoft y el que mejor escala en entornos grandes. Los usuarios se añaden a Grupos Globales organizados por rol o departamento. Los Grupos Globales se anidan en Grupos de Dominio Local que tienen los permisos efectivos sobre los recursos. Esta separación entre 'quién eres' (Global) y 'qué puedes acceder' (Domain Local) facilita enormemente la gestión del acceso en entornos complejos.

La nomenclatura de los grupos debe ser consistente y descriptiva. Una convención útil es incluir el tipo (GG para Global Group, DL para Domain Local), el ámbito o recurso y el nivel de acceso: por ejemplo, 'GG-Finanzas-Madrid' para el grupo global de usuarios de finanzas en Madrid, y 'DL-ServidorFinanzas-RW' para el grupo de dominio local con acceso de lectura/escritura al servidor de finanzas. Esta nomenclatura hace el directorio autodocumentado.

Group Policy Objects (GPOs): diseño y buenas prácticas

Las Directivas de Grupo (GPOs) son el mecanismo más potente de Windows para gestionar la configuración de usuarios y equipos a escala. Una GPO bien diseñada puede configurar desde la política de contraseñas hasta los ajustes de Internet Explorer (ya en desuso pero presente en muchos entornos heredados), instalar software, configurar impresoras, mapear unidades de red y aplicar configuraciones de seguridad.

El diseño de GPOs debe seguir el principio de responsabilidad única: cada GPO debe tener un propósito claro y acotado. Las GPOs monolíticas que configuran docenas de ajustes diferentes son difíciles de mantener y depurar. Una estructura recomendada incluye GPOs base (aplicadas al dominio completo, que configuran aspectos de seguridad mínimos), GPOs de seguridad (aplicadas a OUs específicas), GPOs de software (para despliegue de aplicaciones) y GPOs de usuario (para personalización del escritorio y mapeo de recursos).

El orden de procesamiento de GPOs (LSDOU: Local, Site, Domain, OU) y la herencia son fuentes frecuentes de confusión y comportamientos inesperados. La opción 'Enforced' (antes llamada 'No Override') garantiza que una GPO no pueda ser sobrescrita por GPOs de niveles inferiores, mientras que 'Block Inheritance' en una OU impide que las GPOs de niveles superiores se apliquen. Estas opciones deben usarse con moderación y siempre documentadas, ya que pueden hacer el comportamiento del sistema muy difícil de predecir para administradores que las desconozcan.

GPOs de seguridad imprescindibles en todo entorno empresarial

• Política de contraseñas: longitud mínima 12 caracteres, complejidad habilitada, historial de 12 contraseñas
• Política de bloqueo de cuenta: umbral de 5 intentos, duración de bloqueo 30 minutos, reinicio del contador 30 minutos
• Deshabilitar el almacenamiento de hashes LM en el registro
• Configurar la pantalla de inicio de sesión para no mostrar el último usuario
• Habilitar el firewall de Windows en todos los perfiles (Domain, Private, Public)
• Configurar Windows Defender con protección en tiempo real y protección contra manipulación
• Habilitar la auditoría avanzada de seguridad: inicio de sesión, gestión de cuentas, acceso a objetos
• Configurar PowerShell en modo de lenguaje restringido y habilitar script block logging
• Establecer la política de control de cuentas de usuario (UAC) en el nivel máximo

Delegación de administración: el principio de mínimo privilegio

La delegación de administración en AD permite que diferentes equipos gestionen partes del directorio sin necesitar privilegios de Domain Admin. Domain Admin es el nivel de privilegio máximo en un dominio y debe reservarse para el conjunto mínimo de tareas que absolutamente lo requieren. La proliferación de cuentas con Domain Admin es uno de los riesgos de seguridad más comunes y más graves en entornos AD.

El Delegation of Control Wizard de Active Directory Users and Computers permite delegar tareas específicas a grupos concretos sobre OUs específicas. Por ejemplo, el equipo de helpdesk puede recibir el derecho a restablecer contraseñas de usuarios en la OU de usuarios regulares, sin tener acceso a la OU de cuentas administrativas. Los responsables de RRHH de cada oficina pueden tener permiso para crear y modificar usuarios en la OU de su sede, sin acceso a otras regiones.

Para delegaciones más complejas, el uso de PowerShell con los cmdlets del módulo ActiveDirectory y la manipulación directa de ACEs (Access Control Entries) en el descriptor de seguridad de los objetos proporciona granularidad total. La herramienta AD ACL Scanner, disponible como script de PowerShell en el sitio de TechNet/GitHub, permite auditar y reportar las delegaciones configuradas en el directorio, lo que facilita enormemente las revisiones periódicas de permisos.

Fine-Grained Password Policies: políticas de contraseña granulares

Hasta Windows Server 2008, solo era posible tener una política de contraseñas por dominio. Las Fine-Grained Password Policies (FGPP) eliminaron esta limitación, permitiendo definir políticas diferentes para distintos grupos de usuarios. Esto es fundamental para aplicar políticas más estrictas a cuentas privilegiadas sin imponer esas mismas restricciones a todos los usuarios.

Las FGPPs se configuran mediante objetos Password Settings Object (PSO) en el contenedor Password Settings Container dentro de System. Cada PSO tiene una precedencia (cuanto menor el número, mayor la prioridad) que determina qué política se aplica cuando un usuario o grupo tiene múltiples PSOs aplicados. La práctica recomendada es crear al menos dos niveles: una política estándar para usuarios regulares y una política estricta para administradores y cuentas privilegiadas.

Para las cuentas de servicio gestionadas, Windows Server 2012 introdujo las Managed Service Accounts (MSA) y las Group Managed Service Accounts (gMSA). Las gMSA permiten que Active Directory gestione automáticamente la contraseña de las cuentas de servicio, rotándola periódicamente y distribuyéndola a los servidores autorizados. Esto elimina completamente el problema de las contraseñas de cuentas de servicio que nunca se cambian por miedo a romper dependencias.

Seguridad de Active Directory: los ataques más comunes

Active Directory es un objetivo primario en cualquier ataque avanzado contra infraestructuras Windows. El compromiso de un controlador de dominio equivale al compromiso total de toda la infraestructura Windows de la organización. Comprender los vectores de ataque más comunes es imprescindible para implementar las defensas adecuadas.

Pass-the-Hash (PtH) y Pass-the-Ticket (PtT) son los ataques más habituales una vez que un atacante obtiene acceso a credenciales en memoria. Herramientas como Mimikatz permiten extraer hashes de contraseñas NTLM y tickets Kerberos de la memoria de procesos con privilegios elevados. Las defensas incluyen Credential Guard (que aísla las credenciales en un contenedor protegido por hipervisor), Protected Users Security Group (que restringe el uso de protocolos de autenticación más débiles) y la eliminación de privilegios administrativos locales innecesarios.

Kerberoasting es un ataque que aprovecha el protocolo Kerberos para obtener tickets de servicio cifrados con la contraseña de las cuentas de servicio, que luego se pueden atacar offline. Las cuentas de servicio con SPNs registrados y contraseñas débiles son el objetivo. La mitigación consiste en usar gMSAs (que tienen contraseñas de 120 caracteres aleatorios, invulnerables a este ataque), y para las cuentas de servicio tradicionales, usar contraseñas de 25 o más caracteres aleatorios.

Indicadores de compromiso en Active Directory

• Adición inesperada de cuentas al grupo Domain Admins o Enterprise Admins
• Creación de nuevas cuentas con privilegios elevados fuera del proceso habitual
• Modificaciones en la política de dominio predeterminada (Default Domain Policy)
• Cambios en los descriptores de seguridad de objetos críticos (AdminSDHolder, domainDNS)
• Solicitudes Kerberos de tickets de servicio (TGS) en volumen inusual desde una cuenta
• Intentos de replicación DC (DCSync) desde cuentas que no son controladores de dominio
• Cambios en los atributos msDS-AllowedToDelegateTo de cuentas de usuario o equipo

Automatización con PowerShell: gestión eficiente a escala

PowerShell con el módulo ActiveDirectory es la herramienta más poderosa para gestionar AD a escala. Tareas que llevarían horas haciendo clic en la interfaz gráfica se pueden automatizar en minutos con un script bien escrito. El módulo ActiveDirectory incluye más de cien cmdlets que cubren prácticamente todas las operaciones del directorio.

Los cmdlets más utilizados en la administración diaria incluyen Get-ADUser, New-ADUser, Set-ADUser y Remove-ADUser para la gestión de cuentas; Get-ADGroup, New-ADGroup y Add-ADGroupMember para grupos; y Get-ADComputer para la gestión de equipos. La potencia real viene de combinarlos con el pipeline de PowerShell: por ejemplo, Get-ADUser -Filter {Enabled -eq $true -and PasswordNeverExpires -eq $true} -SearchBase 'OU=Users,DC=corp,DC=local' permite identificar en segundos todas las cuentas activas con contraseña que no caduca.

La auditoría periódica del directorio debe automatizarse mediante scripts que generen informes sobre cuentas inactivas (usuarios que no han iniciado sesión en más de 90 días), grupos vacíos o sin propietario, cuentas con permisos privilegiados y discrepancias respecto al estado esperado. Estos informes deben revisarse regularmente y los hallazgos deben generar tickets de trabajo para el equipo de administración.

Azure AD Connect: integración con la nube

En entornos que utilizan Microsoft 365 o servicios de Azure, Azure AD Connect (ahora Microsoft Entra Connect) sincroniza los objetos del AD local con Microsoft Entra ID (anteriormente Azure AD). Esta sincronización permite a los usuarios usar sus credenciales corporativas para acceder tanto a recursos on-premises como a servicios en la nube, simplificando enormemente la gestión de identidades.

La configuración de Azure AD Connect requiere planificación cuidadosa. El modelo de sincronización de contraseñas (Password Hash Synchronization, PHS) es el más simple y proporciona resilencia ante fallos del AD local. La autenticación pass-through (PTA) mantiene la validación de credenciales siempre en los controladores de dominio locales, lo que puede ser un requisito para organizaciones con políticas de cumplimiento estrictas. La federación con AD FS ofrece el mayor control pero añade complejidad y puntos de fallo adicionales.

Con la evolución hacia Microsoft Entra ID, organizaciones que antes dependían exclusivamente de AD on-premises están adoptando modelos híbridos o incluso migrando completamente a la nube. Para nuevas organizaciones o entornos donde se puede partir de cero, una arquitectura cloud-native con Microsoft Entra ID y Microsoft Intune para la gestión de dispositivos puede eliminar completamente la necesidad de AD on-premises, simplificando la infraestructura y reduciendo los costes de operación.

Monitorización y auditoría de Active Directory

La auditoría de Active Directory es un requisito normativo en marcos como ISO 27001, ENS y RGPD, y una necesidad operativa para detectar y responder a incidentes de seguridad. El subsistema de auditoría de Windows genera eventos en el registro de seguridad (Security Event Log) para cada operación del directorio, pero la cantidad de eventos generados en un entorno activo es tan grande que hace imprescindible una plataforma de gestión centralizada de logs.

Las herramientas de Microsoft para la monitorización de AD incluyen Azure Monitor con el conector de AD, Microsoft Sentinel (SIEM en la nube) y Advanced Threat Analytics (ATA), aunque este último ha sido reemplazado por Microsoft Defender for Identity. Esta última solución analiza el tráfico de autenticación Kerberos directamente en los controladores de dominio (mediante sensores en DC) y detecta automáticamente patrones de ataque conocidos como Kerberoasting, Pass-the-Hash y reconocimiento con LDAP.

Los eventos más importantes a monitorizar incluyen las modificaciones en grupos privilegiados (Event ID 4728, 4732, 4756), los cambios en políticas de dominio (Event ID 5136), los intentos de inicio de sesión fallidos (Event ID 4625) y los bloqueos de cuentas (Event ID 4740). Configurar alertas automáticas sobre estos eventos en el SIEM corporativo es una práctica de seguridad fundamental que debe implementarse desde el primer día.

Active Directory es como los cimientos de un edificio: mientras todo funciona bien nadie los nota, pero cuando algo falla o alguien accede donde no debe, es lo primero que el incidente forense examina.

Tiering model: el modelo de administración por niveles

El modelo de administración por niveles (Tiered Administration Model) de Microsoft es el estándar de facto para proteger las cuentas privilegiadas en entornos AD. El principio es simple pero poderoso: una cuenta de administrador de un nivel superior nunca debe iniciar sesión en sistemas de un nivel inferior, porque esto expone las credenciales privilegiadas en sistemas menos seguros.

El modelo define tres niveles: Tier 0 (controladores de dominio y sistemas de gestión de identidades), Tier 1 (servidores de aplicaciones y bases de datos) y Tier 2 (estaciones de trabajo y dispositivos de usuario final). Un administrador de Tier 0 tiene una cuenta separada específica para gestionar los DC, que nunca se usa en estaciones de trabajo. Las Privileged Access Workstations (PAWs) son estaciones de trabajo dedicadas y endurecidas desde las que se realizan las tareas administrativas de cada nivel.

Conclusión: AD bien gestionado, empresa bien protegida

Active Directory es uno de los activos más críticos y, a la vez, más frecuentemente descuidados de la infraestructura empresarial. Un directorio bien diseñado, con estructura de OU clara, GPOs coherentes, delegación granular y monitorización activa, es la base de una postura de seguridad sólida y de operaciones TI eficientes.

La deuda técnica en AD es real y tiene consecuencias graves: desde problemas de seguridad por permisos excesivos hasta interrupciones de servicio por GPOs mal configuradas. El camino para reducirla es la automatización con PowerShell, la documentación de las decisiones de diseño y las revisiones periódicas de la configuración. Invertir tiempo en poner orden en el directorio es una de las iniciativas con mejor retorno en cualquier equipo de TI empresarial.