Understanding group-based Event Log configuration:

Event Log settings are configured at the group level — meaning all clients assigned to a group share the same Event Log collection settings. This makes it straightforward to apply consistent collection policies across machines that serve the same role, such as all Domain Controllers or all SQL Servers, while using different settings for other groups.

Accessing Event Log configuration for a group:

1. In the left navigation menu, click Groups
2. Locate the group you want to configure
3. Click the ⋮ menu next to the group
4. Select Event Logs

Adding a Windows Event Log to a group:

1. From the Event Logs configuration screen, click Add Event Log
2. Select a log from the available list or enter the log name manually:

Common Windows Event Logs:

3. Configure the following settings for each log:

Enable/Disable: Toggle collection on or off for this log without removing it from the configuration. Disabled logs are not collected but their settings are retained for future use.

Include Event IDs: Specify which Event IDs to collect from this log. Leave blank to collect all Event IDs from the channel.

Example: 4624, 4625, 4672, 4720, 4726

Exclude Event IDs: Specify Event IDs to ignore even if they appear in the log channel. Use this to suppress high-volume or low-value events.

Example: 4634, 4648

Exclude Descriptions: Filter events by message content — events whose description matches the specified text will be suppressed.

4. Click Save

Recommended Event ID configuration:

The following Event IDs are recommended as a starting point for security monitoring. Your administrator should adjust this list based on your organization’s specific compliance and monitoring requirements.

Example group Event Log configuration:

The following example shows a recommended starting configuration for a Domain Controllers group:

Log: Security

Enabled: Yes

Include Event IDs: 4624, 4625, 4672, 4720, 4726, 4732, 4740, 4768, 4776, 5136

Exclude Event IDs: (none)

Description: Collect logon events, account changes, and privilege use

Editing an existing Event Log configuration:

1. Navigate to the group’s Event Logs configuration
2. Locate the log to edit
3. Click the expand arrow to view current settings
4. Click Edit
5. Modify the settings as needed
6. Click Save

Disabling a log without removing it:

To temporarily stop collecting from a log channel without losing its configuration:

1. Navigate to the group’s Event Logs configuration
2. Locate the log
3. Toggle the Enable switch to off
4. The log will not be collected until re-enabled

Best practices:

• Start with the Security log and the recommended Event IDs above before expanding to additional log channels
• Use Include Event IDs rather than collecting all events from a channel — this significantly reduces forwarding volume and SIEM ingestion costs
• Use Exclude Event IDs to suppress known high-volume, low-value events such as routine service account logons
• Create separate groups for different server roles (Domain Controllers, File Servers, SQL Servers) and configure Event Log settings appropriate to each role
• Test new Event Log configurations on a small group of non-production machines before rolling out to the full environment
• Enable Windows Advanced Audit Policy on monitored machines to ensure the relevant Security Event IDs are being generated — EventLogAgent can only collect events that Windows is actually logging

[Your administrator should review the Event Log configuration for each group regularly to confirm it remains aligned with your organization’s security monitoring and compliance requirements.]

Understanding audit policy logic:

Audit policies use a two-level rule structure:

Rule Sets: Each policy contains one or more Rule Sets. Rule Sets use OR logic — if any Rule Set within a policy matches an incoming event, the policy action is applied.

Conditions: Each Rule Set contains one or more Conditions. Conditions within a Rule Set use AND logic — all conditions in a Rule Set must match for the Rule Set to trigger.

This structure allows complex filtering logic to be expressed clearly:

Policy matches if:

  (Condition A AND Condition B)   ← Rule Set 1

  OR

  (Condition C AND Condition D)   ← Rule Set 2

ALLOW vs DENY:

Accessing audit policy configuration for a group:

1. In the left navigation menu, click Groups
2. Locate the group you want to configure
3. Click the ⋮ menu next to the group
4. Select Audit Policies

Creating a new audit policy:

1. Click Add Policy
2. Configure the policy details:
   • Policy Name — a descriptive name that clearly indicates the policy’s purpose (e.g., Suppress Service Account Logons, Alert Privileged Logons)
   • Action — select ALLOW to forward matching events or DENY to suppress them
3. Click Add Rule Set to add the first rule set
4. Enter a Rule Set Name (e.g., Service Account Pattern)
5. Add conditions to the rule set:
   • Click Add Condition
   • Select a Field from the available event fields:

• Select an Operator:

• Enter the Value to match against
• Click Save Condition

6. Add additional conditions to the same rule set as needed — all conditions in a rule set must match (AND logic)
7. Click Add Rule Set to add additional rule sets if needed — any rule set matching triggers the policy (OR logic)
8. Click Save

Example audit policies:

Example 1 — Suppress service account logons:

This policy suppresses routine service account logon events to reduce forwarding volume.

