Microsoft AZ-801: Seguridad de Active Directory Domain Services — Guía de estudio

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

Forma parte de la Microsoft Windows Server Hybrid Administrator Associate AZ-801 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Microsoft, o realiza tests cronometrados en ExamRoll.io.

Información general

Active Directory Domain Services (AD DS) es la base de la identidad y el acceso en las redes Windows. Proteger AD DS implica controlar cómo se crean, almacenan y utilizan las credenciales; restringir dónde pueden autenticarse las identidades con privilegios; fortalecer los protocolos de autenticación; auditar acciones de alto valor; y garantizar una recuperación fiable. Esta sección cubre las directivas de contraseñas y cuentas detalladas, las protecciones de identidades con privilegios, el fortalecimiento y la delegación de la autenticación, la auditoría y las SACL, la Papelera de reciclaje, la firma LDAP y el enlace de canal, el comportamiento de AdminSDHolder, las copias de seguridad y las restauraciones autoritativas, incluida la recuperación de SYSVOL, y el modelo de niveles de AD.

Directivas de credenciales y controles de identidades con privilegios

Las directivas de contraseñas detalladas (PSO) permiten tener múltiples directivas de contraseña/bloqueo en un único dominio sin necesidad de dominios adicionales. Los PSO son objetos msDS-PasswordSettings almacenados en CN=Password Settings Container,CN=System,<domain DN> (el msDS-PasswordSettingsContainer). Un PSO se aplica a usuarios y grupos de seguridad globales a través de msDS-PSOAppliesTo. Cuando un usuario tiene múltiples PSO aplicables (directamente o a través de grupos), el PSO resultante es el que tiene el valor más bajo de msDS-PasswordSettingsPrecedence; si hay un empate, prevalece el PSO con el GUID más bajo. El PSO efectivo del usuario se registra en msDS-ResultantPSO. Diseñe los PSO de modo que los números de precedencia más bajos se correspondan con las directivas más restrictivas que se pretenda que prevalezcan, y valide las directivas efectivas leyendo msDS-ResultantPSO.

El grupo de seguridad Protected Users fortalece las cuentas de alto valor eliminando comportamientos de autenticación heredados y de riesgo. Sus miembros:

• No pueden usar NTLM, Digest o CredSSP
• Se les deniega RC4 y DES para Kerberos
• No pueden ser delegados a través de Kerberos (sin restricciones o con restricciones)
• Reciben TGT no renovables con una vida útil corta y fija (4 horas por defecto)
• No almacenan en caché credenciales de texto plano ni secretos a largo plazo en la estación de trabajo (evita el fallback a WDigest y que el material de credenciales permanezca en LSASS) Utilice este grupo para identidades con privilegios operadas por humanos y propietarios de servicios de alto riesgo después de validar la compatibilidad de las aplicaciones. Los controladores de dominio deben ejecutar Windows Server 2012 R2 o posterior para aplicar estas protecciones.

Las directivas de autenticación y los silos de directivas de autenticación restringen dónde y cómo pueden autenticarse las cuentas. Una directiva de autenticación puede establecer restricciones de Kerberos por cuenta, como la vida útil del TGT y los dispositivos permitidos (por SPN/FQDN del host). Un silo de directivas de autenticación agrupa usuarios, equipos y cuentas de servicio para que solo las combinaciones permitidas puedan autenticarse usando Kerberos restringido por esa directiva. Esto impone controles de «estación a administrador»: por ejemplo, los administradores de Nivel 0 solo pueden iniciar sesión en controladores de dominio y en estaciones de trabajo de acceso privilegiado (PAW) designadas, no en servidores miembro o estaciones de trabajo. Combínelo con Protected Users para obtener el máximo efecto. Estas características requieren DC con Windows Server 2012 R2 y blindaje del KDC (KDC armoring).

AdminSDHolder y SDProp protegen las ACL de las identidades con privilegios. Los miembros de los grupos de administradores integrados (por ejemplo, Domain Admins, Enterprise Admins, Schema Admins, Administrators, Account Operators, Server Operators, Backup Operators, Print Operators y otros) están «protegidos». SDProp se ejecuta cada hora en el emulador de PDC, copiando la ACL de CN=AdminSDHolder,CN=System a los objetos protegidos, y deshabilita la herencia de ACL en ellos (AdminCount=1). Para conceder derechos de soporte técnico (helpdesk) sobre objetos protegidos, modifique la ACL en AdminSDHolder —nunca directamente en objetos protegidos individuales— o el cambio se revertirá. Cuando una cuenta se elimina de todos los grupos protegidos, vuelva a habilitar la herencia de ACL y borre AdminCount para que las ACL y GPO a nivel de OU se apliquen de nuevo.

