Where Is Telemetry Generated? The Relationship Between Clients, Servers, DCs, Audit Policy, and SACLs.

1. Core mechanism

Telemetry design comes before log collection. A collection architecture established without knowing which question has the answer on which machine produces an archive with a large volume but a broken chain of evidence. The Windows audit model consists of three stages: first the audit policy subcategory opens an event family, then in families such as object access the SACL of the object determines which accesses will be recorded, and finally the event is written on the Security channel of the machine performing that operation. If one of the three levels is missing, recording will not occur and this deficiency will appear as silence, not as an error. Therefore, 'not in the log' is not a synonym for 'did not happen'.

Interfaces and specifications

• Audit-policy subcategories: Advanced Audit Policy Configuration divides auditing into detailed subcategories under nine main categories. Event families depend on these subcategories, so a category-level statement does not identify which events are enabled.
• Subcategory precedence: When 'Audit: Force audit policy subcategory settings to override audit policy category settings' is enabled, subcategory settings override legacy category-based settings. If this setting is off, legacy policy can interfere with the intended detailed configuration.
• SACL: Object-access auditing has two conditions. The audit subcategory must be enabled, and the object's SACL must contain an audit ACE for the relevant principal and access type. A matching SACL can audit successful or failed attempts according to its flags.
• Domain-controller event families: Kerberos authentication-service and service-ticket events are generated on domain controllers; searching for them on a client is looking at the wrong source.
• Directory-change events: Audit Directory Service Changes is logged only on domain controllers, requires a matching SACL on the relevant object or container, and covers create, delete, modify, move, and undelete operations.
• Audit-setting changes have different scopes: Event 4719 reports system audit-policy changes. Event 4907 reports SACL changes on objects such as files or registry keys, but Microsoft says it is not generated for Active Directory objects. AD DS object changes may appear as Event 5136 when the subcategory and an attribute-specific Write Property audit ACE in the object’s SACL cover the change. None of these records alone proves the effective policy or SACL coverage on every object.

Events are recorded on the machine that performs the operation

When a user connects to a file server in a domain, several machines do work. The domain controller issues the Kerberos ticket, the file server creates the logon session, and the user's workstation initiates the request. Each machine records its own activity. So the answer to 'which server did the user access?' is on that server, while the answer to 'for which service did the user request a ticket?' is on the DC.

Kerberos ticket event families are generated on domain controllers. Searching for a ticket request in a workstation's Security channel can return nothing by design. Directory-object changes are likewise recorded on the domain controller that processes them.

During an investigation, start with the question, identify the machine expected to produce the answer, and then verify whether the relevant subcategory was active there at the time. Skipping this sequence can leave the evidence undiscovered even when log volume is high.

Two conditions for object-access auditing: policy and SACL

Object-access auditing does not have a single switch. First, enable the relevant subcategory. Then add an audit ACE to the target object's SACL specifying which principal and access type to audit. If either condition is missing, the expected event may not be generated.

The same conditions apply to directory changes. Even with Audit Directory Service Changes enabled, an event may not be generated if the relevant object or parent container lacks a matching audit ACE. Microsoft warns that this subcategory can produce high event volume, so choose SACL scope deliberately.

Scope is a balance. A broad SACL can create unnecessary load and noise on domain controllers; a narrow SACL can miss the change under investigation. Identify critical containers and object classes in advance, document the intended scope, and review it periodically.

Distinguish the causes of silence

An event may be missing because the transaction never happened, the wrong machine was checked, the relevant subcategory was disabled, or the object's SACL did not cover the access. A conclusion that does not distinguish these possibilities has little evidentiary value. SACL-change telemetry also has boundaries: Event 4907 is not generated for AD objects; Event 5136 can show a covered AD attribute change only when the conditions for an attribute-specific Write Property audit ACE in the object’s SACL are met. This does not guarantee visibility into every change to the SACL itself. If the audit ACE itself is removed, that event coverage may disappear too.

A telemetry inventory should map which questions can be answered under which conditions, rather than merely list collected sources. For each critical question, record the source machine, required subcategory, and SACL scope when applicable. That map makes investigation routing faster and keeps the evidence boundary explicit.

Here, a Write Property audit ACE is a SACL entry defining when attribute writes are audited; it is not a DACL ACE granting write access. Accessing or changing the SACL itself is separate: Windows evaluates ACCESS_SYSTEM_SECURITY and the applicable SeSecurityPrivilege conditions. Keeping these distinct prevents interpreting a missing audit record as proof of missing write permission.

State and data flow

