How to Audit Active Directory Changes

Learn how to track important Active Directory changes, investigate administrative activity and overcome the limitations of native Windows auditing.

Introduction

Active Directory changes can alter who has access to systems, which policies apply to devices and how administrators control the wider IT environment. A single group membership change, delegated permission or modified account attribute can create significant security and operational consequences.

Effective auditing should establish who made a change, what was changed, when and where it happened, and whether the action was authorised. That evidence supports security monitoring, incident investigation, troubleshooting, access governance and compliance.

Windows provides the underlying audit data, but useful coverage depends on several components working together: the correct advanced audit policies, suitable object-level auditing, adequate event-log retention and collection from every relevant domain controller. This guide explains how to configure that foundation, query it with PowerShell and turn raw events into a repeatable review process.

What Active Directory Changes Should You Audit?

Trying to treat every directory modification as equally important creates noise. Begin with changes that can affect privilege, authentication, policy or business access.

Priority areas normally include:

• Creation, enabling, disabling, deletion and renaming of user accounts
• Password resets and changes to authentication-related account settings
• Additions to and removals from security groups
• Changes to privileged groups, including nested membership
• Creation, modification and deletion of computer and service accounts
• Changes to delegated permissions and access control lists
• Group Policy Object creation, linking, modification and deletion
• Changes to domain password, lockout and Kerberos policies
• Changes to service principal names, delegation and SID history
• Movement or deletion of sensitive directory objects
• Changes to auditing policy or attempts to clear security logs

The guide to identifying privileged accounts in Active Directory can help define which identities and groups require the closest monitoring. The guide to securing Active Directory against privilege escalation provides the wider control context.

Understand How Native AD Auditing Works

Native Active Directory change auditing is not enabled by one switch. It depends on three layers:

1. Advanced audit policy tells domain controllers which categories of security activity to record.
2. System access control lists (SACLs) define which operations and attributes should be audited on relevant directory objects.
3. Security event logs on the domain controller that processed the change hold the resulting events.

Account-management subcategories produce purpose-built events for actions such as user creation and security-group membership changes. Directory Service Changes produces events for object creation, modification, movement, restoration and deletion, but only where the applicable SACL requests auditing.

Because changes can be processed by different domain controllers, reviewing the Security log on one controller does not provide a complete domain-wide history.

Step 1: Define the Audit Scope

Document the questions the audit trail must answer before changing policy. A useful scope identifies:

• The domains and domain controllers in scope
• Critical organisational units, groups and policy containers
• Privileged, service and emergency-access identities
• High-risk attributes and permission changes
• Expected event volume and retention period
• Which platform will collect and protect the events
• Which changes require immediate alerts
• Who reviews alerts and authorises administrative work

Prioritise risk rather than simply collecting the largest possible volume. For example, an unexpected addition to Domain Admins requires a different response from a routine description change on a standard user.

Step 2: Enable Advanced Audit Policy

Configure domain-controller audit policy through a Group Policy Object linked to the Domain Controllers organisational unit. The relevant settings are under:

Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies

For a practical AD change-auditing baseline, review these subcategories:

• Account Management > Audit User Account Management
• Account Management > Audit Computer Account Management
• Account Management > Audit Security Group Management
• DS Access > Audit Directory Service Changes
• Policy Change > Audit Audit Policy Change
• System > Audit Other System Events, where required by the monitoring design

Enable success auditing for completed directory changes. Enable failure auditing where the subcategory supports it and failed attempts contribute useful security evidence. Do not assume every subcategory generates both success and failure events.

Where advanced audit policy is used, also review the security option Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings. This helps prevent legacy category-level policy from overriding the more precise subcategory configuration.

Step 3: Verify the Effective Audit Policy

After Group Policy has applied, check the effective subcategory settings on each domain controller rather than relying only on the GPO editor.

auditpol.exe /get /category:*

To focus on the most relevant categories:

auditpol.exe /get /category:"Account Management"
auditpol.exe /get /category:"DS Access"
auditpol.exe /get /category:"Policy Change"

Confirm Group Policy application and investigate unexpected settings:

gpresult.exe /scope computer /h .\Domain-Controller-GPResult.html

Run these commands from an appropriately authorised administrative session. Repeat verification across domain controllers because policy or replication problems can leave inconsistent coverage.

Step 4: Configure Object-Level Auditing

The Directory Service Changes subcategory does not automatically record every modification. The target object, or an ancestor from which auditing is inherited, needs an appropriate SACL.

