Remote WMI queries succeed, but DCOM ComplexPing causes Event ID 4625 — how can this be prevented?

Question

Remote WMI queries succeed, but DCOM ComplexPing causes Event ID 4625 — how can this be prevented?

Rei Amuro 20

Microsoft's Open Specifications support team suggested posting this API question under the Win32 API tag.

Question

Our remote WMI queries succeed with explicit credentials, but packet captures show IOXIDResolver::ComplexPing authenticating with the client's local process account instead. The ping is issued by the DCOM/RPCSS runtime on our behalf, not by our code. We are asking about DCOM lifetime-management traffic, including ComplexPing requests with AddToSet and DelFromSet updates.

Is there a supported client-side API to obtain/configure the binding RPCSS uses for ComplexPing, or otherwise make its first authentication attempt use the explicit WMI credentials? If not, is this a documented limitation?

Environment and observations

Collector: Windows Server 2022, build 20348.5499, workgroup.
Windows service running under a local Administrator account; Java calls a C# DLL using System.Management over DCOM.
WMI credentials differ from the service account; collection interval: 180 seconds.

We observed this sequence:

ComplexPing authenticates with the client's local account and receives RPC fault 0x5 (access denied).
A subsequent ComplexPing without RPC authentication succeeds (S_OK).

Collection is unaffected; our problem is only that the first, failed attempt is recorded as Event ID 4625 on the target.

Two failed attempts matched Event ID 4625 on the target domain controller by source address, port, account, and timestamp. The events report Status 0xC000006D and SubStatus 0xC000006A.

In a separate saved test, three ComplexPing requests with DelFromSet=1 also received fault 0x5, followed by successful unauthenticated retries, and matched three 4625 events. The two Server 2022 events above instead involved AddToSet=1 and DelFromSet=0. We therefore do not assume that the failure occurs only during cleanup, or that a particular Dispose call directly triggers a ping.

Connection, enumeration, and cleanup

This simplified excerpt retains the cleanup structure of the baseline DLL path. It is not a standalone reproducer. Inputs come from the caller; event serialization, file output, row-limit/watchdog checks, error handling, and hosting code are omitted.


var options = new ConnectionOptions

{

    Username = username,

    Password = password,

    Authority = "ntlmdomain:" + domain,

    Impersonation = ImpersonationLevel.Impersonate,

    Authentication = AuthenticationLevel.PacketPrivacy,

    EnablePrivileges = true,

    Timeout = TimeSpan.FromSeconds(timeoutSec)

};

var scope = new ManagementScope(

    string.Format(@"\\{0}\ROOT\CIMV2", serverAddress), options);

try

{

    scope.Connect();

    var query = new ObjectQuery(wql);

    var enumerationOptions = new EnumerationOptions

    {

        Rewindable = false,

        ReturnImmediately = true

    };

    using (var searcher = new ManagementObjectSearcher(

        scope, query, enumerationOptions))

    using (var logs = searcher.Get())

    {

        foreach (ManagementObject log in logs.OfType<ManagementObject>())

        {

            using (log)

            {

                // Read and serialize the event here (omitted).

                // Row-limit and watchdog checks are also omitted.

            }

        }

    }

}

finally

{

    scope = null;

}

The using blocks show the cleanup points in our code. We do not equate them with immediate removal of all underlying DCOM references or immediate transmission of a ping. Setting scope to null clears this managed reference; it is not an explicit disconnect. The shortened excerpt has not independently been tested for the 4625 behavior.

Already tried and constraints

In a separate controlled test, CoInitializeSecurity succeeded with the WMI credentials in pAuthList, but the ping identity did not change. Prompt reference release did not consistently prevent the failures in our cleanup tests.

We need to retain the execution account, DLL/DCOM path, prompt reference release, and concurrent collection, without changing settings on monitored systems. Disabling auditing or filtering events does not meet the requirement.

We have read KB 2816192, but have not established whether its explanation applies to this ComplexPing sequence.

RLWA32 52,931 Reputation points

2026-09-25T08:06:57.1733333+00:00

Its been a while since I've looked at it but I think that if you want COM/DCOM to use an impersonation identity that cloaking needs to be used. This can be done on a per-process (CoInitializeSecurity dwCapabilities parameter EOAC_STATIC_CLOAKING or EOAC_DYNAMIC_CLOAKING or on a per-proxy basis with CoSetProxyBlanket function.

I don't know how this might be implemented in your particular environment.
Rei Amuro 20 Reputation points

2026-09-25T09:12:58.0633333+00:00