Adopte un modelo de niveles de AD para minimizar la exposición de credenciales. El Nivel 0 contiene los controladores de dominio, los sistemas de identidad (PKI, federación, PAM) y las cuentas de administrador que los gestionan. El Nivel 1 contiene las cargas de trabajo de servidor y sus administradores. El Nivel 2 contiene las estaciones de trabajo y sus administradores. Impida el inicio de sesión entre niveles, utilice PAW para la administración de Nivel 0/1 y aísle las credenciales utilizando características como Protected Users, silos de autenticación, Remote Credential Guard, Just-Enough Administration (JEA) y Windows LAPS/Windows LAPS para la rotación de contraseñas de administrador local.

Refuerzo de la autenticación y delegación

La firma y el channel binding de LDAP protegen contra ataques de retransmisión (relay) y de intermediario (man-in-the-middle). Configure los controladores de dominio para requerir la firma a través de una Política de Grupo (Group Policy): Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\“Domain controller: LDAP server signing requirements” = Require signing. Exija la firma del cliente donde sea factible: “Network security: LDAP client signing requirements” = Require signing. Para LDAPS, habilite el channel binding en los DC estableciendo LDAPEnforceChannelBinding en HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters a 1 (Habilitado, recomendado) o 2 (Siempre). Haga un inventario de los dispositivos y aplicaciones heredados; habilitar la firma o el channel binding puede romper los enlaces anónimos/simples o las pilas LDAP antiguas. Supervise el registro de eventos del Servicio de Directorio (Directory Service): 2886 (no se requiere firma), 2887 (resumen de enlaces simples sin firmar), 2888 (la firma sigue deshabilitada), 2889 (IP de clientes que realizan enlaces simples sin firmar cuando el registro de diagnóstico está habilitado). Implemente los cambios en modo “Advertir” (Warn) (channel binding=1) antes de forzar el modo “Siempre” (Always) (2).

La delegación de Kerberos controla cómo los servicios actúan en nombre de los usuarios:

• La delegación sin restricciones (“Trust this computer for delegation to any service (Kerberos only)”) permite que un servicio reciba un TGT reenviable e suplante a los usuarios ante cualquier servicio. Esto es de alto riesgo; evítela en favor de los modelos restringidos.
• La delegación restringida (KCD) (“Trust this computer for delegation to specified services only”) limita a dónde puede delegar un servicio (lista de SPN de destino). Con “Use any authentication protocol”, el servicio puede usar la transición de protocolo (S4U2Self) y luego S4U2Proxy para alcanzar los backends especificados.
• La delegación restringida basada en recursos (RBCD) traslada el control al recurso estableciendo msDS-AllowedToActOnBehalfOfOtherIdentity en la cuenta de servicio de destino. El propietario del recurso concede qué principales (principals) de front-end pueden delegar en él, lo que simplifica los escenarios entre dominios y minimiza la superficie de ataque. Prefiera RBCD para diseños modernos; audite y verifique periódicamente los SPN y la configuración de delegación.

Auditoría y resiliencia

La auditoría de AD DS debe ser deliberada y específica. Use la Configuración de directivas de auditoría avanzada (Advanced Audit Policy Configuration) para habilitar subcategorías en lugar de las categorías heredadas, y establezca “Audit: Force audit policy subcategory settings to override audit policy category settings” para garantizar la coherencia. Las subcategorías recomendadas incluyen Administración de cuentas (Account Management), Inicio/Cierre de sesión (Logon/Logoff) (Logon, Logoff, Special Logon), Inicio de sesión de cuenta (Account Logon) (Kerberos Authentication Service/Service Ticket Operations) y Cambios/Acceso al servicio de directorio (Directory Service Changes/Access). ID de eventos clave:

• 4720 (Se creó una cuenta de usuario) de Administración de cuentas (Account Management)
• 4740 (Se bloqueó una cuenta de usuario) de Administración de cuentas (Account Management)
• 4625 (Error al iniciar sesión en una cuenta) de Inicio/Cierre de sesión (Logon/Logoff)
• 4648 (Se intentó un inicio de sesión con credenciales explícitas) de Inicio/Cierre de sesión (Logon/Logoff) Auméntela con Cambios en el servicio de directorio (Directory Service Changes) para capturar los valores de quién/qué/antiguo/nuevo para atributos críticos (eventos 5136/5137/5139). Para auditar cambios específicos (p. ej., pertenencia a grupos, SPN, ACL), configure las SACL en los objetos o unidades organizativas (OU) de destino (habilite las Características avanzadas (Advanced Features) en ADUC, abra el objeto Seguridad > Avanzadas > Auditoría). Agregue entradas para auditar “Escribir todas las propiedades” (Write all properties) o propiedades específicas (member, servicePrincipalName), y “Modificar permisos/propietario” (Modify permissions/owner) según sea necesario. Valide que los registros lleguen a un SIEM central y que los registros de seguridad del DC tengan una retención suficiente.