You can configure object auditing through Active Directory Administrative Center or another suitable directory administration tool:

1. Enable the advanced features required to view security properties.
2. Open the properties of the domain, organisational unit or object to audit.
3. Open the advanced security settings and select the auditing controls.
4. Add the principal and choose success, failure or both according to the policy.
5. Select the object types, descendant scope and permissions or properties to audit.
6. Review the inheritance effect before applying the change.
7. Generate an approved test change and confirm that the expected event appears.

Broad SACLs applied high in the directory can produce large volumes of events. Start with sensitive organisational units, privileged groups, Group Policy containers and high-risk attributes, then expand only when the additional data has a defined use.

Important Active Directory Event IDs

Different audit subcategories record different aspects of a change. The following event groups provide a practical starting point.

Directory Service Changes

• 5136 – A directory service object was modified
• 5137 – A directory service object was created
• 5138 – A directory service object was restored
• 5139 – A directory service object was moved
• 5141 – A directory service object was deleted

User and Computer Accounts

• 4720 – A user account was created
• 4722 / 4725 / 4726 – A user account was enabled, disabled or deleted
• 4723 / 4724 – An account password change or reset was attempted
• 4738 – A user account was changed
• 4741 / 4742 / 4743 – A computer account was created, changed or deleted
• 4765 / 4766 – SID history was added or an attempt failed
• 4781 – An account name was changed

Security Group Management

• 4727–4730 – Global security-group creation, membership and deletion
• 4731–4735 – Domain-local security-group creation, membership, deletion and changes
• 4754–4758 – Universal security-group creation, membership, deletion and changes
• 4764 – A group type was changed

Policy and Audit Integrity

• 4739 – Domain policy was changed
• 4719 – System audit policy was changed
• 4907 – Auditing settings on an object were changed
• 1102 – The Security audit log was cleared

An event ID identifies the type of activity, not its business meaning. Review the subject account, target object, affected attributes, domain controller, timestamp, logon identifier and related events.

Step 5: Query Change Events with PowerShell

The following read-only example retrieves common directory-change events from the local Security log for the previous 24 hours:

$StartTime = (Get-Date).AddHours(-24)
$EventIds  = 5136, 5137, 5138, 5139, 5141

try {
    Get-WinEvent -FilterHashtable @{
        LogName   = 'Security'
        Id        = $EventIds
        StartTime = $StartTime
    } -ErrorAction Stop |
    Select-Object TimeCreated, Id, MachineName, RecordId, Message
}
catch [System.Diagnostics.Eventing.Reader.EventLogNotFoundException], 
      [System.Exception] {
    
    if ($_.Exception.Message -like "*No events were found*") {
        Write-Host "No Directory Service changes (Event IDs $(${EventIds} -join ', ')) found in the last 24 hours." -ForegroundColor Yellow
    }
    else {
        Write-Warning "Failed to query Security log: $($_.Exception.Message)"
    }
}

FilterHashtable filters at the event-log service and is normally more efficient than retrieving a large log and then using Where-Object.

Access to the Security log requires appropriate permissions. Remote collection also depends on connectivity, firewall rules and the organisation's administrative model.

Query Every Domain Controller

Because the change event is recorded by the domain controller that handled it, query all available domain controllers for a domain-wide view.

Import-Module ActiveDirectory

$StartTime = (Get-Date).AddHours(-24)
$EventIds = 4720, 4722, 4725, 4726, 4728, 4729,
            4732, 4733, 4738, 4756, 4757,
            5136, 5137, 5138, 5139, 5141

$Events = foreach ($DC in Get-ADDomainController -Filter *) {
    try {
        Get-WinEvent -ComputerName $DC.HostName -FilterHashtable @{
            LogName   = 'Security'
            Id        = $EventIds
            StartTime = $StartTime
        } -ErrorAction Stop |
        Select-Object TimeCreated, Id, MachineName, RecordId, Message
    }
    catch {
        Write-Warning "Could not query $($DC.HostName): $($_.Exception.Message)"
    }
}

$Events |
Sort-Object TimeCreated -Descending |
Export-Csv '.\AD-Change-Events.csv' -NoTypeInformation

The script provides a reviewable export, but event messages are not ideal structured data. For recurring reporting, extract the named XML fields instead of depending on localised message text.

Parse Event 5136 into Structured Data