Policy Name: Suppress Service Accounts

Action: DENY

Rule Set 1: Service Account Pattern

  Condition: TargetUserName EndsWith “$”

  Condition: EventID Equals “4624”

Rule Set 2: Specific Service Accounts

  Condition: TargetUserName Equals “NT AUTHORITY\SYSTEM”

  Condition: EventID Equals “4624”

Example 2 — Forward privileged logon events:

This policy ensures privileged logon events containing specific privileges are always forwarded.

Policy Name: Alert Privileged Logons

Action: ALLOW

Rule Set 1: Admin Logon

  Condition: EventID Equals “4672”

  Condition: PrivilegeList Contains “SeDebugPrivilege”

Policy evaluation order:

Policies within a group are evaluated in the order they are listed. Consider the following when setting policy priority:

• Place more specific DENY policies before broader ALLOW policies to ensure targeted suppression works as intended
• Place critical ALLOW policies at a high priority to ensure important events are not inadvertently suppressed by a broader DENY policy
• Test policies against real sample events before activating them in production

[Your administrator should document the intended logic and business rationale for each audit policy so other administrators can understand and maintain them correctly.]

Editing an existing audit policy:

1. Navigate to the group’s Audit Policies configuration
2. Locate the policy to edit
3. Click the Edit icon
4. Modify the policy name, action, rule sets, or conditions as needed
5. Click Save

Enabling and disabling policies:

To temporarily suspend a policy without deleting it:

1. Locate the policy in the Audit Policies list
2. Toggle the Active switch to off
3. The policy will not be evaluated until re-enabled

Deleting a policy:

Deleting a policy is permanent. Consider disabling the policy instead if you may need it again in the future.

1. Locate the policy
2. Click the Delete icon
3. Confirm the deletion

Best practices:

• Use descriptive policy names that clearly indicate what the policy does and why — this is especially important for DENY policies where the intent may not be obvious
• Start with ALLOW policies focused on the events you want to collect before adding DENY policies to suppress noise
• Use DENY policies carefully — an overly broad suppression policy can silently drop security-relevant events
• Test new policies on a small non-production group before applying them to production machines
• Review audit policies regularly to ensure they remain appropriate as your environment and security requirements evolve
• Use the Regex operator for complex pattern matching where standard operators are insufficient
• Document the business logic behind each policy, particularly DENY policies, so the team understands what is being suppressed and why

[Your administrator should audit active policies across all groups periodically to confirm that no critical event types are being inadvertently suppressed.]

Understanding file auditing in EventLogCentral:

File auditing in EventLogCentral works through Windows Security event logs rather than a separate agent mechanism. Specifically it uses Windows Security Event IDs:

Because file audit relies on Windows Security event logging, Windows Object Access auditing must be enabled on monitored machines before file audit rules will generate events. Without this, EventLogAgent has nothing to collect regardless of how file audit rules are configured.

Rules are evaluated locally on each client — only matching events are forwarded to reduce network traffic and SIEM ingestion volume.

Enabling Windows Object Access auditing:

Before configuring file audit rules, confirm that Windows Object Access auditing is enabled on the target machines. This can be done via Group Policy:

1. Open Group Policy Management Console
2. Edit the GPO applied to the relevant machines
3. Navigate to:

Computer Configuration → Policies → Windows Settings →

Security Settings → Advanced Audit Policy Configuration →

Object Access

4. Enable Audit File System for Success and Failure
5. Apply the GPO

[Your administrator should confirm that Object Access auditing is enabled across all machines in groups where file audit rules are configured before expecting file audit events to appear in LT Auditor ^MP.]

Accessing file audit configuration for a group:

1. In the left navigation menu, click Groups
2. Locate the group you want to configure
3. Click the ⋮ menu next to the group
4. Select File Audit

Creating a file audit rule:

1. Click Add Rule
2. Configure the rule details:

Rule Name: A descriptive name for the rule:

Example: Monitor HR Documents

Example: Critical Config Files

Example: Finance Share Activity

Path: The full directory path to monitor on the client machine:

Windows examples:

C:\HR\Documents

C:\Windows\System32\config

\\fileserver01\shares\Finance

Recursive: Whether to monitor subdirectories within the specified path:

Operations: Select which file operations to monitor:

Include Patterns: File name patterns to include in monitoring. Leave blank to monitor all file types:

Examples:

*.docx, *.xlsx, *.pdf

SAM, SYSTEM, SECURITY

*.csv, *.txt

Exclude Patterns: File name patterns to exclude from monitoring — useful for filtering out temporary or system-generated files that create noise:

Examples:

~$*        (temporary Office files)

*.tmp      (temporary files)

*.log      (log files)

3. Click Save

Example file audit rules:

Example 1 — Monitor HR documents:

