471,319 Members | 1,427 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,319 software developers and data experts.

Bug in ManagementScope.Connect?

Hello

I'm trying to connect to another server via WMI, and it works just
fine. But everytime it first tries to connect with the current user
credentials, which naturally don't exist on the remote server,
resulting in Failure Audit entries in the EventLog. After some googling
I discovered that this is a known problem, but nobody has a workaround.
So I thought I'd try again ;-)

Here's some sample code to demonstrate the behaviour:

using System;
using System.Management;

public class test
{
public static void Main()
{
ConnectionOptions opts = new ConnectionOptions();
opts.Username = "XXXXXXXX";
opts.Password = "XXXXXXXX";

ManagementScope scope = new ManagementScope(@"\\XXX\root\cimv2",
opts);
scope.Connect();
}
}

After running this code, the remote server has 2 entries each for event
ID 529 & 680.

I've tried all settings for ImpersonationLevel and Authentication, and
also setting Authority to "NTLMDOMAIN:<name of remote server>". And
using Kerberos authentication wouldn't help, as the servers are not in
a domain (which is the reason I need to use ConnectionOptions in the
first place).
The .NET version is 1.1.4322, and I've tested it on Windows 2003, 2000
and XP, and it's the same everywhere.
greetings,
markus

Dec 7 '05 #1
5 6958

<to********@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...
Hello

I'm trying to connect to another server via WMI, and it works just
fine. But everytime it first tries to connect with the current user
credentials, which naturally don't exist on the remote server,
resulting in Failure Audit entries in the EventLog. After some googling
I discovered that this is a known problem, but nobody has a workaround.
So I thought I'd try again ;-)

Here's some sample code to demonstrate the behaviour:

using System;
using System.Management;

public class test
{
public static void Main()
{
ConnectionOptions opts = new ConnectionOptions();
opts.Username = "XXXXXXXX";
opts.Password = "XXXXXXXX";

ManagementScope scope = new ManagementScope(@"\\XXX\root\cimv2",
opts);
scope.Connect();
}
}

After running this code, the remote server has 2 entries each for event
ID 529 & 680.

I've tried all settings for ImpersonationLevel and Authentication, and
also setting Authority to "NTLMDOMAIN:<name of remote server>". And
using Kerberos authentication wouldn't help, as the servers are not in
a domain (which is the reason I need to use ConnectionOptions in the
first place).
The .NET version is 1.1.4322, and I've tested it on Windows 2003, 2000
and XP, and it's the same everywhere.
greetings,
markus


Looks like Scope.Connect performs an additional authentication handshake
using the current process identity, the resulting logon session is not used
at all though, sure looks like a "bug".

Willy.

Dec 7 '05 #2
Willy Denoyette [MVP] schrieb:
Looks like Scope.Connect performs an additional authentication handshake
using the current process identity, the resulting logon session is not used
at all though, sure looks like a "bug".
So, does Microsoft have something like a bug submitting system where I
can report this?

Willy.


thanks and greetings,
Markus

Dec 7 '05 #3

<to********@gmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...
Willy Denoyette [MVP] schrieb:
Looks like Scope.Connect performs an additional authentication handshake
using the current process identity, the resulting logon session is not
used
at all though, sure looks like a "bug".


So, does Microsoft have something like a bug submitting system where I
can report this?

Willy.


thanks and greetings,
Markus


Sure, go to

http://lab.msdn.microsoft.com/productfeedback/

and post an issue to the .NET Framework product group.

Willy.

Dec 7 '05 #4
<to********@gmail.com> wrote:
Willy Denoyette [MVP] schrieb:
Looks like Scope.Connect performs an additional authentication handshake
using the current process identity, the resulting logon session is not used
at all though, sure looks like a "bug".


So, does Microsoft have something like a bug submitting system where I
can report this?


http://labs.msdn.microsoft.com/productfeedback

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Dec 8 '05 #5
> Sure, go to
http://lab.msdn.microsoft.com/productfeedback/
and post an issue to the .NET Framework product group.


Ok, I'll try that. Thanks for the link!
greetings,
Markus

Dec 8 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

6 posts views Thread by Jerry Orr | last post: by
reply views Thread by B111Gates | last post: by
9 posts views Thread by Adrian Dev | last post: by
reply views Thread by =?Utf-8?B?YXVsZGg=?= | last post: by
reply views Thread by federico | last post: by
reply views Thread by rosydwin | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.