Revisar los metadatos del descriptor de seguridad del esquema AD

Qué indican los metadatos del descriptor de seguridad del esquema AD

Los metadatos del descriptor de seguridad del esquema AD ayudan a determinar cuándo cambió por última vez el descriptor de seguridad de la raíz del contexto de nombres del esquema. Una marca de tiempo reciente justifica recopilar pruebas y revisar el cambio. No demuestra que un permiso se haya vuelto peligroso, que un administrador haya actuado sin autorización ni que el bosque haya sido comprometido.

Esta guía examina nTSecurityDescriptor en el objeto exacto devuelto como schemaNamingContext. No examina defaultSecurityDescriptor en las clases individuales del esquema. Mantenga esa distinción en el registro de la investigación: un cambio en el descriptor del objeto raíz y un cambio en el descriptor predeterminado de una clase son objetivos de revisión distintos.

Microsoft describe msDS-ReplAttributeMetaData como metadatos mantenidos por el sistema para atributos replicados. Trate esa información como procedencia de la replicación. El servidor de directorio de origen no es la cuenta humana o de servicio que solicitó una escritura. Identificar la cuenta solicitante requiere pruebas independientes.

El resultado práctico es una ficha de evaluación: qué objeto se consultó, qué controlador de dominio respondió, qué metadatos se devolvieron, si la marca de tiempo es utilizable y si una referencia aprobada explica los permisos actuales. Este es un proceso de investigación, contrastado con la documentación de Microsoft el 4 de octubre de 2026; ninguno de los comandos presentados aquí se ejecutó en un directorio de cliente.

Detección: identificar el objeto antes de consultar los metadatos

Paso 1: resolver el contexto de nombres del esquema en el DC elegido

Utilice una estación administrativa Windows con el módulo PowerShell ActiveDirectory y una cuenta autorizada para leer los datos de directorio pertinentes. Sustituya el servidor del ejemplo por un DC concreto de su bosque. Mantenga el mismo servidor para el descubrimiento y la primera consulta de metadatos.

El siguiente ejemplo usa el parámetro documentado -Server de Get-ADRootDSE. Su salida incluye schemaNamingContext, defaultNamingContext, el nombre de host del servidor y la hora actual.

$dc = 'dc01.example.com'
$root = Get-ADRootDSE -Server $dc -ErrorAction Stop
$root | Format-List dnsHostName, defaultNamingContext, schemaNamingContext, currentTime
$schemaDN = [string]$root.schemaNamingContext
if ([string]::IsNullOrWhiteSpace($schemaDN)) {
    throw 'Schema naming context was not returned; stop qualification.'
}

Registre el DN devuelto exactamente. Compárelo con el DN del objeto utilizado por su herramienta de auditoría. En el contexto de un dominio secundario, compruebe específicamente si un DN construido a partir del DN del dominio actual coincide con RootDSE. Una discrepancia es una cuestión de recopilación que debe resolverse antes de interpretar el hallazgo; no es una prueba de que el descriptor haya cambiado.

Paso 2: obtener los metadatos de replicación del atributo

Get-ADReplicationAttributeMetadata acepta un nombre distinguido mediante -Object, un DC mediante -Server y nombres de atributos mediante -Properties. Este ejemplo limita la solicitud a nTSecurityDescriptor y muestra todos los metadatos devueltos, sin ocultar campos en una tabla abreviada.

$metadata = @(Get-ADReplicationAttributeMetadata -Object $schemaDN -Server $dc -Properties nTSecurityDescriptor -ErrorAction Stop)
if ($metadata.Count -eq 0) {
    throw 'No metadata was returned; record insufficient evidence.'
}
$metadata | Format-List *

Conserve la salida, incluidos el nombre del atributo, la versión, la hora del último cambio de origen y la identidad del servidor de directorio de origen. Distinga el DC consultado del servidor identificado como origen del cambio. Mantenga cualquier identidad no resuelta tal como se devolvió; no la sustituya por un nombre de administrador supuesto.

Paso 3: evaluar la marca de tiempo y la ventana de observación

Registre la hora y la zona horaria de recopilación junto con la marca de tiempo original. Confirme que la fecha está presente y se interpreta correctamente antes de aplicar una ventana. Para reproducir la decisión de la auditoría, utilice su hora de referencia registrada, sin sustituirla silenciosamente por la hora actual durante una investigación posterior.

Si repite la consulta en otro DC, repita también allí el descubrimiento RootDSE y guarde un registro de recopilación independiente. No combine dos observaciones en un historial inventado. La marca de tiempo del último cambio no permite reconstruir todos los estados anteriores del descriptor ni todas las modificaciones del período revisado.

Remediación: evaluar primero, corregir la desviación confirmada (Remediation)

Paso 1: comparar el descriptor actual con una referencia aprobada

Obtenga el descriptor actual de la raíz exacta del esquema y compárelo con una referencia fechada y aprobada para ese mismo objeto. Para consultar los permisos en el DC seleccionado, el siguiente comando usa la sintaxis de objetos remotos documentada por Microsoft para Dsacls. Ejecútelo desde un shell Windows elevado, con Dsacls instalado y acceso de lectura al objeto de destino. Sin opciones de modificación, muestra la ACL.

dsacls "\\$dc\$schemaDN"

Conserve la salida del comando e informe de cualquier fallo. La visualización de una ACL permite revisar los permisos; conserve una exportación completa del descriptor mediante sus herramientas de directorio aprobadas si la investigación también necesita información del propietario, del grupo o de auditoría. Identifique exactamente qué componentes se capturaron, para que una vista parcial no se presente como una comparación completa del descriptor.

