AD sensitive privilege use auditing: Failure plus Success

What Is AD Sensitive Privilege Use Auditing?

AD sensitive privilege use auditing is a host-level visibility check: does Windows record sensitive privilege requests on each domain controller, member server, or workstation in scope? A domain GPO export can suggest an answer, but the evidence needed to close the review is the audit policy reported by the target host plus the events that reach your monitoring platform.

This guide was checked on October 4, 2026, against Microsoft Learn and etc-collector source commit 20268a321609c193b79c5da6764f3f56950449cb. Its starting point is a specific limitation: the EtcSec control AUDIT_PRIVILEGE_USE_DISABLED accepts Failure alone. A result with no counted finding therefore does not establish that both Success plus Failure are enabled.

Microsoft recommends both outcomes for this subcategory across domain controllers, member servers, and workstations. Success records successful attempts; Failure records unsuccessful attempts. See the Microsoft Sensitive Privilege Use recommendation. Review your approved baseline and document exceptions rather than treating the product threshold as the complete policy requirement.

How the Verification Works

Start with the machines you intend to cover. List the domain controllers, relevant member servers, and privileged workstations, together with the policy owner responsible for each population. A successful query on one DC does not establish the state of another DC or a member server. Record the host identity and observation time next to every result.

The distinction between configuration and host state is explained in our guide to checking GPO audit configuration against effective host settings. That article focuses on Account Logon, Account Management, and Policy Change. Here the decision concerns the Success bit of Sensitive Privilege Use and the telemetry that follows from it.

The verification has three gates. First, identify the expected baseline and any approved exception. Second, query the system audit policy on the actual host. Third, match relevant local events to their central copies and verify the fields needed by an analyst. Close each gate with its own evidence: an exception approval cannot substitute for a failed collection check, and a populated event log cannot substitute for the policy query.

When the evidence disagrees, preserve the disagreement. For example, a collected GPO may contain Failure only while a host reports both outcomes. The useful next step is to identify how that host is managed and whether the state is durable. Changing a GPO merely to make an export look consistent can remove a legitimate local setting or leave the actual configuration problem unresolved.

Detection: Read the Policy on Each Host

Run the following read-only query on every target, using an account authorized to read its audit policy. These commands apply the name-or-GUID syntax documented in Microsoft's auditpol get reference; they were checked against that reference, not executed against an AD environment for this article.

auditpol /get /subcategory:"Sensitive Privilege Use"

On hosts with a different display language, query by the Sensitive Privilege Use GUID documented by Microsoft, also used by the collector:

auditpol /get /subcategory:"{0cce9228-69ae-11d9-bed3-505054503030}" /r

Without /user, auditpol queries the system policy. Preserve the output, host, timestamp, command, and any error. A permission error is an unknown result requiring authorized access; it is not a disabled-policy result. Investigate per-user policy separately when relevant to a particular account or an unexpected event outcome.

Keep the policy result separate from the event sample. Old events may survive a policy change, so an event observed before the query is not proof of the current setting. Conversely, a quiet observation window may contain no relevant operation. Record the window and the expected activity before deciding whether absent events indicate a generation or collection problem.

Detection: Validate 4673/4674 Through the Collection Pipeline

Microsoft documents 4673 as a privileged service call and 4674 as an attempted operation on a privileged object. Both can also belong to Non Sensitive Privilege Use. Inspect the privilege and operation context; the event number alone does not identify the sensitive subcategory.

Use this local Security-log query to inspect XML. It applies the query, reverse-order, and output-format options in the Microsoft wevtutil reference:

wevtutil qe Security /q:"*[System[(EventID=4673 or EventID=4674)]]" /rd:true /f:xml

Choose a bounded observation window appropriate to your review when searching centrally. Match local records to their received copies using host identity, time, event ID, and record ID where retained. Verify the connector's normalization of audit outcome and privilege names against the original XML, especially when the central view merges fields or removes empty values.

The companion guide to central event collection and parser validation supports this transport and field-mapping work. Retain an example of each relevant event type actually observed. If a required example is unavailable, document the untested case instead of claiming complete coverage.