@RLWA32
Thank you for the suggestion — much appreciated. We had not looked at cloaking separately, so we will consider it alongside the helper-process test.
RLWA32 52,931 Reputation points

2026-09-25T09:35:34.96+00:00

@Rei Amuro You're welcome. I look forward to reading the results of your next round of testing.

Answer accepted by question author

0 additional answers

Your answer

RLWA32 52,931 Reputation points

2026-09-25T08:06:57.1733333+00:00

Its been a while since I've looked at it but I think that if you want COM/DCOM to use an impersonation identity that cloaking needs to be used. This can be done on a per-process (CoInitializeSecurity dwCapabilities parameter EOAC_STATIC_CLOAKING or EOAC_DYNAMIC_CLOAKING or on a per-proxy basis with CoSetProxyBlanket function.

I don't know how this might be implemented in your particular environment.
Rei Amuro 20 Reputation points

2026-09-25T09:12:58.0633333+00:00

@RLWA32
Thank you for the suggestion — much appreciated. We had not looked at cloaking separately, so we will consider it alongside the helper-process test.
RLWA32 52,931 Reputation points

2026-09-25T09:35:34.96+00:00

@Rei Amuro You're welcome. I look forward to reading the results of your next round of testing.

Answer 1

Percy Nguyen (WICLOUD CORPORATION) 80 Microsoft External Staff Moderator

Hi @Rei Amuro ,

Thank you for the detailed description and packet-level correlation.

Based on the Microsoft public documentation I reviewed, I have not identified a documented client-side API for obtaining or configuring the RPCSS-managed binding used for runtime-generated ComplexPing calls. However, I would not interpret this as confirmation that the behavior is a documented product limitation.

I would like to explain what I found in Microsoft’s documentation.

The DCOM specification identifies IObjectExporter as the interface used for OXID resolution, pinging, and server aliveness checks. The Pinging section specifies the RPC binding information and security settings used for SimplePing and ComplexPing, including the credentials of the security principal issuing the request. References: IObjectExporter Methods and Pinging. I read these as protocol requirements, rather than documentation of an application API for accessing RPCSS’s internal binding.
Microsoft describes CoSetProxyBlanket as follows: “Sets the authentication information that will be used to make calls on the specified proxy.” Reference: CoSetProxyBlanket. CoInitializeSecurity establishes the default security values for the process. Reference: CoInitializeSecurity. Based on these documented scopes, I would not assume that configuring the WMI proxy or supplying credentials through pAuthList controls the binding used for runtime-generated ComplexPing. I would therefore not present either change as a confirmed solution to your scenario.
KB 2816192 states: “The pass-through authentication is always attempted first, even if specific credentials are specified in the tool being used.” Reference: Failed logon event generated when running remote WMI command. However, I do not see a discussion of ComplexPing or the authenticated-failure -> unauthenticated-retry sequence in that article. I would treat it as relevant background, rather than confirmation of the cause of your specific sequence.

I would also suggest a client-side experiment if a separate helper process is acceptable.

One option worth evaluating would be to host the WMI/DCOM collection in a process created using CreateProcessWithLogonW with LOGON_NETCREDENTIALS_ONLY.

Microsoft documents that this flag retains the caller’s local token while creating a new logon session and using the supplied credentials as the process’s default network credentials. Reference: CreateProcessWithLogonW.

I would suggest testing whether ComplexPing issued on behalf of that helper uses those network credentials for its first authentication attempt. I would treat this as an unverified test candidate, not a documented or confirmed workaround, because the API documentation does not guarantee its effect on RPCSS-generated ping traffic.

If you choose to evaluate it, I would recommend an isolated A/B test to verify that:

WMI collection still succeeds.
ComplexPing is actually captured.
The first authentication attempt uses the intended identity and no longer produces the corresponding authentication failure and Event 4625.

I recognize that a helper process would change the hosting arrangement and may fall outside your requirement to retain the existing service/Java/DLL execution path.

If that hosting arrangement must remain unchanged, I would suggest requesting clarification from Microsoft’s Windows COM/RPC support team on whether a supported mechanism exists to control this binding, or whether the observed behavior is an acknowledged limitation. I cannot establish either conclusion from the public documentation reviewed so far.

Hope these information help. If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation.

Thank you.

Rei Amuro 20 Reputation points

2026-09-25T09:14:53.1033333+00:00

Thank you, Percy, for the careful review and for clearly separating documented behavior from untested candidates.