1. The question is determined: session, ticket, directory change? The question determines on which machine the event is expected to arise.
2. Verifies whether the relevant control subcategory is enabled on the target machine; The policy setting that allows subcategory settings to override old category settings is also checked.
3. If object access or directory change is involved, SACL of the target object or container is examined; principal and access types covered are read.
4. When the transaction occurs, the event is written to the Security channel of the machine performing the transaction; For KDC authentication-service/ticket and directory-change families, this machine is the domain controller.
5. For system audit-policy changes, review Event 4719. Event 4907 covers SACL changes on non-AD objects such as files or registry keys, not AD objects. For AD DS changes, Event 5136 depends on the relevant audit subcategory and an attribute-specific Write Property audit ACE in the object’s SACL. Validate effective policy and security-descriptor scope separately; no single event proves full coverage.

2. Exploitation

Broken trust assumption

The assumption is “We centrally collect the Security logs of all domain controllers and servers, so we can see everything that is happening in the environment.” From this it is concluded that the failure to find the record sought in an investigation means that that transaction never took place.

Technical prerequisites

• Audit policy is defined at the category level; It has not been verified on a machine-by-machine basis which subcategories are actually active.
• Object access and directory change checking are considered 'open', but the critical container and SACL scope of objects is not documented.
• Collection architecture lists source machines; There is no mapping as to which question can be answered on which machine.
• Events indicating control setting changes are not tracked; scope reduction is not noticeable.
• Policy conflicts and subcategory priority setting status are not checked regularly.

Exploitation mechanism

The error produced by this assumption is turning absence into evidence. In the Windows control model, record generation is conditional: if the subcategory is closed, no event is raised, and in object access families, no event is raised for an access outside the scope of SACL. In both cases, the system does not issue an error; There is simply no registration. Centralized aggregation hides this silence because the aggregator only receives produced events and cannot report the absence of unproduced events. The second source of error is looking at the wrong machine: Kerberos ticket families are recorded only on domain controllers, session creation is recorded on the accessed machine. The third source of error is that the scope changes over time; When an object's SACL is collapsed, the recording flow for that object silently stops. This lesson does not describe an attack method; The point is that telemetry coverage should be a validated input, not an assumption, before each inspection.

Absence is not evidence

The easiest and most fragile sentence to write in an inspection report is the sentence 'no relevant record was found, therefore no such transaction took place'. For this sentence to be valid, three things must also be verified: that the correct machine is being looked at, that the relevant subcategory is active at that time, and that, if object access is involved, SACL covers that access.

The sentence written without validating the three is actually a statement of the telemetry scope, not the behavior of the environment. A mature review process carries this distinction into the report language: 'no record seen in covered resources' and 'no transaction occurred' are two claims with different degrees of strength.

Coverage drifts over time

Telemetry coverage is not static. Policy objects change, new servers come with different base configurations, security descriptors of critical directory containers are updated. Some of these changes expand the scope, some narrow it, and the contraction is usually silent.

Events can help track changes to system audit policy or covered object-auditing settings, but their scope differs. Event 4719 reports system audit-policy changes; Event 4907 is for SACL changes on non-AD objects and does not generate for AD objects. Event 5136 can record a covered AD attribute change only when the directory-change subcategory and an attribute-specific Write Property audit ACE in the object’s SACL are configured. Event monitoring therefore does not replace effective-policy checks and direct security-descriptor review.

Volume is not visibility

High log volume is often mistaken for good visibility. However, most of the volume comes from routine families and the answers to critical questions are not found in these families. Families such as directory change control are scoped carefully because they can generate high volume.

The right measure is not volume, but scope of questions: how many of the specific questions the organization needs to answer can be answered with the current scope? This criterion also prioritizes decisions to expand the collection architecture.

3. Defense & Detection

Telemetry scope

• Keep a line for each critical question: the question, the machine role expected to produce the answer, the required control subcategory, and the SACL scope if necessary.
• Periodically report control subcategory configuration by machine role; Don't settle for a category-level statement.
• Also verify the status of the policy setting that allows subcategory settings to override old category settings.
• Document SACL coverage for critical directory containers; Let it be written which principal and which access types are controlled.
• Track system audit-policy changes with Event 4719 and non-AD file/registry SACL changes with Event 4907, keeping their scopes separate. For AD object changes, validate the subcategory and attribute-specific Write Property audit ACE in the object’s SACL required for Event 5136; do not treat any of these events as proof that every SACL remains in scope.
• Expect domain controller-specific event families only from DC sources; write the search in client resources into the inventory note.

Events and relevant fields

• Just because a subcategory is active does not mean that all relevant events will be generated; In object access families, SACL is the second condition.
• The absence of directory change events does not prove that the directory has not changed; Changes outside the scope of SACL are not recorded.
• The absence of a Kerberos ticket event on the client machine is not a configuration error; These families are produced on domain controllers.
• Event 4719 reports a system audit-policy change; an authorized policy deployment can also produce it. Event 4907 covers non-AD object SACL changes, not AD objects. Neither event alone establishes whether the change was authorized or proves complete current coverage.
• Just because a machine does not appear in the central collector does not mean that no events are generated on that machine; The transmission layer is a separate source of faults.

Start telemetry inventory with question

