DCOM Rights Removal

Yep - DCOM permissions might be required by firewall-related service accounts, but this is not a requirement of Windows Firewall itself. The key question is what the particular service account is used for. Network firewalls and Windows Firewall do not inherently require DCOM permissions to perform their core firewall functions. However, third-party firewall products and their management agents, identity-mapping components, directory integrations, monitoring tools, or other auxiliary services may use WMI for functions such as user-to-IP mapping, event-log collection, remote management, or system discovery. WMI can use DCOM for remote communication, so removing the underlying DCOM permissions can break those functions.

For example, enterprise firewall products may use a service account to query Active Directory or Windows systems and obtain security or authentication information. If the product uses remote WMI for this purpose, the account may require the appropriate WMI/DCOM permissions. Similarly, an integration or management component may use DCOM for remote procedure calls. The presence of DCOM permissions on a firewall service account does not, by itself, prove that they are required, so the specific firewall product, account configuration, DCOM permissions, and associated applications need to be identified before removal.

If the permissions are actively being used, removing them could cause the affected WMI or DCOM operations to fail with Access Denied errors, potentially including error 0x80070005. Depending on the firewall product, this could result in loss of user-to-IP identity mapping, failure to collect Windows security or event-log information, failure of remote management functions, or failure of another application integration. You could also see DistributedCOM-related events such as Event ID 10016 or 10006 on affected systems. The impact is application-dependent and should not be assumed to be limited to the firewall service itself.

Before making the change, first determine exactly which DCOM permissions the accounts currently have and whether they are members of groups such as Distributed COM Users. Also identify the services, scheduled tasks, firewall agents, WMI namespaces, COM applications, CLSIDs/APPIDs, and management components that run under these accounts. Review the firewall vendor's documentation for the account requirements and determine whether the product uses WMI/DCOM, WinRM, a local agent, or another mechanism for its Windows integration.

Consider pre-checks that establish whether the accounts are actually making DCOM/WMI connections. Review existing Windows event logs and, where practical, enable appropriate auditing for DCOM/WMI activity and monitor it for a representative period. This is more reliable than assuming that a permission is unnecessary based solely on the account name or the fact that it is associated with a firewall. The monitoring period should cover normal operational activity, including scheduled firewall management, user authentication, reporting, synchronization, and other periodic functions.

You should also establish a baseline before changing the permissions. Verify that user-to-IP mapping, directory synchronization, event-log collection, firewall management, monitoring, updates, and any other functions associated with the accounts are working normally. If the firewall vendor provides a diagnostic or connectivity test for the service account, run it before and after the change.

Finally, perform the removal in a controlled pilot rather than removing the permissions globally. Test one account or a representative non-critical system first, then monitor the firewall application and Windows event logs for failures. Keep a documented rollback procedure so the original permissions can be restored immediately if a dependency is identified.

The main point is that DCOM permissions should not be considered automatically required or automatically unnecessary for firewall service accounts. If the account is used by a firewall component that relies on remote WMI/DCOM, removing the permissions can break that functionality. If the account has no active DCOM/WMI dependency, removing unused permissions should not affect the core firewall functionality.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

Hello Anant Bera,

Thank you for posting question on Microsoft Windows Forum!

Based on your query of DCOM right removal. Well! In fact, DCOM permissions are not inherently required for Windows Firewall itself. A firewall service account would normally not need DCOM rights merely because it operates a firewall. The permissions may instead be required by the firewall product/agent, its management service, WMI, monitoring software, or another component that runs under that account. On the other hand, WMI uses DCOM for remote connections, and that applications/services performing remote WMI operations can require Remote Launch, Remote Activation, Remote Access, and corresponding WMI namespace permissions.

Regarding the potential impact of removing DCOM permissions. Well! If DCOM permissions are revoked. The firewall might lose the ability to map IP addresses to Active Directory users. This directly affects policy enforcement based on user identity (e.g., "allow only Finance users to access this server"). Palo Alto's agentless User-ID uses WMI transport, which requires DCOM privileges. On the other hand, the firewall components that read security logs from domain controllers (for user mapping or threat detection) will fail. The service account typically needs Event Log Readers in addition to DCOM Users. Also, tools that manage the firewall via WMI or remote COM calls will be unable to connect. You may see errors such as "Access Denied" or DCOM error 1084 (server execution failed). If the firewall uses the service account to authenticate users or perform single sign-on against AD, removing DCOM permissions can cause login failures or force users to re-authenticate manually.

The following are points for recommended pre-checks and precautions:

• To inventory all consumers of the service account by identifying every firewall product, management console, and monitoring tool that uses the account. Check for WMI, RPC, and COM+ dependencies in their documentation and confirm whether the account is a member of the Distributed COM Users group, either directly or via nested groups.
• Monitor DCOM audit logs by enabling DCOM auditing on monitored Domain Controllers to verify whether these specific service accounts are initiating active DCOM calls.
• To conduct a phased rollout by revoking permissions on a single test account or non-critical Domain Controller during a controlled maintenance window and validate the firewall’s active user-mapping table (such as checking show user ip-user-mapping on Palo Alto or equivalent) to confirm session tracking remains intact.
• Having a documented rollback plan by exporting the current DCOM permission configuration via dcomcnfg before making changes. Know exactly how to re-add the account to the Distributed COM Users group and restore any custom launch/activation limits. At the same time, ensure you have a maintenance window and the ability to restart the firewall services or the server itself if needed.

For further reference.

• https://learn.microsoft.com/en-us/windows/win32/wmisdk/securing-a-remote-wmi-connection
• https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/dcom-machine-access-restrictions-in-security-descriptor-definition-language-sddl-syntax

Hope the above information is helpful!