That distinction is explicit in Microsoft's 4672 documentation. Use 4672 for its logon context, while keeping generation and forwarding checks for 4673/4674 separate. Evaluate unexpected accounts, privileges, and processes against approved administrative activity before escalating an event as possible abuse.

Remediation: Verify Failure plus Success After Deployment

1. Correct the Managed Subcategory

Where the approved baseline requires both outcomes, configure Audit Sensitive Privilege Use under Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > System Audit Policies > Privilege Use. Select Success plus Failure in the GPO or configuration system that actually manages the target population.

Document the change owner, target hosts, exception list, previous configuration, and rollback decision. Pilot the change on representative machines before extending it to the remaining scope. The rollout should follow the host population and management boundary you identified, rather than assume every relevant computer is controlled by the same default policy.

2. Check the Legacy Override and Re-read Host State

Review Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings. Microsoft recommends leaving it enabled and documents SCENoApplyLegacyAuditPolicy as preventing application of category-level policy. Consult the Microsoft legacy-override policy reference when reconciling basic and advanced audit settings.

After the managed change has reached each host, repeat the GUID-based auditpol query above. Compare the before/after outputs. If a host still differs, investigate the applicable management source and policy processing; do not declare remediation complete from the GPO editor alone.

3. Keep Backup/Restore as a Separate Decision

Auditing use of Backup and Restore privileges additionally depends on Audit: Audit the use of Backup and Restore privilege. Microsoft discourages enabling that separate setting because it can produce substantial event volume. Do not enable it everywhere as a shortcut to closing this review. Record the required visibility, workload, operational capacity, and owner decision for any exception to that recommendation.

4. Confirm Delivery Before Closing the Review

Recheck local generation and central parsing after deployment using approved, controlled activity relevant to the intended privilege. Agree on the expected event with the monitoring owner before the test. A generic administrative action is not a guarantee that both event IDs or both outcomes will appear.

If local events exist but central copies are missing, investigate the forwarding subscription, agent filters, ingestion errors, and parser configuration. If local events are missing, first verify the operation, audit setting, and observation window. These are different failures with different owners. Set a follow-up date for unresolved cases and recheck after host rebuilds or changes to the managing policy.

How EtcSec Detects This

At the source commit reviewed here, AUDIT_PRIVILEGE_USE_DISABLED reads advancedAuditLevel. That helper uses a selected advanced-audit GPO map or falls back to legacy EventAudit data. With a known value below 2, the detector emits a Medium finding with Count 1. Value 2 means Failure only and value 3 means Success plus Failure: both pass its threshold. Success is not required by this detector.

When neither selected source supplies the setting, ok=false returns Count 0, retains the initialized Medium severity, and includes details explaining that it is not configured via GPO. The effective host policy remains unknown; this is not evidence of compliance or disabled auditing.

The source selection has additional limits:

• Advanced-audit selection prefers Default Domain Controllers Policy, then Default Domain Policy, then the first available map entry. Legacy EventAudit selection prefers Default Domain Policy, then Default Domain Controllers Policy, then the first available entry. These precedences differ.
• A missing subcategory in the selected advanced map does not trigger a search through other advanced maps. The helper can instead fall back to the selected legacy category.
• The SMB provider ignores file-read failures for GptTmpl.inf and audit.csv during policy collection. An EventAudit section containing another field can leave the missing Privilege Use field at its zero value.
• The audit.csv parser extracts GUID/value pairs; it does not attest that a policy applied to a host or preserve a complete application provenance record.

This path does not compute Windows Resultant Set of Policy or fully account for SCENoApplyLegacyAuditPolicy. It also does not prove event generation, forwarding, or parsing. Use the finding to prioritize investigation, then close the review with each host's auditpol output and collection evidence.

Review Record

Retain the baseline decision, scoped host inventory, per-host policy output, approved exceptions, before/after comparison, and local-to-central event samples. Assign an owner to every unknown result. The review is complete when each scoped host has a documented outcome and the required telemetry has been verified, with any remaining exception explicitly accepted by its owner.