Troubleshooting Windows Server: Fix Error 0x138C & 5004 in Security Event Log Forwarding

Table of Contents

Windows Event Forwarding (WEF) is a powerful mechanism for collecting events from multiple source computers onto a central collector computer. This consolidation is crucial for security monitoring, analysis, and compliance. However, setting up WEF, particularly for sensitive logs like the Security event log, can sometimes encounter permission-related issues. Two specific errors, 0x138C on the collector and 5004 on the source, often indicate a problem with how the Event Collector service accesses the Security log on the source machine.

Understanding these errors and their root cause is essential for establishing a reliable event collection infrastructure. This article details the symptoms of these errors and provides a direct resolution to address the underlying permission deficiency that prevents successful security event log forwarding in Windows Server environments.

Symptoms¶

When attempting to configure and initiate event forwarding for the Security log channel from source servers to a designated collector server, administrators may observe specific error messages indicating a failure in the subscription or event retrieval process. These symptoms manifest on both the event collector and the event source computers involved in the WEF subscription.

On the event collector computer, typically within the Event Viewer logs related to Event Forwarding or the subscription status output, the following error message is encountered:

Error “0x138C” Windows Event Forward plugin can’t read any event from the query since the query returns no active channel.

This error code, 0x138C (which translates to 5004 in decimal, mirroring the source error), signals that although the collector is trying to retrieve events based on the subscription query, it is receiving no data streams or “active channels” from the configured source computers. This often points to a fundamental access or configuration problem on the source side that prevents the collector from establishing a connection capable of reading the specified log. The phrase “no active channel” misleadingly suggests a channel availability issue, but in this specific context, it frequently stems from a permission issue preventing the channel from being accessed in the first place by the service querying it.

Concurrently, on the event source computer where the Security log resides and is being configured for forwarding, the subscription fails to establish correctly. The error logged on the source computer provides a more direct clue regarding the nature of the failure. Administrators will typically find entries in the Event Viewer indicating a problem with the subscription creation or maintenance process initiated by the collector.

The specific error message observed on the event source computer is:

The subscription SubscriptionName cannot be created. The error code is 5004.

This error code 5004, often appearing in conjunction with the collector-side 0x138C, confirms that the attempt by the collector (acting through the WinRM service) to set up or service the forwarding subscription on the source computer was unsuccessful. This generic “subscription cannot be created” message, when linked with the 0x138C error on the collector and the context of Security log forwarding, strongly suggests a permission problem related to accessing the Security log data. It means the remote process initiated by the collector lacks the necessary rights on the source machine to read the Security event log data effectively. Identifying these twin errors is the first step towards diagnosing the specific permission misconfiguration detailed in the cause.

Cause¶

The root cause of these intertwined errors (0x138C on the collector and 5004 on the source) when forwarding the Security event log specifically lies in insufficient permissions granted to the process responsible for reading the log data on the source computer. Windows Event Forwarding utilizes the Windows Remote Management (WinRM) service to transport event data from source machines to the collector. WinRM, in turn, often operates under the context of the Network Service account when performing remote operations like querying event logs.

By default installations and configurations of Windows Server, the Network Service account (NT AUTHORITY\NETWORK SERVICE) typically possesses the necessary rights to read standard event logs. However, the Security event log is different. Access to the Security log is more tightly controlled due to the sensitive nature of the information it contains, such as logon/logoff events, audit trail data, and system security state changes. Permissions to access and manage the Security log are governed by a combination of factors, including default system Access Control Lists (ACLs) and specific user rights assignments.

A common way permissions for event logs are managed is through the security descriptor associated with the event log channel. This security descriptor is stored in the Windows Registry. For the Security log, this is found under the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Security. Within this key, a crucial registry entry is CustomSD, which holds the Security Descriptor Definition Language (SDDL) string defining who can access and manage the Security log and what permissions they have.

The problem arises when the default permissions for the Security log’s CustomSD value are modified. This modification can occur through various means:
1. Group Policy Objects (GPOs): Specific security settings within a GPO, particularly those related to “Manage auditing and security log” user rights, can inadvertently or intentionally override the default permissions applied to the Security log.
2. Manual Registry Edits: An administrator might have manually edited the CustomSD registry value directly.
3. Security Hardening Scripts/Tools: Some automated security configuration tools or scripts might modify registry permissions or user rights assignments without explicitly accounting for the needs of the Network Service account for event forwarding.

