AD attribute change approval: pair 5136 values

What Is AD Attribute Change Approval?

An AD attribute change approval review links a recorded modification of an existing directory object to an independently authorized decision. Its output is an evidence record: the object GUID, changed attribute, observed deleted and added values, operation correlation ID, requesting account, emitting domain controller, event time and approval evidence. A familiar administrator name or a low posture finding count cannot substitute for that record.

Use this procedure when a directory modification needs an explanation before the review is closed or a corrective change is approved. Start with one object and one attribute. Preserve the original events, establish the collection limits and ask the authorized decision maker to confirm whether the observed value change matches the request. The review can end with a supported approval, a confirmed unauthorized change or an unresolved evidence gap; those outcomes require different follow-up.

This article concerns changes to an existing object. For newly provisioned objects, use the creation register that connects whenCreated and creation evidence to approved provisioning. For the wider comparison between intended access and effective group, ACL and replication rights, use the privileged access drift review and revalidation workflow. Here, the deliverable is the attribute-change evidence record rather than another inventory of privileged accounts.

How It Works: Establish What 5136 Can Show

Microsoft documents event 5136 for modifications to directory service objects. For the event to be generated, Directory Service Changes success auditing must apply and the object needs a matching SACL entry auditing the relevant attribute write. The audit subcategory operates on domain controllers. Some object or property changes are not audited because of schema settings, so policy enablement alone does not establish complete coverage. Microsoft Learn: Event 5136, Audit Directory Service Changes.

For a replacement, Microsoft describes a typical deleted-value event followed by an added-value event. Treat that pattern as a reconstruction aid. It is not a guarantee that every review has exactly two records. An attribute can have multiple values, an operation can affect several attributes, and the retained records may be incomplete. Keep every relevant value event and explain how it contributes to the reviewed change.

The XML field OperationType distinguishes an addition, %%14674, from a deletion, %%14675. AttributeValue contains the value involved in that event. Preserve both the raw operation code and its meaning. Do not interpret an added value as a complete post-change attribute set when it may represent one member of a multi-value attribute. Microsoft Learn: Event 5136 field descriptions.

OpCorrelationID relates modifications belonging to an LDAP operation. It can span more than the one attribute under review. Combine it with object and attribute identity, provenance and time; it is not a business ticket reference. Microsoft describes AppCorrelationID as unused, with a dash value. Neither field supplies the organization’s approval decision.

Detection: Collect a Bounded Evidence Set

The commands below use documented command and parameter syntax adapted to this review. They have not been executed against a real domain. Run event reads from an authorized Windows host; use the Active Directory module for the object read. Replace the example DC, UTC interval and object GUID with the actual case inputs. Record permissions errors and unavailable logs as failed observations rather than empty, successful searches. Remote Get-WinEvent reads require firewall access to the Windows Event Log service; the cmdlet does not rely on PowerShell remoting. Microsoft Learn: Get-WinEvent ComputerName.

Step 1: Record audit and retention coverage

On each DC relevant to the case, inspect the current system audit subcategory. The English name below requires an installation that recognizes that name; the documented syntax also accepts a subcategory GUID.

auditpol /get /subcategory:"Directory Service Changes" /r

The expected output is a policy report identifying the subcategory and its success/failure settings. Save the DC identity, collection time, command and returned report. A successful query establishes what was read at that time. It does not prove that the same setting applied when the historical modification occurred. The command’s syntax and read-permission requirements are documented in Microsoft Learn: auditpol get.

For log configuration, inspect the Security log on the same DC:

Get-WinEvent -ListLog Security -ComputerName 'dc01.contoso.local' -ErrorAction Stop

The result describes the log, including its mode, configured maximum size and record count. A size or count does not prove that the target interval remains searchable. Check the retained local records and central archives for that interval, and document source coverage, forwarding gaps and available historical policy/SACL evidence. Microsoft Learn: Get-WinEvent.

Answer the first decision question explicitly: which attribute-write SACL and which retention evidence support this reconstruction? Record the audited object or inherited scope, relevant write action, covered principal and success setting. If only current configuration is available, mark historical coverage as unproven. Do not infer that an absent historical event means the attribute was never modified.

Step 2: Retrieve the events without an arbitrary pair limit

Use a bounded interval that includes the change under review. The following example selects Security events by provider, ID and time:

$reviewStart = [DateTimeOffset]::Parse('2026-10-04T08:00:00Z').UtcDateTime
$reviewEnd = [DateTimeOffset]::Parse('2026-10-04T09:00:00Z').UtcDateTime
$events = Get-WinEvent -ComputerName 'dc01.contoso.local' -FilterHashtable @{
    LogName = 'Security'
    ProviderName = 'Microsoft-Windows-Security-Auditing'
    Id = 5136
    StartTime = $reviewStart
    EndTime = $reviewEnd
} -ErrorAction Stop

These are illustrative times, not a measured change window or a prescribed review duration. Get-WinEvent documents these filter keys and returns event records, newest first by default. The example intentionally does not request only two events or cap the result with -MaxEvents. Preserve the query and outcome before selecting the object and attribute from the event XML. Microsoft Learn: Get-WinEvent filter parameters.

Expect zero or more matching records, not a predetermined count. If the command reports no matching events, distinguish that result from access or connection errors and then evaluate retention and generation coverage. Search authorized archives as needed; the cmdlet also documents -Path for saved event files. A failed read must remain visible in the case record.