Revise los destinatarios modificados, los derechos, los GUID específicos de objetos, la herencia y el alcance. Determine si cada diferencia pertenece a la propia raíz o a otro objeto. La revisión de permisos del esquema aporta contexto relacionado con los permisos; esta comprobación temporal no demuestra un cambio en defaultSecurityDescriptor de una clase.

Si no existe una referencia aprobada, registre esa limitación. El descriptor actual aún puede revisarse frente a la delegación prevista por la organización, pero no se dispone de una comparación histórica exacta. No fabrique un estado anterior a partir de la marca de tiempo ni trate un valor predeterminado genérico como la referencia aprobada de su bosque.

Paso 2: correlacionar la autorización y los eventos disponibles

Contraste las pruebas con un ticket de cambio real: DN de destino, permisos esperados, equipo responsable, ventana de ejecución aprobada y estado resultante. Un ticket que mencione un despliegue relacionado con el esquema no basta por sí solo; compruebe que el cambio previsto explica el objeto observado y la diferencia del descriptor.

Microsoft documenta el evento de seguridad 5136 para modificaciones de objetos de directorio bajo Audit Directory Service Changes. Su generación exige una entrada de auditoría apropiada para escrituras de atributos en la SACL del objeto. Cuando existan eventos, compruebe ObjectDN y AttributeLDAPDisplayName, conserve los campos de la cuenta Subject y correlacione las operaciones coincidentes mediante OpCorrelationID. Microsoft describe registros típicos Value Deleted y Value Added, pero verifique los valores realmente disponibles en sus pruebas.

Utilice la guía de supervisión AD para la recopilación y correlación de eventos para revisar el sistema de supervisión circundante. Determine si la auditoría, el reenvío y la retención cubrían el DC y el período pertinentes antes de interpretar una búsqueda vacía. Una cuenta Subject identifica al principal solicitante en el evento; cualquier atribución a una persona concreta sigue necesitando registros operativos de respaldo.

Paso 3: elegir una conclusión defendible

Una marca de tiempo sin explicación, por sí sola, pertenece a la tercera rama. Una desviación de permisos confirmada puede justificar una remediación sin determinar quién la causó. Explicite la cuestión de la autorización y la evaluación de la exposición actual, para que la respuesta no dependa de una atribución sin respaldo.

Paso 4: corregir únicamente la desviación confirmada del descriptor

Pida al equipo de directorio autorizado que prepare un cambio sobre el DN verificado de la raíz del esquema. Guarde el descriptor actual, identifique la ACE o el componente exacto que debe corregirse, documente el resultado previsto y disponga una vía de recuperación antes de escribir. Aplique el cambio revisado mediante su editor de ACL aprobado, preservando la delegación legítima y los permisos necesarios.

Evite usar un restablecimiento general para descartar una marca de tiempo reciente. La referencia Dsacls de Microsoft describe /S como la restauración de los valores predeterminados de la clase y /R como la eliminación de todas las ACE de un principal especificado; ninguna de las dos opciones sustituye una corrección específica respaldada por su comparación aprobada.

Después de la corrección, repita las lecturas RootDSE, de metadatos y de permisos. Verifique que el estado previsto del descriptor está presente y que las operaciones de directorio necesarias siguen funcionando. Registre los nuevos metadatos y cualquier prueba de auditoría recopilada como un nuevo cambio autorizado. Un hallazgo de cambio reciente puede seguir siendo positivo después de una corrección legítima, porque la propia corrección es reciente; valide los permisos, no solo la desaparición de la señal temporal.

Cómo detecta EtcSec este caso

En la implementación revisada de etc-collector, SCHEMA_SD_RECENT_CHANGE produce un hallazgo Info con Count 1 cuando SchemaSDLastChanged no es cero y es estrictamente posterior a data.Now.AddDate(0, 0, -90). El umbral utiliza una resta de días naturales. El límite exacto queda excluido y no hay un límite superior en Now: una fecha futura también supera la prueba. En caso contrario, el hallazgo devuelto tiene Count 0.

El motor construye CN=Schema,CN=Configuration, seguido de DomainInfo.DomainDN, solicita metadatos de replicación y copia la hora de cambio de nTSecurityDescriptor. Compare ese DN construido con el schemaNamingContext real de RootDSE, especialmente cuando el contexto de auditoría sea un dominio secundario. Esta revisión del código establece un requisito de validación, no un fallo medido en su bosque.

El proveedor LDAP busca en el subárbol con los resultados limitados a una entrada y lee msDS-ReplAttributeMetaData. Las respuestas ausentes, los errores de solicitud, las etiquetas XML faltantes o las marcas de tiempo no analizadas pueden dejar la fecha en cero. El analizador de marcas de tiempo admite YYYY-MM-DDTHH:MM:SSZ y YYYY-MM-DDTHH:MM:SS. Esta ruta no tiene un estado de sondeo independiente que demuestre que la recopilación tuvo éxito.

El detector no compara un descriptor antiguo con uno nuevo, no calcula diferencias de DACL, no identifica una cuenta solicitante ni demuestra abuso. Use su resultado Info para comenzar la evaluación. Count 1 respalda el predicado temporal implementado; Count 0 no puede certificar que el esquema no haya cambiado ni que la recopilación haya tenido éxito.