Rule Name: HR Documents

Path: C:\HR\Documents

Recursive: Yes

Operations: Read, Write, Delete, Rename, Permission Change

Include Patterns: *.docx, *.xlsx, *.pdf

Exclude Patterns: ~$*, *.tmp

Example 2 — Monitor critical Windows configuration files:

Rule Name: Critical Config Files

Path: C:\Windows\System32\config

Recursive: No

Operations: Write, Delete, Rename, Permission Change

Include Patterns: SAM, SYSTEM, SECURITY

Exclude Patterns: *.log, *.tmp

Example 3 — Monitor a sensitive network share:

Rule Name: Finance Share

Path: \\fileserver01\shares\Finance

Recursive: Yes

Operations: Read, Write, Delete, Permission Change

Include Patterns: (blank — monitor all file types)

Exclude Patterns: ~$*, *.tmp, Thumbs.db

Editing an existing file audit rule:

1. Navigate to the group’s File Audit configuration
2. Locate the rule to edit
3. Click the Edit icon
4. Modify the settings as needed
5. Click Save

Deleting a file audit rule:

1. Locate the rule in the File Audit list
2. Click the Delete icon
3. Confirm the deletion

Troubleshooting file audit:

If file audit events are not appearing in LT Auditor ^MP, work through the following checks:

Best practices:

• Always confirm Windows Object Access auditing is enabled before configuring file audit rules — without it no events will be generated regardless of rule configuration
• Be specific with monitored paths — targeting entire drives generates extremely high event volumes and significant performance impact on client machines
• Use Include Patterns to limit monitoring to file types most likely to contain sensitive data
• Use Exclude Patterns to filter out temporary files, log files, and other noise sources from the start
• Disable the Read operation for high-traffic directories if write, delete, and permission change monitoring is sufficient — read events can generate very high volumes on busy file servers
• Test file audit rules on non-production machines before deploying to production to assess event volume and performance impact
• Confirm the EventLogAgent service account has appropriate read access to any network shares included in file audit rules

[Your administrator should document all active file audit rules and the business rationale for each monitored path so the configuration is auditable and can be reviewed during compliance assessments.]

Understanding sender configuration:

Targets are created and managed centrally in the Targets section of EventLogCentral. The Sender configuration within a group simply assigns one of those pre-configured targets to the group. If no sender is assigned to a group, clients in that group use their default local configuration for forwarding.

Changes to a group’s sender assignment are applied to all clients in the group immediately — clients receive the updated forwarding configuration on their next heartbeat cycle.

Accessing sender configuration for a group:

1. In the left navigation menu, click Groups
2. Locate the group you want to configure
3. Click the ⋮ menu next to the group
4. Select Sender

Assigning a target to a group:

1. From the Sender configuration screen, select a configured target from the dropdown list
2. Click Update

All clients in the group will begin forwarding events to the selected target on their next heartbeat cycle (default: 5 minutes). Use Force Configuration Sync on individual clients from the Clients page if the change needs to be applied immediately.

Changing a group’s sender assignment:

To change the forwarding target for a group:

1. Navigate to the group’s Sender configuration
2. Select the new target from the dropdown list
3. Click Update

Changing a sender assignment redirects all future event forwarding from the group to the new target. Events already forwarded to the previous target are not affected.

Groups without a sender assigned:

If no sender is assigned to a group, clients in that group use their default local forwarding configuration. This may result in events being forwarded to an unintended destination or not forwarded at all, depending on the agent’s local configuration.

It is recommended to assign an explicit sender to every group to ensure consistent and predictable event forwarding across all clients.

Verifying sender configuration:

After assigning a sender to a group, verify that clients are forwarding events to the correct target:

1. Navigate to Clients in the left navigation menu
2. Select a client in the group
3. Click View Effective Configuration
4. Confirm the configured target matches the sender assigned to the group
5. In the LT Auditor ^MP Web UI, navigate to View and confirm events from clients in the group are appearing under the correct environment and category

Best practices:

• Assign an explicit sender to every group — do not rely on default local agent configuration for forwarding in production environments
• Use Force Configuration Sync on clients after changing a sender assignment if the change needs to take effect immediately rather than waiting for the next heartbeat
• Create a dedicated LT Auditor ^MP target in the Targets section and assign it as the sender for all groups that should forward to LT Auditor ^MP
• Verify event forwarding in the LT Auditor ^MP View module after any sender assignment change to confirm events are arriving at the correct destination
• If different groups need to forward to different destinations — for example, Domain Controllers to LT Auditor ^MP and workstations to a separate SIEM — create separate targets for each destination and assign them to the relevant groups

[Your administrator should document the sender assignment for each group and review it whenever targets are added, modified, or removed to ensure all groups are forwarding to the correct destination.]