Retain the original event export and each event’s XML. A screenshot of the newest value is insufficient for reconstruction. In a SIEM, verify that ingestion preserves the fields below and keeps source event identity separate from ingestion time and any duplicate forwarded copies.

Step 3: Assemble the attribute-change record

Use ObjectGUID to identify the object and AttributeLDAPDisplayName to identify the attribute. Record the DN and class as context. Then collect all candidate value events sharing the operation correlation ID for that object/attribute, checking the emitting DC, subject and times. If those fields disagree, keep the disagreement for investigation instead of forcing the records into one pair.

These event field names come from the 5136 XML and field descriptions. The approval fields are a proposed review record, not additional Windows telemetry.

For a single-value replacement with complete evidence, the reviewer should be able to describe the observed deletion and addition and reference each source record. For a multi-value attribute, retain the individual removals and additions as sets of observed operations. Do not invent unchanged values or claim that the event set is a complete before/after snapshot.

To compare with current directory state, Get-ADObject accepts an object GUID as -Identity, extra attributes as -Properties and a specific server as -Server. This example uses the GUID from Microsoft’s sample 5136 event; replace it and the sample attribute with the reviewed identifiers.

Get-ADObject -Identity '4fe80a66-5f93-4f73-b215-68678058e613' -Server 'dc01.contoso.local' -Properties userAccountControl -ErrorAction Stop

Expect the located object and requested property, or an explicit read/lookup error. Preserve the collection time and DC. Current state can help validate remediation, but it cannot recover a missing historical value or approval. Microsoft Learn: Get-ADObject.

Verification: Make the Approval Decision Independent

Ask the designated change authority to match the request to this object, attribute and intended value change. Record who is authorized to decide, the approval evidence and its time, and whether that evidence covers the observed operation. An operator explaining a change is useful evidence, but an explanation is not automatically an independent approval.

Keep the technical actor and decision maker in separate fields. If an automation account requested the change, record that subject without guessing the human initiator. Establish any operator attribution through independent records. Likewise, do not join a business request to an event merely because the timestamps are close or both descriptions mention “directory maintenance.”

Classify the difficult cases explicitly:

This table proposes review outcomes. It does not claim that every unmatched event is malicious. Answer the remaining decision questions before closure: who confirms authorization independently of the technical actor, and how will missing, multi-value or deletion-only evidence be qualified? Give each unresolved item an owner and the next evidence request.

Remediation: Resolve the Decision and Validate Coverage

Preserve the historical evidence before making a corrective directory change. For a supported approved modification, attach the decision to the review record. For an approval mismatch or confirmed unauthorized change, have the responsible identity and service owners assess exposure and dependencies, decide on containment or correction, and record the authorized target state. Avoid blindly restoring a deleted value: later legitimate changes or multi-value dependencies may make that action incorrect.

If generation coverage is inadequate, authorized administrators should repair the applicable audit policy and attribute-write SACL. Microsoft documents success auditing for Directory Service Changes and no Failure events in this subcategory. Run the following command locally on the selected DC. It uses the documented auditpol /set syntax to enable success auditing, changes configuration and belongs in an approved administrative procedure.

auditpol /set /subcategory:"Directory Service Changes" /success:enable

A successful command outcome is followed by the auditpol /get read above and the separately verified matching SACL. The command does not configure a SACL, prove centrally managed policy persistence or recreate past events. Coordinate it with the policy owner and preserve the resulting configuration evidence. Microsoft Learn: auditpol set, Audit Directory Service Changes.

Validate future coverage through an approved pilot modification on a non-production test object and a suitable attribute. Record the authorized old/new intent before the test. Check that the generated and retained events contain the expected object, attribute and value operations, that forwarding preserves their identity, and that the review can link them to the test approval. No such domain test was performed for this article.

After an authorized correction, repeat the scoped object read and event review. Preserve the current state, corrective operation evidence and independent decision. Close only the supported portions of the case; carry historical reconstruction gaps forward with a documented disposition.

How EtcSec Detects This

At collector commit bcd03c540bfccdeecf70f36bb80fd58bbe0bef1d, CHANGE_MANAGEMENT_BYPASS is a Medium posture heuristic. Its Detect() reads collected LDAP users. It counts enabled users whose direct memberOf entries contain the English names Domain Admins or Enterprise Admins, using case-insensitive substring matching. More than 10 such users creates an issue. A separate count includes users with at least one SPN and adminCount=1; more than 5 creates another issue. The second count does not exclude disabled users.

If either condition is met, the returned finding has Count=1; otherwise it has Count=0. One is the finding indicator, not the number of unapproved changes. The details include the two aggregate counters. The thresholds are product heuristics without normative authority, not Microsoft, ANSSI or HDS approval requirements.

The LDAP provider supplies memberOf, servicePrincipalName and adminCount. This detector does not expand nested group membership. Renamed or localized privileged-group names can defeat the English-name match; substring matching is not a stable group-SID test. Microsoft documents that adminCount can remain set to 1 after an account leaves a protected group; this flag therefore does not establish current effective privilege. An SPN can be registered on a user or computer account, so its presence alone does not establish the account's current operational purpose. Microsoft Learn: protected accounts and adminCount, SPN registration. Collection scope and limits also constrain the populations examined.

This check reads no 5136 events, removed/added values, correlation IDs, SACLs, retention records or approval workflows. A positive finding can prompt a change-management review, but it cannot prove bypass, identify this attribute modification or decide authorization. A zero count cannot clear the evidence record. Complete the event reconstruction and independent decision above before closing the review.