La Papelera de reciclaje de AD DS protege contra eliminaciones accidentales al preservar todos los atributos y backlinks de los objetos eliminados. Habilítela una vez por bosque (irreversible) a través de ADAC o PowerShell (Enable-ADOptionalFeature -Identity ‘Recycle Bin Feature’ -Scope ForestOrConfigurationSet -Target <forest>). Después de habilitarla, un objeto eliminado permanece en un estado de “objeto eliminado” durante el tiempo de vida de msDS-DeletedObjectLifetime (si no se establece, el valor predeterminado es tombstoneLifetime), durante el cual se puede restaurar por completo con sus atributos intactos. Después de eso, se convierte en un objeto reciclado y ya no se puede restaurar con sus atributos; más tarde es recolectado por el proceso de recolección de elementos no utilizados (garbage collection). Los bosques modernos suelen tener un tombstoneLifetime predeterminado de 180 días; los bosques más antiguos pueden tenerlo de 60. Restaure con ADAC, LDP o PowerShell (Restore-ADObject), y prefiera la recuperación autoritativa de la pertenencia a grupos a través de la Papelera de reciclaje en lugar de volver a agregarlos manualmente para evitar la desviación de privilegios (privilege drift).

Las copias de seguridad y la restauración autoritativa son las últimas líneas de protección. Realice copias de seguridad frecuentes del estado del sistema (System State) de cada controlador de dominio utilizando Windows Server Backup o wbadmin (wbadmin start systemstatebackup). Para reversiones a nivel de objeto que van más allá de la Papelera de reciclaje, realice una restauración no autoritativa del estado del sistema (System State) y luego use ntdsutil para marcar objetos o unidades organizativas (OU) específicas como autoritativas (aumentando su versión para que la replicación las vuelva a aplicar). Comprenda la diferencia: la restauración no autoritativa recupera el DC y luego aplica la replicación actual; la autoritativa marca un objeto para que la versión restaurada sobrescriba las réplicas más nuevas. Para SYSVOL usando la Replicación DFS (DFSR), realice una recuperación no autoritativa o autoritativa:

• No autoritativa: Detenga el servicio DFSR, establezca la suscripción de SYSVOL del miembro afectado como no autoritativa (msDFSR-Options=0), inicie DFSR para que se rehidrate desde un socio ascendente (upstream partner).
• Autoritativa: En el DC bueno elegido, establezca la suscripción de SYSVOL como autoritativa con msDFSR-Options=1, inicie DFSR y luego fuerce a los socios a resincronizarse (DFSRDIAG PollAD). Valide el estado con dfsrdiag backlog y los registros de eventos. Para el FRS heredado (no compatible), migre a DFSR y evite los procedimientos de BurFlags.

Poniéndolo todo en práctica: Operaciones, prioridades de fortalecimiento y acceso por niveles

Priorice primero el Tier 0: aplique la firma y el enlace de canal de LDAP, elimine la delegación no restringida, migre a KCD/RBCD, coloque las identidades privilegiadas en el grupo Protected Users y adjunte directivas/silos de autenticación para restringir los puntos de conexión de inicio de sesión, y exija el uso de PAW para los administradores de Tier 0/1. Establezca PSOs para las cuentas privilegiadas con políticas estrictas de bloqueo y rotación. Active la auditoría avanzada con SACL en los contenedores del Tier 0. Asegure copias de seguridad diarias del estado del sistema de los DC y tenga documentadas guías de ejecución (runbooks) para la restauración autoritativa y la recuperación de SYSVOL. En los Tier 1/2, bloquee el inicio de sesión de administradores en niveles inferiores, elimine la reutilización de administradores locales con Windows LAPS y monitorice los picos en los eventos 4625/4740 y el uso indebido del 4648 para detectar intentos de movimiento lateral.

Escenario de problema práctico