When these modifications occur, they might remove or fail to explicitly grant the necessary read permissions for the Network Service account on the Security log. The Network Service account requires the ability to read from this log channel to fulfill event forwarding requests coming via WinRM. Specifically, it needs the “Read” access right to the Security log. This right is typically granted via the Manage auditing and security log user privilege, or directly through the SDDL string in the CustomSD value. If the Network Service account lacks this specific permission because the CustomSD value has been modified and does not include it, the WinRM process running under this account will be denied access when it attempts to query the Security log for events requested by the collector. This access denial is what ultimately triggers the 5004 error on the source (subscription failure) and the subsequent 0x138C error on the collector (inability to read the “channel”).

The default CustomSD value typically grants read access to well-known accounts and groups, including the Network Service account. However, deviations from this default, often driven by overly restrictive security configurations, are the primary cause of this issue. Ensuring the Network Service account is correctly assigned the necessary permissions, either through the Manage auditing and security log user right or by correcting the CustomSD value, is the key to resolving these errors and enabling successful security event log forwarding.

Resolution¶

To resolve the 0x138C and 5004 errors and enable successful security event log forwarding, the Network Service account must be granted the necessary permission to read the Security event log on the source computer. The most straightforward and recommended method to achieve this is by assigning the “Manage auditing and security log” user right to the Network Service account. This user right, represented internally by the SeSecurityPrivilege, inherently grants the ability to read and clear the security log, which is exactly what the WinRM process operating under Network Service needs for event forwarding.

You can assign this user right using either the Local Security Policy editor on individual source servers or, for larger environments, via a Domain Group Policy Object linked to the Organizational Units (OUs) containing your source servers. Using Group Policy is highly recommended for consistency and scalability across multiple machines.

Here are the steps to assign the “Manage auditing and security log” user right using the Local Security Policy editor:

1. Open the Local Security Policy editor on the affected source computer. You can do this by typing secpol.msc in the Run dialog box or by navigating through the Start menu: Start > Administrative Tools > Local Security Policy.
2. In the navigation pane of the Local Security Policy window, expand Local Policies, and then select User Rights Assignment.
3. In the details pane on the right, scroll down and locate the policy named Manage auditing and security log. This policy controls which accounts can read and modify the security log.
4. Right-click the Manage auditing and security log policy and select Properties.
5. In the policy’s Properties dialog box, go to the Local Security Setting tab.
6. Click the Add User or Group… button.
7. In the “Select Users or Groups” dialog box, type NETWORK SERVICE in the “Enter the object names to select” field. Click Check Names to verify the name (it should resolve to NT AUTHORITY\NETWORK SERVICE), and then click OK.
8. Verify that NT AUTHORITY\NETWORK SERVICE is now listed in the “Users and groups” list on the Local Security Setting tab.
9. Click Apply, and then click OK to close the policy properties.
10. Close the Local Security Policy editor.

If you are implementing this change via a Domain Group Policy Object, the steps are similar, but you will use the Group Policy Management Editor. You would edit a GPO linked to your source server OUs, navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment, and modify the “Manage auditing and security log” setting there. Add NETWORK SERVICE to the list of accounts defined in the GPO policy setting.

After applying the change (either locally or via GPO), the security configuration on the source computer needs to be refreshed for the change to take effect. If you modified the Local Security Policy, the change is usually immediate or takes effect after a short delay. For changes made via Domain Group Policy, you should run gpupdate /force from a command prompt on the source server to explicitly refresh the group policy settings. This ensures that the new user right assignment is applied to the system’s effective policy.

Assigning the “Manage auditing and security log” user right programmatically translates into modifying the security descriptor (the CustomSD value) for the Security event log in the registry to include the necessary access control entry (ACE) for the Network Service account. The SID for the Network Service account is S-1-5-20. The required access mask for reading is typically included when this user right is granted. While you could manually edit the CustomSD registry value to add an ACE for S-1-5-20 with read permissions, this is not recommended as manually editing SDDL strings is complex and prone to errors that could lock out legitimate access. Using the dedicated user right assignment method is safer and best practice. The user right assignment method handles the correct SDDL modification automatically. Once the user right is assigned and policy is applied, the Network Service account will have the necessary permissions to read the Security log, allowing the WinRM service to successfully collect events for the WEF subscription, thereby resolving the 0x138C and 5004 errors.

Verification¶

After implementing the resolution by assigning the “Manage auditing and security log” user right to the Network Service account, it is crucial to verify that the fix has been successfully applied and that event forwarding is now functioning correctly. Verification steps should be performed on both the source and collector computers.