Most organizations keep their telemetry inventory as a source list: which servers are being logged from, which channels are being collected. This list is necessary but not sufficient. Operational value comes when the list becomes a question-based map.

The map is in the following format: 'How do I verify whether an account is logged in to a particular server?' The source machine role, required subcategory and storage period are written opposite the question. If this line cannot be filled out, it means that question cannot be answered today and this is a risk register.

Prove scope, don't assume

The declared version of the control configuration may differ from the version implemented on the machine. Policy conflicts, subcategory priority setting status, and local configuration differences are typical reasons for this divergence. Therefore, the scope should be read from the machine and not from the policy document.

The same discipline applies to SACL. Security identifiers of critical containers are read periodically to verify that the expected audit ACEs are in place. This verification is the only basis that makes 'no record' in a review meaningful.

Detection logic · KQL

// SACL changes on non-AD objects such as files/registry; not run. Does not cover AD object SACL changes.
SecurityEvent
| where TimeGenerated > ago(30d)
| where EventID == 4907
| project TimeGenerated, Computer, Account, ObjectName, ObjectType
| order by TimeGenerated desc

Query assumptions

• This KQL is a format example and was not run; verify the SecurityEvent table and Account/ObjectName/ObjectType fields in the actual workspace.
• Event 4907 reports SACL changes on non-AD objects such as files or registry keys; Microsoft states that this event is not generated for Active Directory objects.
• This query covers only Event 4907 records that reach the collector. It does not report AD DS object SACL changes or changes on uncollected machines.

False positives

• Planned file/registry SACL hardening can produce Event 4907 records; match them to authorized change records.
• No Event 4907 result does not show that AD object SACLs were unchanged or that coverage is complete.

Hardening

• Define the audit policy at the subcategory level and verify the applied values ​​on the machine; The declaration and the applied value are two different things.
• For critical index containers, keep the SACL scope narrow and purposeful; Assess volume impact before expanding scope.
• Write the telemetry inventory question-based; Source listing alone is not proof of visibility.
• Match audit setting changes to authorized change records; Any changes that do not match are examined.
• Plan domain controller log volume separately; Directory change checking can generate high volume and affects retention time.
• Track scope changes in a version-controlled document; 'Since when do we see it?' The answer to the question is required for every review.

Read the examples

O:DAG:DAD:AI(A;CI;RPLCLORC;;;AU)(A;CI;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)S:AI(AU;CISA;WPWDWO;;;WD)(AU;CIFA;WP;;;S-1-5-21-4071847660-1138144873-2902452632-1174)

Two reality checks

Assumption: Since the audit policy is open, all relevant transactions are recorded in the Security channel.

In fact: No. It is a necessary, but not the only, condition in the object access and directory change families that the audit subcategory is active: if a suitable audit ACE is not found on SACL of the relevant object or container, no event is generated. Additionally, if the policy setting that allows subcategory settings to replace old category-based settings is not in the expected state, the detailed configuration that was thought to have been applied may be ineffective. In both cases, the system does not error; only registration does not occur.

Assumption: Since we have collected all the logs in the center, I can find the event I am looking for in any source.

In fact: No. The event is raised on the machine performing the operation. Kerberos authentication service and service ticket events are generated only on domain controllers; Directory object changes are also recorded in the domain controller that processes the change; The session occurrence appears on the accessed machine. Centralized aggregation does not eliminate this source separation, it just brings the records together. Therefore, the 'no record' result becomes meaningful by first verifying that the correct source is looked at and that the scope is active at that time.

Sources

• Microsoft · Advanced security audit policy settings
  The audit is divided into subcategories under main categories and event families are linked to the subcategories.
• Microsoft · Audit: Force audit policy subcategory settings to override audit policy category settings
  Description and effect of the policy setting that allows subcategory settings to override category-based settings.
• Microsoft · Audit Directory Service Changes
  Subcategory only valid on domain controllers, SACL condition, modify/create/undelete/move/delete scope and high volume warning.
• Microsoft · 4907(S) Auditing settings on object were changed
  SACL change on objects such as files/registry keys; Microsoft explicitly states this event does not generate for Active Directory objects.
• Microsoft · 4768(S, F) A Kerberos authentication ticket (TGT) was requested
  The event is generated only on domain controllers and is connected to the Audit Kerberos Authentication Service subcategory.
• Microsoft · 4624(S) An account was successfully logged on
  Generation of the event on the accessed computer and field descriptions with logon type.
• Microsoft · 4719(S) System audit policy was changed
  Computer audit-policy changes; Category/Subcategory, SubcategoryGuid, and change fields.
• Microsoft · 5136(S) A directory service object was modified
  AD DS object-change event requires an appropriate an attribute-specific Write Property audit ACE in the object’s SACL ACE; Event 4907 does not generate for AD objects.
• Microsoft · SACL Access Right
  ACCESS_SYSTEM_SECURITY and enabled SE_SECURITY_NAME privilege; access to a SACL is not controlled by DACL entries.