Active Directory: fundamentos y hardening

Definición

Active Directory Domain Services (AD DS) es el servicio de directorio de Microsoft para entornos Windows que centraliza:

• Identidades (usuarios, equipos, grupos, cuentas de servicio).
• Autenticación (quién eres) y autorización (qué puedes hacer).
• Configuración y control a escala mediante Group Policy (GPO).

En el RAW aparecen dos piezas base:

• Dominio: unidad central de la estructura lógica donde residen objetos y políticas.
• Controlador de dominio (DC): servidor que “hace de cerebro” del dominio (autenticación/autorización, servicio de directorio y componentes asociados).

Contexto

• En muchas organizaciones, AD es el “sistema nervioso” de la empresa: si se compromete un DC o cuentas Tier 0, el impacto suele ser catastrófico (control de identidades, cambios de políticas, movimiento lateral).
• AD no es solo “usuarios y contraseñas”: depende de piezas como DNS, sincronización de tiempo y protocolos de red (SMB/LDAP/Kerberos).
• Un objetivo práctico de hardening: que un atacante con un primer acceso no pueda:
  • Escalar a privilegios de dominio con facilidad.
  • Usar credenciales privilegiadas en equipos “de menor confianza”.
  • Persistir sin dejar trazas útiles para detección/IR.

Nota: el RAW referencia documentación de Azure AD (hoy Microsoft Entra ID) para MFA y política de contraseñas. En entornos híbridos esto aplica directamente; en AD on‑prem puro, la implementación exacta de MFA depende de la integración (ADFS, NPS extension, etc.). Se conserva la referencia y se indica dónde validar.

Desarrollo (MIT-style)

1) Estructura lógica: dominios, árboles y bosques

Dominios: límite lógico principal para cuentas, políticas y administración. En general, el dominio es donde “viven” objetos y donde se aplican GPOs de forma organizada.

Árbol (Tree): conjunto de dominios relacionados jerárquicamente (raíz + dominios hijo) que comparten un espacio de nombres contiguo. En el RAW se menciona que la comunicación entre dominios de un árbol se rige por confianzas (trusts).

Bosque (Forest): conjunto de uno o más árboles que comparten:

• Esquema (qué tipos de objetos/atributos existen),
• catálogo global (búsqueda/autenticación a nivel forestal),
• configuración y estructura lógica compartida.

Por qué importa: el bosque suele ser el “límite máximo” de confianza. Si comprometes identidades/infra Tier 0 del bosque, el radio de impacto se multiplica.

2) Confianzas (Trusts) en AD

En el RAW: la confianza es el “puente” que permite compartir recursos entre dominios de forma gobernada (no todo queda accesible automáticamente).

Dos clasificaciones clave:

• Por características:
  • Transitivas: una relación puede extenderse (si A confía en B y B en C, A puede terminar confiando en C en ciertos escenarios).
  • No transitivas: la relación no “se hereda”.
• Por dirección:
  • Unidireccional: A confía en B (pero no necesariamente al revés).
  • Bidireccional: confianza mutua.

Acceso a la consola (según RAW): Server Manager > Tools > Active Directory Domains and Trust

Buenas prácticas (operativas):

• Tratar cada trust como un contrato de seguridad: justificar el caso de uso, documentar owners, revisar periódicamente.
• Minimizar trusts “amplios” sin segmentación adicional; preferir accesos explícitos (grupos/ACLs).

3) Objetos, contenedores y “leaf objects”

En AD, casi todo es un objeto: usuarios, equipos, grupos, servicios, recursos.

El RAW introduce:

• Contenedor: objeto que puede contener otros objetos.
• Objeto hoja (leaf): objeto que no contiene otros (p.ej., un usuario o un equipo).

Contexto adicional útil:

• En la práctica, la estructura organizativa (OUs y contenedores) es clave para:
  • aplicar GPOs de forma consistente,
  • delegar administración (RBAC),
  • reducir “blast radius” de un error de política.

4) GPO como mecanismo de hardening (Group Policy Management Editor)

El RAW usa Group Policy Management Editor como herramienta central para configurar políticas de seguridad (dominio/DC/hosts).

Recomendaciones prácticas:

• Diseñar GPOs por objetivo (hardening, auditoría, configuración base) y por scope (DCs vs servidores miembro vs estaciones).
• Evitar “GPO monolítica”: dificulta auditoría, rollback y troubleshooting.
• Mantener backups/versionado de GPO (y evidencia de cambios) como parte de gobernanza.

5) Asegurar autenticación y protocolos (LM/NT hash, SMB signing, LDAP signing)

5.1 LM hash vs NT hash (evitar LM)

Del RAW:

• Windows puede generar LM hash y NT hash (según longitud/configuración).
• LM hash es más débil y facilita fuerza bruta rápida.

Control recomendado (según RAW): evitar que se almacene LM hash tras el siguiente cambio de contraseña: Group Policy Management Editor > Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Network security - Do not store LM hash value on next password change policy > select "Define policy setting"

Notas operativas:

• Esta directiva suele requerir cambio de contraseña para que el LM hash deje de existir para ese usuario.
• En entornos legacy, validar compatibilidad antes de forzar cambios globales.