First, ensure that the policy change has taken effect on the source server. If you used Local Security Policy, the change should be immediate. If you used Group Policy, verify that the policy has been applied by running gpresult /r or gpupdate /force and checking the output. You can confirm the user right assignment using the secedit command-line tool. Export the current security configuration to a text file using the command secedit /export /cfg C:\temp\security_config.inf. Open the generated .inf file and search for the SeSecurityPrivilege setting. Verify that *S-1-5-20 (the SID for Network Service) is listed among the accounts granted this privilege. Alternatively, you can use PowerShell to inspect the local security policy database, though this is more complex. A simpler check is to verify the CustomSD registry value at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Security. While direct manual SDDL interpretation is difficult, applying the user right should result in an ACE for S-1-5-20 ((A;; 0x2;;;NS) or similar within the SDDL string, representing Network Service having read access).

Next, confirm that the WEF subscription on the collector is now active and receiving events. On the event collector computer, open Event Viewer and navigate to Applications and Services Logs > Microsoft > Windows > Event Forwarding > Operational. Look for events indicating successful connection attempts to the source computer and successful event delivery. Events with IDs like 105 or 104 typically signify successful forwarding and delivery.

You can also check the status of the subscription using the wecutil command-line tool on the collector. Open an elevated Command Prompt and run wecutil gs SubscriptionName, replacing SubscriptionName with the actual name of your subscription. The output should indicate a “Status” of “Active” and show a non-zero number of “Events forwarded.” If the status shows “Inactive” or “Retry,” or if the event count is not increasing, investigate further. Check the “DeliveryMode” and “ConfigurationMode” to ensure they match your setup (e.g., “Push” or “Pull”).

On the source computer, check the status of the Windows Event Log service and the Windows Remote Management service, ensuring both are running. Also, examine the Event Viewer logs on the source, specifically in Applications and Services Logs > Microsoft > Windows > Eventlog-ForwardingPlugin > Operational. Look for events indicating that the forwarding plugin is successfully processing requests from the collector and retrieving events from the Security channel. Events with IDs like 100 or 101 might indicate successful communication with the collector or successful processing of events for forwarding. Conversely, look for any new error events that might point to a different issue if the original errors persist.

If, after assigning the user right and refreshing policy, the errors 0x138C and 5004 still appear, consider potential delays in policy application or replication (in a domain environment). Also, double-check that the WinRM service is properly configured and running on both the source and collector, and that necessary firewall rules are in place to allow WinRM traffic (HTTP on port 5985 or HTTPS on port 5986) between the machines. Although less common as the direct cause of these specific errors, network connectivity and DNS resolution issues between the source and collector can also prevent WEF from working correctly.

Related Troubleshooting Tips¶

While the primary cause of Error 0x138C and 5004 is often permission-related as described, other factors can interfere with Windows Event Forwarding. If applying the “Manage auditing and security log” user right does not fully resolve the issue, consider these additional troubleshooting steps:

1. WinRM Configuration: Windows Event Forwarding relies heavily on the Windows Remote Management service. Ensure WinRM is configured correctly on both the source and collector. On both machines, open an elevated Command Prompt and run winrm quickconfig. This command verifies the WinRM listener is running, checks firewall rules, and ensures the service is set to start automatically. Address any issues reported by the quickconfig tool. Ensure the WinRM service (WinRM) and the Windows Event Log service (EventLog) are running on the source, and the Windows Event Collector service (Wecsvc) is running on the collector.

2. Firewall Rules: Proper firewall rules must be in place to allow communication between the collector and source machines over the WinRM ports. By default, WinRM uses HTTP on port 5985 and HTTPS on port 5986. Ensure these ports are open in the firewall profile active on both the source and collector machines, allowing traffic in the correct direction (inbound on source for collector connections, outbound on collector to source). The winrm quickconfig command can configure basic firewall rules, but complex network setups or third-party firewalls may require manual configuration.

3. Network Connectivity and DNS: Verify that the collector can communicate with the source machine by name and IP address. Use ping and Test-NetConnection -ComputerName SourceServer -Port 5985 (or 5986 for HTTPS) from the collector to the source. Ensure DNS resolution is working correctly. If using FQDNs in subscriptions, verify they resolve correctly on both ends.

4. Authentication: WEF typically uses Kerberos authentication (when computers are in the same domain or trusted domains) or NTLM (for workgroups or cross-domain scenarios without trust). Ensure that authentication is succeeding. Kerberos issues can sometimes be tricky; verifying SPNs for the WinRM service or checking security event logs for Kerberos errors (Event ID 4624/4625 for logon/logoff results on the source) might provide clues. If using HTTPS for WinRM, ensure certificates are correctly configured and trusted.

5. Subscription Configuration: Double-check the WEF subscription configuration on the collector using wecutil es SubscriptionName to view settings. Ensure the source computer names are correct, the query is valid for the Security log (typically using the log name “Security”), and the “RunAs” account (if specified, though not common for this error) has necessary permissions.

