Dentro de muchos proyectos de infraestructura, surge la misma duda: “¿cuántas máquinas virtuales necesito para desplegar Active Directory de forma segura y eficiente?” A primera vista, ocho VM pueden parecer lógicas si se siguen guías genéricas, pero la realidad es más matizada.
¿Realmente se necesitan ocho máquinas virtuales?
La confusión suele arrancar en foros y laboratorios donde se presenta un proof of concept con múltiples bosques, dominios y roles distribuidos. El lector inexperto interpreta que la cifra es un requisito estricto. En entornos empresariales, sin embargo, la planificación de VM responde a tres ejes:
- Disponibilidad: cuánto tiempo de caída puedo tolerar sin afectar al negocio.
- Seguridad: hasta qué punto necesito aislar cuentas, datos o cargas de trabajo.
- Coste–rendimiento: presupuesto frente a requisitos de CPU, memoria, IOPS y licencias.
Conclusión rápida: no existe ningún mandato que obligue a desplegar ocho VM desde el inicio. Puede bastar con un bosque, un dominio y un controlador de dominio (DC) para arrancar, y crecer después de forma orgánica.
Alta disponibilidad de controladores de dominio
La práctica recomendada en producción es alojar al menos dos DC por dominio distribuidos en hosts físicos distintos. De este modo:
- Ganas tolerancia a fallos de servidor, hipervisor o almacenamiento.
- Evitas cuellos de botella en autenticación Kerberos y replicación.
- Simplificas mantenimiento: un DC puede reiniciarse sin detener el negocio.
Servidores de aplicaciones: compartir o segregar
Exchange, SQL Server, servidores de archivos o soluciones de ERP pueden convivir en la misma VM que el DC sólo en laboratorios. En producción es preferible separarlos porque:
- Las actualizaciones de seguridad de aplicaciones no impactan al servicio de directorio.
- Permite asignar recursos dedicados a procesos con picos de uso intensivo (por ejemplo, un ETL nocturno).
- Reduce la superficie de ataque: si una aplicación web es vulnerada, el atacante no obtiene acceso directo a NTDS.dit o a Sysvol.
La tabla siguiente muestra combinaciones comunes para dimensionar y cómo evolucionar a lo largo del ciclo de vida del proyecto:
| Escenario | Carga inicial | VM recomendadas | Momento de escalar |
|---|---|---|---|
| Laboratorio personal | <100 cuentas, uso ocasional | 1 DC, 1 VM de apps | Cuando necesites probar sitios AD DS o escrituras concurrentes |
| Pymes regionales | 100–500 usuarios, 2 sedes | 2 DC, 1 VM de archivos, 1 VM de SQL | Al abrir una nueva sede o implementar MFA on‑prem |
| Empresa multisede | 500–5 000 usuarios, 5–10 sedes | 2 DC por sede principal, 1 DC de sólo lectura (RODC) por oficina remota, 2–4 VMs de apps | Ante DRP activo‑pasivo o auditoría de compliance |
| Organización crítica (finanzas, salud) | >5 000 usuarios, alta criticidad | Bosque de producción, bosque “Privileged Access”, 2+ DC por dominio, 4 VM de aplicaciones distribuidas | Cuando aparezcan nuevas normativas o crezca la infraestructura cloud híbrida |
¿Qué amenazas mitiga un diseño multinivel?
Aunque algunos administradores afirman no haber sufrido incidentes, la experiencia demuestra que los bosques y dominios segregados añaden capas de defensa. Así se limitan movimientos laterales, se aplica privilegio mínimo y se segmenta la administración.
| Categoría de amenaza | Ejemplo de ataque | Protección con varios bosques/dominios |
|---|---|---|
| Malware / ransomware | Adjunto malicioso que cifra servidores | Aislar el impacto dentro de su bosque; evita cifrado simultáneo de DC críticos. |
| Amenaza interna | Administrador con credenciales comprometidas | Cuentas privilegiadas residirán en un bosque “Restricted Access” sin conectividad directa con estaciones de trabajo. |
| Ataques de credenciales | Pass‑the‑Hash / Pass‑the‑Ticket | Separar credenciales de servicio, usuario y administración; bastion forests. |
| Denegación de servicio | Saturación de consultas LDAP | Distribuir roles de operación (FSMO) entre varios DC y dominios. |
| Fuga de datos | Extracción de objetos AD o archivos | Confinar información confidencial en dominios con permisos reforzados y auditoría obligatoria. |
Cómo detectar y evidenciar estas amenazas
La detección precoz pasa por combinar logs nativos, agentes especializados y un SIEM central.
Registros locales del DC
- Security: 4624 / 4625 (inicios de sesión), 4672 (privilegios especiales), 4740 (bloqueo de cuenta), 4768–4771 (tráfico Kerberos).
- System: fallos del servicio NetLogon, reinicios inesperados.
Auditoría avanzada y Sysmon
Sysmon amplía la visibilidad: hashes de proceso, creación de archivos, conexiones a IP remotas y eventos DNS capaces de revelar túneles de comando y control.
SIEM y correlación de eventos
Herramientas como Microsoft Sentinel, Splunk Enterprise o stacks basados en Elastic agregan, enriquecen y disparan alertas en tiempo real. Algunos casos de uso listos para producción:
- Alerta cuando una cuenta Tier 0 inicia sesión en un servidor que no pertenece al Tier 0.
- Caza de hash NTLM reutilizados en varios hosts en menos de 10 min.
- Detección de modificaciones en GPO fuera de la ventana de mantenimiento.
Soluciones específicas para Active Directory
- Microsoft Defender for Identity (antes ATA): análisis en tiempo real de autenticaciones, replica tráfico NetLogon y realiza detección de lateral movement.
- PingCastle y Purple Knight: auditorías puntuales con informe de riesgos, concentración de privilegios y objetos obsoletos.
Buenas prácticas de detección
- Habilitar “Audit Directory Service Changes” y “Advanced Audit Policy” desde la GPO.
- Reenviar eventos a un WEC o Syslog inmutable con retención mínima de 365 días.
- Revisar mensualmente los grupos con SIDHistory y las cuentas con privilegios delegados.
Recomendaciones complementarias
Plan mínimo para laboratorios
Si tu objetivo es aprender o probar parches, arranca con 2 DC (uno por sitio lógico) y 1 servidor de aplicaciones. A partir de ahí:
- Agrega un bosquecito “bastión” cuando quieras practicar técnicas de salto (PAW Tiering).
- Añade objetos de confianza unidireccional para simular fusiones y adquisiciones.
Automatiza el despliegue repetible
Ahorra tiempo con plantillas de Hyper‑V/VMware, scripts de PowerShell DSC o Terraform. Define variables como CPU, RAM, VLAN y redes de gestión para clonar el entorno en minutos.
Seguridad desde el diseño
- Aísla credenciales administrativas (Tier 0) en un bosque de acceso restringido desconectado de VLAN de usuarios.
- Implementa LAPS o su sucesor Windows LAPS para gestionar contraseñas locales únicas y rotativas.
- Exige MFA y contraseñas de uso único a toda cuenta con privilegios de dominio; evita AdminSDHolder sin justificación.
Documenta y revisa
Los diagramas de bosques, dominios y relaciones de confianza deben mantenerse vivos. Además:
- Ejecuta simulacros de restauración del estado del sistema cada seis meses.
- Versiona la configuración de GPO y DNS en repositorios privados (Git).
- Verifica la expiración de certificados de DC en tu PKI interna y establece alertas con 30 días de antelación.
Consideraciones de licenciamiento y recursos
El número de VM no sólo impacta en hardware; también hay implicaciones de licencias para Windows Server y CALs. Ten en cuenta:
- Cada host físico que ejecute más de dos VM Windows Server necesita licencias adicionales o suscripciones por núcleo.
- Las CALs de usuario se vuelven obligatorias a partir del primer inicio de sesión, sin importar si hay uno o diez dominios.
- En entornos mixtos (on‑prem y nube), compara modelos hybrid benefit frente a licencias por hora en IaaS.
Dimensionamiento orientativo para un DC moderno:
| Usuarios soportados | CPU (vCores) | RAM (GB) | Almacenamiento (GB) |
|---|---|---|---|
| <500 | 2 | 4–8 | 40 OS + 20 logs |
| 500–5 000 | 4 | 8–16 | 60 OS + 40 logs |
| >5 000 | 8 | 16–32 | 80 OS + 60 logs |
¿Cuándo conviene realmente separar servicios?
No todos los roles justifican su propia VM. Aun así, existen señales claras de que ha llegado el momento de segregar:
- La base de datos de SQL supera el 60 % de uso de CPU sostenido.
- El arranque de Exchange genera tiempos de IO superiores a 15 ms.
- Necesitas aplicar parches de forma escalonada para cumplir SLA de negocio.
- Hay requisitos de compliance que prohíben que un servicio tier 1 conviva con un componente tier 0.
Plan de expansión gradual
- Fase 1: validación
Un bosque, dos DC, backups diarios, replicación cada 15 min. Ideal para crear políticas de grupo (GPO) y probar scripts de inicio de sesión. - Fase 2: seguridad
Se añade un bosque “bastión”, DCs con Shielded VM, jump servers con autenticación fuerte y estaciones PAW. - Fase 3: resiliencia
RODCs en sedes remotas, DFS‑R para Sysvol, DNS SEC interno, Azure AD Connect para identidad híbrida. - Fase 4: automatización
Terraform + canales CI/CD despliegan bosques de prueba efímeros para pipelines de QA; integración con Policy as Code.
Resumen ejecutivo
No existe una regla rígida que imponga ocho máquinas virtuales ni múltiples bosques para Active Directory. Lo que sí existe es la necesidad de alinear la arquitectura con los objetivos de negocio, la tolerancia a fallos y la postura de seguridad.
- Mínimo recomendable: dos DC por dominio para alta disponibilidad.
- Aislamiento: bosques separados para cuentas administrativas y recursos de alto valor.
- Monitorización: logs nativos, Sysmon y un SIEM con reglas de uso inmediato.
- Escalabilidad: crecer en fases, automatizar y revisar diagramas de forma continua.
Si se aplica este enfoque, la organización reduce la superficie de ataque, mejora la resiliencia ante ransomware y simplifica auditorías de cumplimiento, todo ello evitando el sobrecoste y la complejidad innecesaria de “ocho VM por defecto”.