AD schema security descriptor metadata: qualify a recent change

What AD schema security descriptor metadata tells you

AD schema security descriptor metadata helps qualify when the security descriptor on the schema naming-context root last changed. A recent timestamp is a reason to collect evidence and review the change. It does not establish that a permission became dangerous, that an administrator acted without authorization, or that the forest was compromised.

This guide examines nTSecurityDescriptor on the exact object returned as schemaNamingContext. It does not examine defaultSecurityDescriptor on individual schema classes. Keep that distinction in the investigation record: a change to the root object's descriptor and a change to a class's default descriptor are different review targets.

Microsoft describes msDS-ReplAttributeMetaData as system-maintained metadata for replicated attributes. Treat that information as replication provenance. The originating directory server is not the human or service account that requested a write. Establishing the requesting account requires separate evidence.

The practical outcome is a qualification sheet: which object was queried, which domain controller answered, what metadata was returned, whether the timestamp is usable, and whether an approved baseline explains the current permissions. This is an investigation workflow, reviewed against Microsoft documentation on October 4, 2026; no commands here were executed against a customer directory.

Detection: identify the object before querying metadata

Step 1: resolve the schema naming context on the chosen DC

Use a Windows administrative workstation with the ActiveDirectory PowerShell module and an account authorized to read the relevant directory data. Replace the example server with a specific DC in your forest. Keep the same server for discovery and the first metadata query.

The following example uses the documented -Server parameter of Get-ADRootDSE. Its output includes schemaNamingContext, defaultNamingContext, the server hostname and current time.

$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.'
}

Record the returned DN exactly. Compare it with the object DN used by your audit tool. In a child-domain context, specifically verify whether a DN assembled from the current domain's DN matches RootDSE. A mismatch is a collection question to resolve before interpreting the finding; it is not evidence that the descriptor changed.

Step 2: retrieve the attribute's replication metadata

Get-ADReplicationAttributeMetadata accepts a distinguished name through -Object, a DC through -Server, and attribute names through -Properties. This example narrows the request to nTSecurityDescriptor and displays the complete returned metadata rather than hiding fields in a short table.

$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 *

Preserve the output, including the attribute name, version, last originating change time and originating directory-server identity. Separate the DC you queried from the server identified as the origin of the change. Keep any unresolved identity as returned; do not replace it with an assumed administrator name.

Step 3: qualify the timestamp and observation window

Record the collection time and timezone alongside the raw timestamp. Confirm that the date is present and interpreted correctly before applying a window. Use the audit's recorded reference time when reproducing its decision, rather than silently substituting today's time during a later investigation.

If you repeat the query on another DC, repeat RootDSE discovery there too and save a separate collection record. Do not merge two observations into an invented history. A latest-change timestamp cannot reconstruct every earlier descriptor state or every modification in the review period.

Remediation: qualify first, correct confirmed drift

Step 1: compare the current descriptor with an approved reference

Obtain the current descriptor for the exact schema root and compare it with a dated, approved reference for that same object. For a permissions view on the selected DC, the following uses Microsoft's documented remote-object syntax for Dsacls. Run the command from an elevated Windows shell with Dsacls installed and read access to the target object. With no modification switches, it displays the ACL.

dsacls "\\$dc\$schemaDN"

Retain the command output and report any failure. An ACL display supports permissions review; keep a complete descriptor export through your approved directory tooling if the investigation also needs owner, group or auditing information. Label exactly which components were captured so a partial view is not presented as a complete descriptor comparison.

Review changed trustees, rights, object-specific GUIDs, inheritance and scope. Establish whether each difference belongs to the root itself or to another object. The existing review of schema permissions provides related permissions context; this timing check does not demonstrate a change to a class's defaultSecurityDescriptor.

If no approved reference exists, record that limitation. The current descriptor can still be reviewed against the organization's intended delegation, but an exact historical diff remains unavailable. Do not manufacture a previous state from the timestamp or treat a generic default as your forest's approved baseline.

Step 2: correlate authorization and available events

Match the evidence against an actual change ticket: target DN, expected permissions, responsible team, approved execution window and resulting state. A ticket mentioning a schema-related deployment is insufficient on its own; verify that its intended change explains the observed object and descriptor difference.

Microsoft documents Security event 5136 for directory-object modifications under Audit Directory Service Changes. Generation requires an appropriate attribute-write auditing entry in the object's SACL. Where events exist, check ObjectDN and AttributeLDAPDisplayName, retain the Subject account fields, and correlate matching operations using OpCorrelationID. Microsoft describes typical Value Deleted and Value Added records, but verify the values actually available in your evidence.

Use the AD monitoring guide for event collection and correlation to review the surrounding monitoring pipeline. Establish whether auditing, forwarding and retention covered the relevant DC and time before interpreting an empty search. A Subject account identifies a requesting principal in the event; any attribution to a particular person still needs supporting operational records.

Step 3: choose a defensible disposition

An unexplained timestamp alone belongs in the third branch. A confirmed permissions deviation can justify remediation without establishing who caused it. Keep the authorization question and the current exposure assessment explicit, so the response does not depend on unsupported attribution.

Step 4: correct only the confirmed descriptor deviation

Have the authorized directory team prepare a change against the verified schema-root DN. Save the current descriptor, identify the exact ACE or descriptor component to correct, document the intended result and arrange a recovery path before writing. Apply the reviewed change through your approved ACL editor, preserving legitimate delegation and required permissions.

Avoid using a blanket reset to explain away a recent timestamp. Microsoft's Dsacls reference describes /S as restoring class defaults and /R as removing all ACEs for a specified principal; neither substitutes for a targeted correction supported by your approved comparison.

After correction, repeat the RootDSE, metadata and permissions reads. Verify that the intended descriptor state is present and that required directory operations still work. Record the new metadata and any collected audit evidence as a new authorized change. A recent-change finding may remain positive after a legitimate correction because the correction is itself recent; validate the permissions, not just the disappearance of the timing signal.

How EtcSec Detects This

In the reviewed etc-collector implementation, SCHEMA_SD_RECENT_CHANGE produces an Info finding with Count 1 when SchemaSDLastChanged is nonzero and strictly after data.Now.AddDate(0, 0, -90). The threshold uses calendar-day subtraction. The exact cutoff is excluded, and there is no upper bound at Now: a future date also passes the test. Otherwise the returned finding has Count 0.

The engine constructs CN=Schema,CN=Configuration, followed by DomainInfo.DomainDN, requests replication metadata and copies the change time for nTSecurityDescriptor. Compare that constructed DN with the actual RootDSE schemaNamingContext, especially when the audit context is a child domain. This source review establishes a validation requirement, not a measured failure in your forest.

The LDAP provider searches the subtree with results limited to one entry and reads msDS-ReplAttributeMetaData. Missing responses, request errors, missing XML tags or unparsed timestamps can leave the date zero. The timestamp parser supports YYYY-MM-DDTHH:MM:SSZ and YYYY-MM-DDTHH:MM:SS. This path has no separate probed state establishing that collection succeeded.

The detector does not compare an old descriptor with a new one, calculate a DACL diff, identify a requesting account or establish abuse. Use its Info result to begin qualification. A Count 1 supports the implemented timing predicate; a Count 0 cannot certify an unchanged schema or successful collection.