The LOGON_NETCREDENTIALS_ONLY suggestion fits what we have observed: the ping identity appears to follow the process's logon session, which the in-process settings we tried did not change. We plan to run an isolated A/B test with a helper process next week and will report the results here.
Percy Nguyen (WICLOUD CORPORATION) 80 Reputation points Microsoft External Staff Moderator

2026-09-25T09:23:21.4666667+00:00

Hi @Rei Amuro ,

Thanks for letting me know. Please update me when the testing is done.

And if you have any question during the test, feel free to post it here.
Rei Amuro 20 Reputation points

2026-09-29T07:56:29.75+00:00
Thank you, @Percy Nguyen (WICLOUD CORPORATION) and @RLWA32 , for your suggestions.

We tested the helper-process approach and dynamic cloaking, and the results helped us narrow down the behavior. Here is a summary of what we observed.

Test setup

A standalone harness that calls the same shipped C# DLL (System.Management over DCOM) through the same Java-to-.NET bridge and in the same order as our product. It is not the Windows service itself; it was started from an elevated interactive session under the local built-in Administrator.

Clients: Windows 11 and Windows Server 2022 (build 20348.5499), both workgroup.

Target: Windows Server 2022, workgroup, collected with the target's local administrator account (NTLM). The target's password differs from the client's local Administrator password.

On the Server 2022 client, the target's name was resolvable through a hosts file entry. We are investigating separately why this affected whether pinging occurred.

Evidence: packet captures on the client and the target's Security log (4624/4625), matched by source port.

A: baseline (no change)

WMI collection succeeded.

The first ComplexPing that creates a ping set (SETID=0) authenticated with the client's local account, received fault 0x5, and was retried without authentication (S_OK).

Each failed attempt matched one Event ID 4625 (0xC000006D / 0xC000006A) by source port.

B: helper process started with CreateProcessWithLogonW + LOGON_NETCREDENTIALS_ONLY, using the same credentials as the WMI connection

WMI collection succeeded, with record counts comparable to the baseline.

ComplexPing was captured, including the set-creating request (SETID=0).

That request authenticated with the supplied network credentials and returned S_OK. There was no fault and no 4625; the target logged 4624 instead.

Subsequent SimplePing/ComplexPing requests from the helper were also authenticated with the same credentials, and all succeeded.

Observed on both the Windows 11 and the Windows Server 2022 client.

Side note: in one run where the network-credential password was mistyped, the helper started and WMI collection still succeeded, but the ping failed and 4625 was logged for the supplied account. As documented, the credentials are not validated when the process is created.

Dynamic cloaking via CoInitializeSecurity

CoInitializeSecurity with EOAC_DYNAMIC_CLOAKING (S_OK), and each collection thread impersonated a LogonUser(LOGON32_LOGON_NEW_CREDENTIALS) token that was kept open for the lifetime of the process.

The DCOM activation request issued from the impersonating thread did use the token's network credentials.

However, ComplexPing still authenticated with the process's local account, received fault 0x5, and produced 4625.

Our reading: the credentials used for runtime-generated pings follow the logon session of the process, not the thread's impersonation token or the proxy settings. This is consistent with your reading of the documentation.

Considering the helper-process approach

The helper process worked exactly as you suggested, and we are now considering whether it could fit into our product. That said, we have a few reservations about adopting it as is:

Since network credentials are attached per logon session, we would likely need a separate process for each credential set, together with lifecycle management and inter-process communication.

CreateProcessWithLogonW cannot be called from a service running as LocalSystem, so the implementation would depend on the service account.

Starting processes for collection may offset part of the performance benefit that led us to collect in-process through the DLL.

Question

While we continue to evaluate the helper-process approach, we would like to ask whether there is a supported way to keep everything in the existing process. For example:

Could the client stop RPCSS from pinging the references it receives from a remote WMI connection? It would be acceptable for us if the server-side references are cleaned up by timeout.

Could the pings that RPCSS issues for our references use the same credentials we pass for the WMI connection, instead of the process's logon session?

For reference, we have already looked at CoSetProxyBlanket / pAuthList and cloaking (tested, results above), as well as MSHLFLAGS_NOPING, CoDisconnectObject / CoDisconnectContext, and IRpcOptions / IGlobalOptions (documentation only). We did not find a way to achieve either of the above with them.

If neither is supported, knowing that would also help us decide on our direction. And if this is better asked of the Windows COM/RPC support team, any pointer would be appreciated.

Scope and limitations: short test windows (minutes to about half an hour per condition), a single target, and the standalone harness rather than our service.

Thanks again for your help.
RLWA32 52,931 Reputation points

2026-09-29T08:37:20.01+00:00

