Qué significa validar copias de seguridad de Active Directory para recuperar un bosque
La validación de copias de seguridad de Active Directory para recuperar un bosque plantea dos preguntas: ¿se puede restaurar la copia y puede la organización justificar su confianza en el bosque recuperado a partir de ella? Una restauración correcta responde a la primera. La segunda requiere un punto de recuperación investigado, un procedimiento ensayado y pruebas de que el directorio restaurado cumple los criterios de recuperación.
La guía de recuperación de bosques Active Directory de Microsoft ofrece una plantilla que debe adaptarse al entorno. Sus recomendaciones para evaluar el incidente excluyen expresamente las recomendaciones de seguridad completas para recuperar un bosque atacado o comprometido. Utilice el procedimiento de recuperación junto con el trabajo de respuesta al incidente necesario para establecer la confianza.
Aquí, recuperación validada significa un ejercicio o una recuperación documentados, con controles de aceptación registrados y límites expresamente indicados. Es una definición editorial, no una certificación de Microsoft. «El DC arrancó» y «la replicación funciona» son observaciones útiles, pero ninguna demuestra que el estado de directorio seleccionado sea seguro.
| Pregunta | Pruebas que solicitar | Qué queda sin resolver |
|---|---|---|
| ¿Se puede restaurar la copia? | El resultado de una restauración real de la copia y la vía de recuperación seleccionadas | Si el estado restaurado es fiable |
| ¿Se puede repetir la recuperación? | Un procedimiento actualizado y un registro de ensayo fechado | Si el siguiente incidente tendrá el mismo alcance |
| ¿Se puede justificar el punto de recuperación? | Una cronología del incidente y las razones para aceptar esa copia | Los cambios maliciosos que la investigación no cubre |
| ¿Está listo el bosque recuperado? | Controles operativos registrados y decisiones de revisión de seguridad | Dependencias o persistencia fuera de esos controles |
Trate el tiempo de recuperación como otro resultado que debe registrarse. Un ejercicio rápido con credenciales desconocidas, datos sin revisar o fallos de validación sin resolver no debe describirse como una recuperación validada.
Elegir un estado fiable antes de restaurar
Las recomendaciones de Microsoft para seleccionar copias advierten de que una copia más reciente puede reintroducir datos peligrosos. Si se desconoce el momento del fallo, investigue el último estado seguro. La recuperación pierde los objetos, las actualizaciones y los cambios de configuración o de esquema posteriores.
La misma página recomienda realizar periódicamente copias de al menos dos DC con capacidad de escritura por dominio. Exige credenciales Domain Admin para cada dominio y la contraseña DSRM. Una copia de un RODC no puede restaurar un DC con capacidad de escritura; no se admite restaurar el estado del sistema sobre una instalación nueva de Windows. Planifique la vía adecuada de recuperación completa del servidor. Dsamain y un explorador LDAP como Ldp pueden ayudar a inspeccionar los datos de directorio de la copia.
Con la papelera de reciclaje habilitada, la validez de la copia está limitada por el menor valor entre deletedObjectLifetime y tombstoneLifetime. Estas condiciones hacen que «tenemos un archivo reciente» sea un argumento incompleto para la recuperación.
Para decidir la recuperación, registre la copia elegida, el dominio al que corresponde, por qué su estado resulta aceptable y qué cambios se perderán. Si la investigación no permite respaldar un punto fiable, registre esa incertidumbre en lugar de etiquetar como limpia la copia más reciente.
Las afirmaciones sobre persistencia deben seguir siendo condicionales
La inferencia relativa a la recuperación es condicional: si un cambio malicioso del directorio está presente en la copia seleccionada y forma parte del estado restaurado, restaurar ese estado puede reintroducir el cambio. Es una deducción del comportamiento documentado de retorno a un estado anterior, no una afirmación de Microsoft de que toda puerta trasera regrese necesariamente intacta.
Esta distinción importa para las ACL y AdminSDHolder. Nuestro artículo sobre AdminSDHolder y SDProp explica la persistencia mediante una plantilla de ACL modificada y por qué corregir solo la ACL de un objeto protegido puede dejar sin resolver el problema de la plantilla. Para la recuperación, compruebe si la plantilla guardada y los permisos pertinentes coinciden con una referencia aceptada. Las páginas de Forest Recovery citadas aquí no describen expresamente la restauración de una puerta trasera AdminSDHolder.
La documentación de Microsoft sobre plantillas de certificados indica que las plantillas de las CA empresariales residen en AD DS. Distingue entre modificar una plantilla, habilitar la emisión en una CA y publicar un certificado emitido. Por tanto, una plantilla modificada incluida en el estado de directorio restaurado podría reaparecer: es una inferencia condicional. No establece el estado restaurado de cada CA, certificado emitido o secreto PKI. Defina por separado la revisión complementaria de PKI.
Nuestro artículo sobre Golden Ticket describe el riesgo de persistencia asociado a un secreto krbtgt comprometido. Las instrucciones de recuperación y los intervalos de restablecimiento que aparecen a continuación proceden de Microsoft Learn. El enlace explica por qué importa el secreto; no es la fuente de autoridad de este procedimiento de recuperación.
Seguir la secuencia de recuperación con puntos de validación
Los requisitos previos de Microsoft presuponen que la causa y las posibles soluciones se han evaluado con el soporte de Microsoft y que la restauración del bosque es la solución elegida, a menudo como último recurso. También exigen un plan documentado y probado en un laboratorio con copias de producción.
Prepare esa decisión antes de iniciar pasos destructivos de recuperación. Registre el alcance del incidente, las credenciales de recuperación, la información de acceso de emergencia y las copias seleccionadas. El procedimiento debe dejar clara la siguiente decisión incluso cuando los servicios habituales de directorio no estén disponibles.
Lo siguiente es una visión general de la secuencia de recuperación inicial de Microsoft, no un sustituto ejecutable del procedimiento completo:
- Restaurar de forma aislada. Empiece por un DC con capacidad de escritura del dominio raíz del bosque y recupere después los demás dominios, primero los padres y luego los hijos.
- Usar el modo de restauración correcto para el primer DC restaurado de cada dominio. Restaure AD DS de forma no autoritativa y SYSVOL de forma autoritativa, siguiendo el método documentado. Los DC posteriores del dominio deben resincronizar SYSVOL desde la copia autoritativa.
- Verificar los datos restaurados antes de conectar a producción. Complete los pasos documentados de FSMO, metadatos, DNS, RID, contraseñas de cuentas y hora. Una sospecha de intrusión exige restablecer las contraseñas administrativas y sustituir todas las contraseñas gMSA. Una sospecha de compromiso de cuentas de usuario también exige planificar el restablecimiento de contraseñas de todos los usuarios del dominio.
- Validar conjuntamente los DC recuperados. Utilice una red aislada común antes de la transición a producción.
- Crear copias de los DC restaurados antes de volver a desplegar los DC restantes.
La página también documenta estos controles operativos en su sección de estado de la replicación del bosque, después de la transición a la red de producción:
repadmin /replsum
DCDiag /v
Evalúan la replicación y el estado de los DC y de DNS. Un resultado correcto no certifica la ausencia de persistencia. Mantenga diferenciadas las pruebas operativas y las conclusiones de la revisión de seguridad en el registro de recuperación.
Restablecer krbtgt dos veces con el intervalo documentado
El procedimiento de Microsoft para restablecer krbtgt se aplica a los DC con capacidad de escritura, no a los RODC. En Usuarios y equipos de Active Directory, habilite Características avanzadas, abra el contenedor Users del dominio y use Restablecer contraseña sobre krbtgt.
Realice la operación dos veces. La cuenta conserva las dos contraseñas más recientes; dos restablecimientos eliminan la contraseña antigua de ese historial. Learn exige 10 horas entre restablecimientos con las duraciones máximas predeterminadas de los tickets de usuario y de servicio. Si se modifica la duración máxima, el periodo de espera debe superar el valor configurado. No suponga que el primer restablecimiento invalida universalmente todos los tickets falsificados.
Para una recuperación que incluya RODC, Learn indica que no se deben eliminar sus cuentas krbtgt_number. No les aplique el procedimiento de los DC con capacidad de escritura.
Detección: medir la antigüedad de las copias y las pruebas ausentes
El éxito de una tarea de copia, una marca de tiempo del directorio y un ejercicio de restauración describen pruebas diferentes. Revise cada una según lo que realmente demuestra.
Las recomendaciones de Microsoft sobre latencia de las copias documentan:
Repadmin.exe /showbackup
Recopile las fechas de copia indicadas para los DC y los contextos de nombres de destino, y registre el alcance real del comando. Repadmin necesita credenciales administrativas en cada DC de destino. Microsoft explica que las copias realizadas con las API estándar de copia de seguridad escriben la marca de tiempo; una copia a nivel de archivo de la base de datos AD no aporta esa protección.
Investigue cuando las copias tengan una antigüedad superior a la mitad de la duración de los objetos tombstone del bosque. Learn indica que las copias más antiguas que esa duración son inválidas y recomienda al menos copias diarias en casi todos los escenarios. Lea los valores reales de duración del bosque. No los sustituya por un valor universal de 180 días ni por el umbral independiente de 60 días del colector.
Una marca de tiempo reciente sigue sin demostrar la integridad del soporte ni una restauración correcta.
| Señal que investigar | Pruebas que recopilar | Siguiente decisión |
|---|---|---|
| Información de copia ausente o antigua | Resultados de /showbackup con su alcance, historial de tareas e inventario de copias disponibles | Corregir la cobertura ausente o las tareas fallidas |
| Ningún ejercicio de restauración registrado | Fecha del último ensayo, identificadores de las copias y resultados de los controles | Programar un ejercicio con copias de producción |
| Punto de recuperación incierto | Cronología del incidente y revisión del estado candidato guardado en las copias | Establecer el último punto fiable o conservar la incertidumbre |
| Papelera de reciclaje no disponible o de estado desconocido | Estado real de la función y revisión de requisitos previos | Planificar su habilitación antes de futuras eliminaciones |
| Fallos en los controles de recuperación | Resultados de diagnóstico guardados y desviaciones del procedimiento | Resolver el fallo antes de aceptar la recuperación |
Son propuestas de investigación, no observaciones de un entorno de cliente. Solicite los artefactos que respaldan «probado» o «recuperable»: ¿qué copia, qué dominio, qué revisión del procedimiento y qué controles superados?
Remediación: documentar, ensayar y preparar la recuperación de objetos (Remediation)
1. Adaptar el procedimiento al bosque
Las recomendaciones de planificación de Microsoft exigen un mapa de topología que abarque DC, roles, estado de las copias y relaciones de confianza. Recomiendan practicar la recuperación del bosque al menos anualmente y sugieren también ejercicios cuando cambia la composición de Domain Admins o Enterprise Admins.
Convierta el mapa en un registro de decisiones utilizable: identifique el DC de recuperación de cada dominio, los criterios para seleccionar copias, los accesos necesarios y los puntos de validación. Asigne responsables para mantener esos datos actualizados. Una laguna sin explicar debe seguir visible en lugar de ocultarse tras una lista de comprobación completada.
2. Repetir la restauración y conservar los resultados
Los requisitos previos exigen copias y restauraciones periódicas de AD DS y SYSVOL en laboratorio, revisiones rutinarias del procedimiento y actualizaciones tras cambios de sistema operativo o arquitectura. Ensaye la vía real de recuperación con copias de producción.
Un registro de ensayo útil identifica la revisión del procedimiento, las copias seleccionadas, los operadores, los controles realizados, sus resultados y las desviaciones. Incluya el tiempo transcurrido, pero indique también qué validó el ejercicio y qué no. Si una copia arranca correctamente pero falla la revisión de los datos, conserve ambos resultados. Si un acceso necesario no estaba disponible, regístrelo como una dependencia de recuperación que debe corregirse.
Separe «se ejecutó el procedimiento» de «se cumplieron los criterios de aceptación». Repetir un procedimiento sin examinar sus resultados no resuelve la cuestión de la confianza.
3. Habilitar la papelera de reciclaje antes de necesitarla
Las recomendaciones de Microsoft sobre la papelera de reciclaje indican que la función está deshabilitada por defecto y que su activación es irreversible. Conserva los atributos y vínculos de los objetos eliminados, incluidas las pertenencias a grupos. Solo puede recuperar objetos eliminados después de habilitarla.
Compruebe los requisitos previos documentados: niveles funcionales de bosque y dominio de Windows Server 2008 R2 o superiores, los permisos administrativos indicados y ADAC o el módulo PowerShell de Active Directory.
Para la vía ADAC documentada, seleccione el dominio de destino adecuado, elija Habilitar papelera de reciclaje en el panel Tareas, confirme los mensajes y actualice ADAC. Después de una eliminación de prueba controlada, use el contenedor Objetos eliminados para restaurar el objeto seleccionado y verificar su ubicación.
Registre la decisión de habilitación y una prueba controlada de restauración de objetos. La papelera resuelve la recuperación de objetos; no valida un bosque comprometido. Mantenga esa prueba separada del ejercicio de restauración del bosque.
4. Cerrar las lagunas de prueba antes de declarar validada la recuperación
Utilice un breve registro de aceptación que conecte cada conclusión con pruebas. «Copia disponible» debe nombrar la copia. «Recuperación ensayada» debe identificar el ejercicio. «Estado fiable» debe identificar la investigación y la revisión de la referencia. «Controles operativos superados» debe identificar los resultados registrados.
Si el incidente exige trabajo adicional de seguridad o PKI, nombre la tarea pendiente y su responsable. No permita que un control de replicación correcto se convierta silenciosamente en la aprobación de todo lo que queda fuera de su alcance.
Cómo EtcSec detecta estas señales
El colector proporciona tres controles activos pertinentes para este tema. Identifican señales de configuración o de revisión; no prueban que el bosque pueda recuperarse.
| Control activo | Predicado real | Límite |
|---|---|---|
HDS_5_8_DR_PLAN_MISSING | Menos de 2 DC inventariados produce Count 1 | Una heurística basada en el número de DC. No lee procedimientos, copias ni ensayos. Dos DC ubicados juntos sin un plan pueden pasar; un despliegue de un solo DC bien planificado puede fallar. |
DC_BACKUP_OLD | La ausencia de DomainInfo o LastADBackupDate produce Count 1; en caso contrario, más de 60 días completos produce Count 1 | El proveedor rellena el campo con el máximo whenChanged entre los objetos nTDSDSA. Es un indicador indirecto de metadatos NTDS a nivel de recopilación, no la antigüedad de las copias por DC. Los cambios de topología pueden hacer que parezca reciente. Exactamente 60 días completos no lo activan. |
RECYCLE_BIN_DISABLED | RecycleBinEnabled=false produce Count 1; true produce Count 0 | Si falta DomainInfo, el resultado es desconocido con Count 0. Eso no prueba que la función esté habilitada. |
El identificador HDS no establece un requisito HDS numerado específico ni demuestra que falte un plan de recuperación. Utilícelo para motivar una revisión humana de la topología y de la planificación de recuperación.
El colector no mide BACKUP_AD_NOT_VERIFIED. Su detector retirado no devuelve hallazgos y no está registrado. Se excluye de las etiquetas de vulnerabilidad de este artículo. Verificar la restauración exige pruebas operativas externas a estos controles del directorio.
Explore las páginas de identidad que apoyan este tema