Event 5136 can include the account making the change, target object's distinguished name, attribute name, value and operation type. A modification may produce separate events for the deleted and added values.

$StartTime = (Get-Date).AddHours(-24)

try {
    $Events = Get-WinEvent -FilterHashtable @{
        LogName   = 'Security'
        Id        = 5136
        StartTime = $StartTime
    } -ErrorAction Stop
}
catch {
    if ($_.Exception.Message -like "*No events were found*") {
        Write-Host "No Event 5136 (Directory Service Object Modification) logs found in the last 24 hours." -ForegroundColor Yellow
    }
    else {
        Write-Warning "Failed to query Security log: $($_.Exception.Message)"
    }
    $Events = $null
}

if ($Events) {
    $Report = foreach ($Event in $Events) {
        $Xml  = [xml]$Event.ToXml()
        $Data = @{}

        foreach ($Item in $Xml.Event.EventData.Data) {
            $Data[$Item.Name] = $Item.'#text'
        }

        [PSCustomObject]@{
            TimeCreated      = $Event.TimeCreated
            DomainController = $Event.MachineName
            RecordId         = $Event.RecordId
            SubjectUser      = $Data['SubjectUserName']
            SubjectDomain    = $Data['SubjectDomainName']
            ObjectDN         = $Data['ObjectDN']
            ObjectClass      = $Data['ObjectClass']
            Attribute        = $Data['AttributeLDAPDisplayName']
            OperationType    = $Data['OperationType']
            AttributeValue   = $Data['AttributeValue']
            CorrelationId    = $Data['OpCorrelationID']
        }
    }

    $Report | Sort-Object TimeCreated -Descending
}

Field availability varies by event version and operation. Preserve the original event record and XML when evidence may be needed for an investigation.

Investigate a Suspicious Change

When an important event is detected, use a consistent investigation sequence:

1. Preserve the event. Record the domain controller, channel, record ID, timestamp and raw XML.
2. Identify the actor. Review the subject SID, account, domain and logon ID rather than relying on a display name.
3. Identify the target. Record the object GUID, distinguished name, class, group or affected attribute.
4. Reconstruct the change. Correlate deleted and added values, related event IDs and matching correlation identifiers.
5. Establish the source. Use associated logon events, management-platform records and endpoint evidence to determine where the action originated.
6. Check authorisation. Compare the activity with change tickets, approvals, lifecycle events and the administrator's expected duties.
7. Assess impact. Determine what access, policy or authentication capability the change created.
8. Contain and remediate. Reverse unauthorised access, protect affected identities and follow the incident-response process.
9. Document the outcome. Retain the evidence, decision, actions and validation result.

Do not assume that the subject account is the human who initiated the work. Administrative platforms, scripts and services may perform changes using delegated or service identities. Their own approval and execution logs may be needed to establish the initiating user.

Monitor High-Risk Attribute Changes

Some modifications deserve priority because they can create or conceal privileged access. Depending on the environment, monitor changes involving:

• member and privileged group membership
• userAccountControl account and delegation flags
• servicePrincipalName
• msDS-AllowedToDelegateTo
• Resource-based constrained delegation attributes
• gPLink and gPOptions
• nTSecurityDescriptor and delegated permissions
• sIDHistory
• Password, lockout and Kerberos policy attributes

The appropriate list depends on the organisation's privilege model, applications and attack surface. Validate attribute coverage with controlled tests because not every object or property produces the same audit detail.

Audit Group Policy Changes Carefully

A Group Policy Object has components in both Active Directory and SYSVOL. Directory Service Changes can show modifications to the directory object, links and attributes, but that alone may not describe every file-level policy change.

A complete monitoring design may need to correlate:

• Directory events for objects beneath the Group Policy container
• Changes to gPLink on sites, domains and organisational units
• File-system auditing or change monitoring for SYSVOL
• Group Policy Management and administrative-tool records
• Change-control approval and the resulting policy version

Pay particular attention to GPOs linked to domain controllers, privileged systems and broad organisational-unit scopes.

Check Security Log Capacity and Retention

Auditing has little value if relevant events are overwritten before collection or review. Inspect the Security log configuration across domain controllers:

Import-Module ActiveDirectory

foreach ($DC in Get-ADDomainController -Filter *) {
    try {
        Get-WinEvent -ListLog Security -ComputerName $DC.HostName |
        Select-Object @{Name = 'DomainController'; Expression = { $DC.HostName }},
                      RecordCount, MaximumSizeInBytes, LogMode, IsEnabled
    }
    catch {
        Write-Warning "Could not inspect $($DC.HostName): $($_.Exception.Message)"
    }
}