Our reading: the credentials used for runtime-generated pings follow the logon session of the process, not the thread's impersonation token or the proxy settings.

@Rei Amuro If I remember correctly the token and related logon session created when using LOGON32_LOGON_NEW_CREDENTIALS belong to the caller, not the identity to be used for network activities.

Instead of using a helper process so configured is it possible to logon the user to be used for impersonation so that it gets its own token and related logon session that can be used in a cloaking test without a helper process?
Percy Nguyen (WICLOUD CORPORATION) 80 Reputation points Microsoft External Staff Moderator

2026-09-29T09:04:51.3066667+00:00

Hi @Rei Amuro ,

Thank you for running the A/B test and for reporting the results in this much detail.

For your first question, I have not found a supported way to do this from the client. MSHLFLAGS_NOPING is documented as applying "to an original object marshaling (as opposed to marshaling a proxy)," which places it with the party exporting the object rather than the party holding the reference. Reference: MSHLFLAGS. The protocol specification describes the same thing from the other direction: the SORF_NOPING flag is written into the object reference at marshal time based on the exporter's garbage-collection state. Reference: Marshaling an Object Reference.

In your scenario the object is exported by the WMI service on the target, so opting out would be a change on the monitored system. Given your constraint that those systems cannot be modified, I would treat this option as closed rather than untested.

Second, I have not identified a documented mechanism for this either. You already covered the candidates I would have checked. For completeness, the process-global properties exposed through IGlobalOptions are COMGLB_EXCEPTION_HANDLING, COMGLB_APPID, COMGLB_RPC_THREADPOOL_SETTING, COMGLB_RO_SETTINGS, and COMGLB_UNMARSHALING_POLICY; none of them relate to ping traffic or credentials. Reference: GLOBALOPT_PROPERTIES.

Your said that CreateProcessWithLogonW requires an account allowed to log on interactively is correct and documented, so I understand why it constrains the service account. One variation worth evaluating is obtaining a token with LogonUser using LOGON32_LOGON_NEW_CREDENTIALS, then launching the helper with CreateProcessWithTokenW, which is documented as requiring only the SE_IMPERSONATE_NAME privilege. Reference: CreateProcessWithTokenW.

The intent is to keep the network-only logon session that produced your working result while removing the dependency on an interactive-logon-capable service account. I would treat this as another unverified candidate rather than a recommendation, since the documentation does not describe its effect on RPCSS-generated ping traffic. If you evaluate it, the same A/B checks you already used would apply.

Please note that, on the per-credential process concern: pinging is documented as aggregating references machine-to-machine rather than per process or per object, with a single ping set ID sent periodically. If you proceed with multiple helpers, it may be worth measuring whether two helpers using different credentials against the same target produce independent ping sets, since that assumption affects how many processes you would actually need.

And on the hosts-file entry you are investigating separately: the client-side pinging algorithm groups object IDs by the string binding of the resolver they belong to. A change in how the target name resolves changes that binding, so I would consider a resolution-path difference a plausible explanation before looking for a separate defect. Reference: Pinging.

From the public documentation I have reviewed, I cannot confirm a supported in-process mechanism for either of your two questions. I also cannot state that the absence of documentation makes this an acknowledged product limitation, which is the distinction I would want to preserve. If you need a definitive answer on that point, the Windows COM/RPC support team is the right channel, and your A/B results would give them a strong starting position.

Thank you.
Rei Amuro 20 Reputation points

2026-09-30T05:57:13.2433333+00:00
@RLWA32

Thank you for pointing this out.

You are right that our cloaking test used a LOGON32_LOGON_NEW_CREDENTIALS token, so it does not show whether a token from an actual logon of that user would behave differently.

Our understanding of your suggestion is to try cloaking with a token representing the user whose credentials we pass to WMI, rather than a NEW_CREDENTIALS token that retains the caller's local identity. We interpreted this as calling LogonUser with LOGON32_LOGON_INTERACTIVE, then having the collection thread impersonate the returned token. As a first step, we checked whether our client could obtain such a token using the target's local account credentials.

What we ran

LogonUserW called via P/Invoke from an elevated Windows PowerShell 5.1 session (Add-Type):

[DllImport("advapi32.dll", SetLastError = true, CharSet = CharSet.Unicode)] static extern bool LogonUserW(string user, string domain, IntPtr password, int logonType, int provider, out IntPtr token); // logonType: 2 = LOGON32_LOGON_INTERACTIVE, 3 = LOGON32_LOGON_NETWORK // provider: 0 = LOGON32_PROVIDER_DEFAULT // On failure: Marshal.GetLastWin32Error() // On success: new WindowsIdentity(token).Name, then CloseHandle(token)

