Is this a bug or a feature of ManagementScope?

Question

http://msdn.microsoft.com/en-us/library/system.management.connectionoptions.aspx

ConnectionOptions co = new ConnectionOptions();
co.Username = CreateUserName(Domain, Username);

If I use the previous code together with ManagementScope like this:

ManagementScope ms = new ManagementScope("\\\\" + PcName + "\\root\\cimv2:Win32_Service='RpcSs'", co);
ms.Connect();

But if I use incorrect Domain it still works? How should I correct this. Why is this happening?

Edit 1: This happens(I am allowed with bad domain and correct Administrator account and correct password) when I try to access a remote machine, which may have other credentials and other domain than my machine.

Edit 2: Bad domain in my case means: domain which does not exist on that machine or other domain in which the current user entered is not present.

Edit 3: Even if I use this code:

options.Authority = "ntlmdomain:DOMAIN";//this won't work either.

http://msdn.microsoft.com/en-us/library/system.management.connectionoptions.authority.aspx

Answer 1

WbemTest is the standard to know how WMI behaves. Addressing your comment (@Floradu88, May 15):

1) WbemTest fails on remote connections when passing invalid credentials (invalid domain)

That is the expected behavior, of course

2) WbemTest for local connection works "only without credentials"

It looks like this might not have trickled up into the documentation for ManagementScope and ConnectionOptions, but:

You cannot change credentials when connecting to the local computer.
(MSDN: WMI Tasks: Connecting to the WMI Service)

Remarks
Do not specify strUser, strPassword, or strAuthority when making a connection to a local namespace.
(MSDN: IWbemLocator::ConnectServer)

---

Regarding your original question, because you have said that WbemTest is behaving as expected, we know that WMI is "working" and it's not an edge case issue like the target machine having been configured to accept anonymous connections.

One possibility is that your C# WMI connection is using the credentials of the calling user, rather than the specified (invalid) credentials. Please try running the same code, but this time as a user on the local machine whose account does not exist on the remote machine. If that fails, it means that the caller's credentials were being used instead of the explicit credentials you wanted. Which, if it occurred, would suggest an error in your implementation of the calls to impersonate the manually specified credentials when connecting to the remote machine.