Adobe debe asegurar un bosque de AD DS on-premises rápidamente después de adquirir una filial cuyas aplicaciones de negocio (LOB) dependen de protocolos heredados. Los objetivos son reducir el éxito de los ataques de pulverización de contraseñas (password spraying), detener el relay de credenciales hacia los DC, restringir los inicios de sesión privilegiados a las PAW, modernizar la delegación para un nivel web y garantizar una recuperación rápida de eliminaciones accidentales.

1. Definir PSOs y asignarlos a grupos privilegiados

• Crear un PSO estricto (valor de precedencia bajo) en msDS-PasswordSettingsContainer con una antigüedad de contraseña corta, alta complejidad y un bloqueo agresivo.
• Aplicarlo mediante msDS-PSOAppliesTo a los grupos “Domain Admins”, “Server Admins” y un grupo personalizado “Tier0‑Privs”. Por qué: Los PSOs de grano fino se dirigen solo a las cuentas de alto riesgo sin afectar a todo el dominio, y la precedencia garantiza que la directiva estricta prevalezca.

2. Aplicar Protected Users y silos de autenticación

• Añadir los administradores humanos del Tier 0 al grupo Protected Users.
• Crear una directiva de autenticación que permita el inicio de sesión con Kerberos solo desde los SPN de los hosts PAW y los DC; vincular cuentas y PAW en un silo de directivas de autenticación. Por qué: El grupo Protected Users elimina NTLM/RC4 y previene la delegación; los silos imponen la regla de «solo desde PAW», reduciendo la exposición de tokens y las rutas de robo de credenciales.

3. Fortalecer LDAP y monitorizar posibles fallos

• Establecer «Controlador de dominio: requisitos de firma del servidor LDAP» en Requerir; configurar LDAPEnforceChannelBinding=1 inicialmente.
• Revisar los eventos 2886–2889 del Servicio de Directorio para identificar enlaces heredados; remediar las aplicaciones y luego establecer LDAPEnforceChannelBinding=2. Por qué: La firma y el enlace de canal eliminan rutas comunes de relay hacia los DC, mientras que la aplicación por fases evita interrupciones del servicio.

4. Migrar la delegación a RBCD para el nivel web

• Convertir los servidores web de front-end de delegación no restringida a RBCD añadiendo sus cuentas de equipo al atributo msDS-AllowedToActOnBehalfOfOtherIdentity de la cuenta de servicio de la API de back-end.
• Eliminar los indicadores heredados de «Confiar en este equipo para la delegación a cualquier servicio»; definir los SPN de servicio con precisión. Por qué: RBCD permite que el recurso dicte quién puede delegar en él y limita la suplantación a los objetivos previstos, reduciendo el movimiento lateral.

5. Habilitar la auditoría avanzada y las SACL

• Configurar la Directiva de auditoría avanzada para la Administración de cuentas, Inicio/cierre de sesión, Inicio de sesión de cuenta y Cambios en el servicio de directorio.
• En las OU del Tier 0 y grupos clave, añadir SACL que auditen la escritura en los atributos member y servicePrincipalName, y los cambios de permisos/propietario.
• Reenviar los registros a un SIEM; alertar sobre anomalías en los eventos 4720, 4740, 4625 y 4648. Por qué: No se puede defender lo que no se puede ver; estos eventos exponen la creación de cuentas, los bloqueos, los inicios de sesión fallidos y los patrones de uso explícito de credenciales.

6. Activar la Papelera de reciclaje de AD DS y finalizar las guías de recuperación

• Habilitar la Papelera de reciclaje a nivel de bosque y documentar los flujos de trabajo de Restore-ADObject.
• Estandarizar las copias de seguridad diarias del estado del sistema de los DC con Windows Server Backup, probar la restauración autoritativa mediante ntdsutil en un laboratorio.
• Documentar y ensayar la recuperación autoritativa y no autoritativa de DFSR SYSVOL. Por qué: Una recuperación rápida y precisa disuade las acciones destructivas de los atacantes y mitiga los errores de los administradores sin desviación de privilegios (privilege drift).

7. Implementar el modelo de niveles de AD de forma operativa

• Definir los activos de los Tier 0/1/2; restringir los inicios de sesión de administrador por nivel usando Directivas de Grupo y silos de autenticación.
• Desplegar PAW para los Tier 0/1, aplicar Remote Credential Guard y rotar las contraseñas de administrador local con Windows LAPS. Por qué: El modelo de niveles garantiza el aislamiento de credenciales y detiene la escalada de un atacante a través de las capas, alineando las operaciones diarias con los límites de seguridad.

← Microsoft Sentinel y monitoreo de seguridad · Todos los dominios · Azure Arc y gestión de servidores híbridos →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →

Explorar Microsoft →