5.2 SMB Signing (integridad frente a MiTM)

Del RAW:

• SMB se usa para archivos/impresión y puede ser objetivo de ataques MiTM.
• La firma SMB ayuda a garantizar integridad del tráfico cliente/servidor.

Configuración propuesta (según RAW): Group Policy Management Editor > Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Microsoft network server: Digitally sign communication (always) > select Enable Digitally Sign Communications

Pitfall frecuente: habilitar “always” sin validar impacto en legacy/performance. Planificar despliegue gradual y medir.

5.3 LDAP Signing (SASL) para evitar LDAP “en claro”

Del RAW:

• LDAP se usa para localizar/autenticar recursos.
• Sin controles, puede ser objetivo de replay/MiTM.
• LDAP signing (SASL) fuerza solicitudes firmadas y rechaza texto plano/sin SSL.

Configuración (según RAW): Group Policy Management Editor > Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Domain controller: LDAP server signing requirements > select Require signing from the dropdown

Pitfalls y mitigación:

• Puede romper clientes/apps antiguas. Antes de forzar:
  • inventariar qué aplicaciones consultan LDAP,
  • habilitar logging y detectar binds no firmados,
  • migrar a LDAPS / signing según corresponda.

6) Contraseñas: rotación, MFA y cuentas de servicio (gMSA)

El RAW describe tres enfoques:

1. Script de rotación (PowerShell + tarea programada): reduce trabajo manual pero introduce dependencia de scripting/mantenimiento.
2. MFA: añade capa adicional. El RAW referencia guía de MFA en Azure AD.
3. gMSA: rotación automática (p.ej., cada 30 días) para cuentas de servicio.

Buenas prácticas complementarias:

• Separar cuentas de usuario vs cuentas de administración (no reutilizar credenciales).
• En cuentas de servicio:
  • minimizar privilegios,
  • prohibir uso interactivo,
  • preferir gMSA cuando aplique.

7) Políticas de contraseña (Password Policy)

El RAW sugiere endurecimiento contra fuerza bruta/diccionario/password spraying:

• Ruta para configurar: Group Policy Management Editor > Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Password Policy
• Parámetros del RAW:
  • Historial: 10–15 contraseñas.
  • Longitud mínima: 10–14.
  • Complejidad: no contener el nombre de la cuenta + mayúsculas/minúsculas/dígitos/símbolos.

Notas prácticas (para que “funcione en la vida real”):

• No confundir “complejidad” con “seguridad”: longitudes mayores y políticas de contraseñas prohibidas suelen dar mejor resultado que reglas complejas que incentivan patrones.
• Si se aplica MFA para admins y se protege Tier 0, se puede reducir presión sobre rotación excesiva en algunos casos (pero hay que documentar riesgo y compensating controls).

8) Mínimos privilegios, RBAC y cuentas correctas (TAM)

Del RAW:

• Mínimos privilegios: limitar acceso a lo necesario; cuando se usa admin “para todo”, se amplía la superficie de ataque.
• Tipos de cuenta:
  • Usuarios: para trabajo diario.
  • Privilegiadas: elevadas (primer/segundo privilegio).
  • Compartidas: no recomendadas salvo casos muy acotados y con controles.

RBAC (control basado en roles) en AD suele implementarse con:

• Grupos por rol (p.ej., “DNS Admins”, “Server Operators” o grupos propios por función).
• Asignaciones a recursos con ACLs/GPO/delegación.

Tiered Access Model (TAM)

El RAW presenta TAM para evitar que credenciales privilegiadas crucen límites:

• Tier 0: DCs, admins de dominio, grupos críticos (identidades más valiosas).
• Tier 1: servidores y aplicaciones miembro del dominio.
• Tier 2: endpoints de usuarios finales.

Objetivo: “evitar que credenciales privilegiadas crucen los límites, accidental o intencionalmente”.

Controles típicos (alineados con el objetivo del RAW):

• Cuentas separadas por tier (al menos: usuario vs admin; idealmente admin por tier).
• Restringir logon/RDP de cuentas Tier 0 a sistemas Tier 0 (y usar estaciones/admin workstations dedicadas).
• GPOs por OU/tier para controlar “logon rights”, RDP, y restricciones de admin.

Referencia del modelo EAM/Tier (según RAW): https://docs.microsoft.com/en-us/security/compass/privileged-access-access-model

9) Auditoría de cuentas (uso, privilegios, cambios)

Del RAW:

• Auditoría de uso: qué tareas realiza cada cuenta y si es coherente.
• Auditoría de privilegios: si cumple mínimos privilegios.
• Auditoría de cambios: permisos/contraseñas/configuraciones.

Recomendación operativa: convertir esto en un ciclo recurrente con evidencia (reportes, tickets, owners).

10) Microsoft Security Compliance Toolkit (MSCT) + Policy Analyzer

Del RAW:

• MSCT provee baselines predefinidas y tooling para administrar políticas sin “pelearte con sintaxis”.
• Incluye Policy Analyzer para comparar GPOs y detectar inconsistencias/redundancias.
• Precaución explícita: descargar solo del sitio oficial.