Setup

Client: Windows Server 2022 (build 20348), workgroup (not domain-joined), running as the built-in local Administrator.

Target: Windows Server 2022, workgroup. Its local Administrator has a different password from the client's local Administrator.

Logon auditing (success and failure) enabled on both machines.

Cases (each with both logon types)

Control: client's own Administrator, domain ".", client's password -> succeeded; token user was the client's Administrator.

Target account: user "administrator", domain = target computer name, target's password -> failed with ERROR_LOGON_FAILURE (1326).

Same user and password, domain "." -> failed with 1326.

Observations

The client's Security log recorded one 4625 for each failed call (Status 0xC000006D, SubStatus 0xC000006A).

The target's Security log, over a 30-minute window that includes the test and without filtering by source address, shows no 4625 and no logon event from the client.

If this matches what you had in mind, obtaining such a token would require an account for that user on the collector itself. We do not want to pursue a fix that depends on creating new accounts, since our product cannot require customers to create accounts on their collector for collection. For that reason, we have not run the cloaking test with such a token, and the conclusion in our previous post should be taken as applying only to the NEW_CREDENTIALS case.

If we have misunderstood your suggestion, for example if you had a different way of obtaining the token in mind, please let us know.

Thank you again for taking the time to look into this.
RLWA32 52,931 Reputation points

2026-09-30T08:47:19.8766667+00:00

@Rei Amuro Thank you for sharing the results of the LogonUserW testing. Impersonation and cloaking to avoid a helper process isn't practicable in the workgroup environment that you describe.

Cloaking aside, I do wonder what you might see if instead of running the service under a local Administrator account it ran as one of the built-in service accounts that exist on all systems.
Percy Nguyen (WICLOUD CORPORATION) 80 Reputation points Microsoft External Staff Moderator

2026-09-30T11:19:27.7833333+00:00

Hi @Rei Amuro ,

Thank you for the detailed tests and for clarifying their scope.

I agree with your distinction. These results show that the attempted LogonUser calls did not obtain the intended token in your configuration. They do not establish how cloaking would behave with such a token, because that part of the experiment was not reached.

LogonUser documentation states:

“You cannot use LogonUser to log on to a remote computer.” Reference: LogonUserW.

The same documentation specifies that using "." for lpszDomain validates against the local account database. Your "." test therefore checks the collector’s account database, not the target’s Administrator account. I would not interpret the failures as evidence that the target’s credentials are incorrect, particularly given your successful WMI collection using those credentials.

Given your requirement not to create additional collector accounts, I would not ask you to change the account configuration merely to complete this experiment. Based on the documentation I reviewed, I do not have an alternative token-acquisition method to recommend for this actual-user-token test in your unchanged workgroup setup.

For clarity, the variation I mentioned in my earlier reply, LogonUser(LOGON32_LOGON_NEW_CREDENTIALS) followed by CreateProcessWithTokenW, was a separate helper-launch experiment. It was not a proposed method for obtaining the target user’s actual identity for in-process cloaking. Your latest INTERACTIVE/NETWORK results therefore do not directly test that variation.

I should also correct one sentence in my previous reply: your earlier concern was the restriction on calling CreateProcessWithLogonW from a LocalSystem service, not a requirement that the service account be allowed to log on interactively. Reference: CreateProcessWithLogonW.

For now, I would retain your revised conclusion: cloaking with the NEW_CREDENTIALS token did not change the observed ping identity, while cloaking with an actual-user logon token remains untested. I would not extend that result into a claim that every form of cloaking is unsupported or ineffective.

Thank you.
Rei Amuro 20 Reputation points

2026-10-01T01:36:45.3366667+00:00

@Percy Nguyen (WICLOUD CORPORATION) @RLWA32

Thank you both for following up.

Percy, thank you for clarifying the CreateProcessWithTokenW variation and for the correction regarding LocalSystem. We agree with your summary of the current state: cloaking with a NEW_CREDENTIALS token did not change the observed ping identity, and cloaking with an actual-user logon token remains untested.

RLWA32, regarding the built-in service accounts: keeping the service's current account is one of our requirements, so we have not tested that configuration.

Our two questions have now been answered as far as the public documentation goes: we understand that there is no documented in-process way to stop the pings or to make them use the WMI credentials. We will therefore close this thread and accept Percy's answer. If we need a definitive answer, we will consider the Windows COM/RPC support channel, as Percy suggested.

Thank you again for your time and detailed guidance.