6. Event Log Integrity: Although rare, ensure the Security event log file itself (C:\Windows\System32\Winevt\Logs\Security.evtx) is not corrupted or inaccessible. Check the properties of the Security log in Event Viewer on the source machine for any errors reported.

7. Security Software Interference: Occasionally, third-party security software (like intrusion prevention systems or host-based firewalls) might interfere with WinRM traffic or access to event logs. Temporarily disabling such software in a test environment (carefully and with proper change control) might help rule this out as a cause.

Addressing the specific permission for the Network Service account to access the Security log is the most common solution for Error 0x138C and 5004 in this context. However, a systematic troubleshooting approach considering the underlying infrastructure (WinRM, network, firewall, authentication) is essential if the initial fix does not resolve the issue.

Best Practices for Windows Event Forwarding¶

Implementing Windows Event Forwarding effectively and securely involves adhering to several best practices. These recommendations help ensure reliable event collection, simplify management, and enhance the security posture of your logging infrastructure.

1. Utilize Group Policy: For environments with multiple source computers, configuring WEF subscriptions via Group Policy is the most scalable and consistent method. GPOs allow you to centrally define source computer settings (like enabling the EventLog-ForwardingPlugin service and configuring the collector address) and collector settings (defining subscriptions). This prevents manual configuration errors and simplifies deployment.
2. Dedicated Collector(s): Designate specific server(s) as event collectors. Avoid placing other heavy workloads on these servers, as collecting events can consume significant CPU, memory, disk I/O, and network bandwidth, especially in large environments.
3. Separate Event Logs: If possible, forward events to a dedicated log file on the collector rather than mixing them with existing local logs. This makes analysis and management easier. The WEF configuration allows specifying a custom log file for forwarded events.
4. Secure WinRM Traffic: Whenever possible, configure WinRM to use HTTPS (port 5986) instead of HTTP (port 5985). This encrypts the event data during transit, protecting sensitive information. Implementing HTTPS requires deploying certificates on both source and collector machines, typically via a Public Key Infrastructure (PKI). Configure the WEF subscription and source settings to explicitly use HTTPS.
5. Filter Events at the Source: To reduce network traffic and collector load, use XPath queries in your subscriptions to filter events at the source computer before they are sent. Only forward the events you actually need for security monitoring or analysis. For example, filter out noisy informational events.
6. Monitor WEF Performance: Regularly monitor the performance of both source and collector machines, paying attention to CPU usage, memory, disk queues, and network utilization. Use performance counters specific to WinRM and Event Forwarding to identify bottlenecks. Monitor the Event Forwarding Operational log on the collector for any errors or warnings about subscription status or delivery issues.
7. Plan for Storage: Event logs can consume significant disk space on the collector. Plan storage capacity based on the volume of events being forwarded and your retention requirements. Consider implementing log archival or integration with a Security Information and Event Management (SIEM) system for long-term storage and analysis.
8. Regularly Review Subscriptions: Periodically review your WEF subscriptions to ensure they are still relevant, correctly configured, and functioning as expected. Remove old or unnecessary subscriptions.

By following these best practices in conjunction with addressing specific errors like 0x138C and 5004, you can build a robust and reliable Windows Event Forwarding infrastructure crucial for effective security monitoring and incident response.

Conclusion¶

Successfully forwarding security event logs is a cornerstone of a strong security posture, providing critical visibility into activities occurring across your Windows server environment. The errors 0x138C and 5004 during security event log forwarding are specific indicators that the Network Service account, under which WinRM operates to collect these logs, lacks the necessary permissions on the source machine. This is frequently caused by modifications to the Security log’s default access control permissions, often stemming from security policy configurations that override the default settings.

The resolution involves granting the Network Service account the crucial “Manage auditing and security log” user right. This can be efficiently achieved through Local Security Policy on individual servers or, more practically in scaled environments, via a carefully configured Group Policy Object applied to the relevant source computers. Implementing this user right ensures that the Network Service account possesses the SeSecurityPrivilege, granting it the ability to read the Security event log, thereby allowing Windows Event Forwarding to function as intended.

Following the steps outlined for resolving the permission issue and incorporating the verification steps ensures that the fix is applied correctly and event flow is restored. Furthermore, adopting broader best practices for Windows Event Forwarding, such as using Group Policy for configuration, securing WinRM traffic, and monitoring performance, will contribute to a more resilient and effective logging infrastructure overall. Addressing these specific errors and implementing sound practices empowers administrators to maintain comprehensive security monitoring capabilities essential for detecting and responding to security incidents effectively.

Have you encountered these specific errors in your Windows Event Forwarding setup? What troubleshooting steps did you find most effective in your environment? Share your experiences and insights in the comments below!