Ruta del RAW (resumen):

• Descargar baseline (zip), extraer, ejecutar scripts con PowerShell.
• Usar PolicyAnalyzer.exe para comparar/gestionar políticas.

11) Protección contra ataques conocidos (enfoque defensivo)

El RAW recomienda pensar “como atacante” y referencia salas de THM:

• Zerologon, BreachingAD, ExploitingAD, PostExploit.

Controles defensivos mencionados o derivados del RAW (sin pasos ofensivos):

• Kerberoasting: minimizar el valor de tickets/secretos de cuentas de servicio (gMSA/rotación/MFA y hardening de cuentas de servicio) y monitorizar patrones anómalos.
• Contraseñas débiles: banned passwords, auditorías de contraseñas, MFA donde aplique.
• Brute force RDP: no exponer RDP a Internet; usar controles adicionales (MFA, VPN/RD Gateway, allowlists) y monitoreo.
• Public shares: inventario y restricción; auditar con PowerShell (Get-SmbOpenFile) y ajustar permisos.

Checklist recomendada: Active Directory Hardening Checklist

Ejemplos

Ejemplo 1 — “Paquete mínimo” de hardening para un DC (alto nivel)

1. Separar OUs: Tier0-DCs, Tier0-Admins, Tier1-Servers, Tier2-Workstations.
2. Aplicar GPOs por scope:
   • DCs: LDAP signing, auditoría reforzada, políticas de Kerberos, hardening SMB según compatibilidad.
   • Endpoints: limitar logon/RDP y reducir caché de credenciales donde aplique.
3. Activar un ciclo de auditoría: revisión mensual de grupos privilegiados + cambios de GPO.

Ejemplo 2 — Rotación de cuentas de servicio sin dolor (gMSA)

• Migrar cuentas de servicio “manuales” a gMSA cuando sea posible.
• Documentar dependencias (servicio/app), plan de rollback, y ventana de cambio.
• Establecer métricas: % de servicios en gMSA, % de cuentas “legacy” sin rotación.

Ejemplo 3 — Auditoría rápida de recursos compartidos (PowerShell)

El RAW menciona Get-SmbOpenFile para buscar acceso a recursos compartidos no deseados:

Get-SmbOpenFile

Guardar evidencia (output) en "90 Recursos"/ y abrir ticket si hay shares fuera de política.

Pitfalls

• Cambiar políticas sin inventario: LDAP signing/SMB signing pueden romper clientes legacy si se fuerzan sin análisis previo.
• “Admin para todo”: usar la misma cuenta admin para correo/navegación y administración eleva el riesgo (robo de token/credenciales).
• Password policy mal diseñada: demasiada complejidad puede incentivar patrones; validar con auditorías reales.
• No separar tiers: credenciales Tier 0 en endpoints Tier 2 es una receta para escalada rápida.
• Baselines sin pruebas: aplicar MSCT sin staging puede generar indisponibilidad; usar despliegue gradual y rollback.

Diagrama

Jerarquía lógica simplificada (Forest → Tree → Domain → OU → Objects)

flowchart TD
  F[Forest] --> T[Tree]
  T --> D[Domain]
  D --> OU[OU / Contenedor]
  OU --> U[User]
  OU --> C[Computer]
  D --> DC[Domain Controller]

Tiered Access Model (TAM) — idea de límites

flowchart TB
  subgraph T0["Tier 0 — Identidad (máximo valor)"]
    DCs[Domain Controllers]
    Admins[Admins / grupos críticos]
  end
  subgraph T1["Tier 1 — Servidores y apps"]
    Servers[Member servers]
    Apps[Aplicaciones]
  end
  subgraph T2["Tier 2 — Endpoints usuarios"]
    Endpoints[Workstations]
  end

  T0 -->|Administración controlada| T1
  T1 -->|Servicios/operación| T2

Referencias

1. TryHackMe — Zerologon: https://tryhackme.com/room/zer0logon
2. TryHackMe — Breaching AD: https://tryhackme.com/room/breachingad
3. TryHackMe — Exploiting AD: https://tryhackme.com/room/exploitingad
4. TryHackMe — Post-exploitation basics: https://tryhackme.com/room/postexploit
5. TryHackMe — Attacking Kerberos (Kerberoasting): https://tryhackme.com/room/attackingkerberos
6. Microsoft Security Blog (mitigación post‑explotación / AMSI / ML): https://microsoft.com/security/blog/2020/08/27/stopping-active-directory-attacks-and-other-post-exploitation-behavior-with-amsi-and-machine-learning/
7. Azure AD — Password ban / banned passwords: https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-password-ban-bad-combined-policy
8. Azure AD — MFA (getting started): https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-getstarted
9. gMSA (Group Managed Service Accounts): https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/service-accounts-group-managed
10. Principle of Least Privilege (Wikipedia): https://en.wikipedia.org/wiki/Principle_of_least_privilege
11. Microsoft — Privileged access (EAM/Tier model): https://docs.microsoft.com/en-us/security/compass/privileged-access-access-model
12. Microsoft — Security Compliance Toolkit (download): https://www.microsoft.com/en-us/download/details.aspx?id=55319