Active Directory / Advanced / Lesson 16
Monitoring and evidence correlation
Collect and interpret the right categories of authorized evidence, distinguish events from operations, and avoid claiming health from missing logs or one successful client.
On this page
Lesson goals
- Separate availability, replication, authentication, policy, and change signals.
- Explain audit-policy and object-auditing prerequisites.
- Correlate synthetic records without reading live Windows channels.
Observe the directory outcomes users and owners need
A controller answering one request does not prove every directory service is healthy. Define availability, authentication success, replication convergence, policy delivery, and change accountability as separate outcomes with their own evidence. Site and controller identity matter when symptoms are intermittent. Alerting thresholds need a baseline, service objective, sampling window, and escalation owner rather than universal numbers. A sudden absence of events can reflect collection failure or audit scope, not perfect security. This course uses synthetic normalized records only and never opens an event channel, queries a controller, or enables diagnostic logging.
An audit event depends on configured collection conditions
Directory-change auditing depends on applicable audit policy and the relevant object SACL, among other documented conditions. Microsoft’s event 5136 describes an object modification and can generate related value-deleted/value-added records for one action. It is therefore wrong to count every event as a separate administrative change. Not every field is present or safe to publish, and event schemas can vary by event/version. An authentication event records its particular stage, not every later resource decision. Keep event identifiers, provider/channel, timestamp, controller, object identity, and correlation fields in context rather than interpreting an isolated number as a diagnosis.
Group declared event records without inventing missing identity
The complete Python fixture filters three synthetic normalized records and counts two modification events belonging to one declared operation. Its operation label is a local fixture key, not a claim to parse actual Windows XML or a real correlation GUID. Real correlation must handle missing keys, multiple channels, time differences, and collection delays. Do not merge every unknown correlation into one operation. The arithmetic output demonstrates event-versus-operation counting only. It cannot prove the actor was authorized, the change succeeded across replicas, or every relevant event was collected. Preserve raw evidence under the approved handling process when a real investigation requires it.
events = [
{"event_id": 5136, "operation": "synthetic-op-1", "phase": "value_deleted"},
{"event_id": 5136, "operation": "synthetic-op-1", "phase": "value_added"},
{"event_id": 4768, "operation": "synthetic-auth-2", "phase": "ticket_request"},
]
changes = [event for event in events if event["event_id"] == 5136]
operations = {event["operation"] for event in changes}
print("events=" + str(len(changes)), "operations=" + str(len(operations)))
events=2 operations=1
The line is events=2 operations=1. No live event, identity, directory, or authentication material is read.
Make the question and collection limits explicit
The contextual record separates the intended change question from authentication and replication observations. It is not an audit-policy file or a command to collect logs. A real evidence plan should minimize sensitive attributes, protect access and retention, preserve trustworthy timestamps, and document what is not collected. High-cardinality identity data belongs in controlled investigation context, not indiscriminate metric labels. Avoid logging credentials, secrets, or full directory dumps to simplify correlation. An approved monitoring change can affect volume and performance, so scope it and define when temporary diagnostics end. No such change is performed by these examples.
{"question":"was-the-reviewed-object-change-accountable","sources":["authorized_change_record","sanitized_directory_events","replication_context"],"excluded":["credentials","secret_attributes","unbounded_directory_dump"],"collection_action":"none"}
The record defines permitted evidence categories and exclusions. It enables no auditing, retrieves no logs, and asserts no live security outcome.
Validate the observation pipeline and the business conclusion
A monitoring test must distinguish source event generation, collection, transport, parsing, retention, alerting, and analyst interpretation. A local Counter-like model tests only the final arithmetic. Verify known positive and negative cases in an approved isolated environment before declaring coverage. Compare controller clocks and the incident timeline carefully rather than forcing a causal order from unsynchronized timestamps. Record uncertainty and escalate high-impact identity changes to the accountable owner. A dashboard can summarize a symptom without identifying its cause, and a successful authentication event cannot prove access permission or forest recoverability. Keep conclusions proportional to the evidence actually available.
Common errors and fixes
Two 5136 records are counted as two independent changes.
- Why it happens
- Event count was confused with correlated operation count.
- How to fix it
- Interpret the documented fields and correlate valid operation evidence.
- Prevent it next time
- Test multi-record and missing-correlation cases.
No events is described as proof of no changes.
- Why it happens
- Audit policy, SACL, and collection coverage were assumed.
- How to fix it
- Verify the observation prerequisites and pipeline.
- Prevent it next time
- Maintain known-positive monitoring checks.
Full sensitive directory content is logged for convenience.
- Why it happens
- Evidence usefulness was pursued without data minimization.
- How to fix it
- Select authorized fields and protect access/retention.
- Prevent it next time
- Review diagnostic scope and expiry before collection.
Check your understanding
1. Add another value-added record for synthetic-op-1 to the fixture. Give the event and operation counts and explain a remaining uncertainty.
Show worked solution
There are three selected modification events but still one declared operation identity. The model cannot determine whether the extra record is a duplicate collection, another attribute change, or a different real action with bad normalization. Real interpretation needs trustworthy event fields and collection context. Do not turn this set count into a claim that exactly one authorized administrative action occurred.
2. An alert disappears after an audit collector stops. What should the review distinguish before declaring the issue resolved?
Show worked solution
Distinguish absence of the underlying failure from absence of observation. Check the approved collection pipeline, source coverage, retention, and known-positive signal before interpreting a quiet dashboard. Preserve the incident’s service outcome evidence separately. A stopped collector can remove visibility while the directory problem remains unchanged.
Key takeaways
- Events, operations, and outcomes are different units.
- Audit coverage has prerequisites and sensitive data.
- Missing evidence is not evidence of health.