Size retention against measured event volume, expected collection outages and the investigation period. Central collection should preserve events independently of the source controller and restrict alteration or deletion.

Validate the Audit Configuration

Configuration is not evidence of coverage. Test the complete route from approved change to searchable record.

1. Create a controlled test plan for each important change type.
2. Record the expected audit subcategory and event ID.
3. Apply Group Policy and verify effective settings.
4. Perform the test using a named administrative identity.
5. Confirm the event on the domain controller that processed it.
6. Confirm collection, parsing, enrichment and alerting centrally.
7. Check that the event identifies the actor, target and changed value sufficiently.
8. Measure event volume and retention impact.
9. Record gaps and adjust policy or SACL scope.
10. Repeat tests after material configuration changes.

Include negative tests. Confirm that an unauthorised or unusual change triggers the intended workflow and that a collector outage is visible to the monitoring team.

Common Mistakes to Avoid

Enabling Audit Policy Without SACLs

Directory Service Changes requires appropriate object-level auditing. The policy may appear enabled while important object modifications remain unrecorded.

Checking Only One Domain Controller

The relevant event is stored on the controller that processed the change. A single local log is not a complete audit trail.

Collecting Everything Without Priorities

Excessive event volume increases cost and noise. Start with important objects, attributes and administrative actions that have defined owners and responses.

Ignoring Event-Log Retention

A correctly generated event can still be lost through overwriting, collection failure or deliberate clearing.

Treating an Event as Proof of Authorisation

Security logs show that an account performed an action. They do not prove the action was approved or that the named account's owner initiated it.

Assuming a GPO Is Only a Directory Object

Group Policy also uses SYSVOL. Monitoring only the AD component can leave gaps in the change history.

Generating Reports Without a Response Process

A searchable audit trail does not reduce risk unless important changes are reviewed, investigated and resolved by accountable owners.

Build a Repeatable AD Change-Auditing Process

A sustainable operating process should:

1. Define sensitive objects, attributes and change types.
2. Maintain advanced audit policy and targeted SACLs through change control.
3. Collect events from every relevant domain controller.
4. Normalise and enrich events with identity, asset and change-management context.
5. Alert immediately on high-risk activity.
6. Review lower-risk changes on an appropriate schedule.
7. Compare activity with approvals and expected administrative duties.
8. Track investigations, exceptions and remediation.
9. Protect the audit evidence according to retention requirements.
10. Test coverage and collector health regularly.

Changes to privileged groups, audit policy, domain policy, delegation and sensitive GPOs normally require real-time or near-real-time attention. Routine lifecycle changes may be better suited to scheduled review and exception reporting.

Limitations of Native Windows Auditing

Native logs provide valuable evidence, but operating them at scale is demanding. Common limitations include:

• Events distributed across multiple domain controllers
• Dependency on correct audit policy and SACL configuration
• Technical event fields that require interpretation and correlation
• Separate events for parts of one logical change
• Limited native historical search and reporting
• No built-in business approval context
• Local retention and tamper-resistance concerns
• Additional data sources required for hybrid identity and connected applications

PowerShell is effective for verification and focused investigations. It is less suitable as the sole long-term collection, correlation, alerting and case-management layer for a complex environment.

Automating Active Directory Change Monitoring

Centralised auditing, SIEM and Active Directory reporting platforms can turn distributed Windows events into a more usable operational record.

Depending on the platform, useful capabilities include:

• Collection from all domain controllers
• Clear before-and-after values
• Correlation of related events into one administrative action
• Alerts for privileged membership, delegation and policy changes
• Long-term, protected and searchable retention
• Dashboards and scheduled compliance reports
• Integration with service-management and incident-response workflows
• Coverage across Active Directory, Entra ID and other identity systems

Automation should reflect an agreed monitoring policy. Alerting on every change without risk context can obscure the activity that needs immediate attention.

Final Thoughts

Auditing Active Directory changes effectively requires more than enabling a Windows setting.

A reliable audit trail combines advanced audit policy, targeted object-level auditing, collection from every domain controller, adequate retention and a process for determining whether each important change was expected and authorised.

By prioritising changes that affect privilege, authentication and policy, organisations can create useful security evidence without overwhelming administrators with undifferentiated event noise.