PrivilegeNotHeld, .Net 1.1 sp1 bug, hotfix

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi...

One of our ops people was looking for a utility that would let him remotely
reboot machines in the farm, and he search the web for .Net samples how to do
this. He found a couple, including a nice one written by John O'Donnell, but
he couldn't get any of them to work. They all threw PrivilegeNotHeld errors,
not matter what privileges he did hold.

I googled PrivilegeNotHeld and found a reference to a very similar bit of
code with a note saying that framework 1.1 sp 1 introduced a bug which caused
the error to always be thrown regardless. Then the note referenced a kb
article (Q887814) which said it was a 1.1 sp1 hotfix that may or may not fix
this issue.

I've been searching msdn and google but can't find this particular kb
article. Anyone familiar with it? And whether it solves the problem?

Thanks
_mark
 
Hi Mark,

Based on my test, the code below works file.
The client is windows xp + sp2+.NET FW 1.1 SP1
The server is windows 2003 +SP1 + .NET FW1.1 SP1
You may have a try and let me know the result.
private void button1_Click(object sender, System.EventArgs e)
{
ConnectionOptions op = new ConnectionOptions ( ) ;
op.Username =@"domain\user"; //The domain\user is an administrator of the
machinename
op.Password ="Password";
ManagementScope scope = new ManagementScope("\\\\" + "machinename" +
"\\root\\cimv2", op ) ;
try
{
scope.Connect( ) ;
System.Management.ObjectQuery oq = new System.Management.ObjectQuery
("SELECT * FROM Win32_OperatingSystem");
ManagementObjectSearcher query1 = new ManagementObjectSearcher ( scope ,
oq ) ;
ManagementObjectCollection queryCollection1 = query1.Get ( ) ;
foreach ( ManagementObject mobj in queryCollection1 )
{
string [ ] str= { "" } ;
mobj.InvokeMethod("Reboot",str);
}
}
catch(Exception ex)
{
MessageBox.Show(ex.ToString());
}
}

BTW: The KB article is as the link below.
To fix the problem in the KB article, you may need to contact MSPSS to
obtain the hotfix.
FIX: A security token leak occurs when you use the System.Management
namespace and you set the ConnectionOptions.EnablePrivileges property to
true in a .NET Framework-based application
http://support.microsoft.com/?id=887814

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
 
"Peter Huang" said:
Hi Mark,

Based on my test, the code below works file.
The client is windows xp + sp2+.NET FW 1.1 SP1
The server is windows 2003 +SP1 + .NET FW1.1 SP1
You may have a try and let me know the result.
private void button1_Click(object sender, System.EventArgs e)
{
ConnectionOptions op = new ConnectionOptions ( ) ;
op.Username =@"domain\user"; //The domain\user is an administrator of the
machinename
op.Password ="Password";
ManagementScope scope = new ManagementScope("\\\\" + "machinename" +
"\\root\\cimv2", op ) ;
try
{
scope.Connect( ) ;
System.Management.ObjectQuery oq = new System.Management.ObjectQuery
("SELECT * FROM Win32_OperatingSystem");
ManagementObjectSearcher query1 = new ManagementObjectSearcher ( scope ,
oq ) ;
ManagementObjectCollection queryCollection1 = query1.Get ( ) ;
foreach ( ManagementObject mobj in queryCollection1 )
{
string [ ] str= { "" } ;
mobj.InvokeMethod("Reboot",str);
}
}
catch(Exception ex)
{
MessageBox.Show(ex.ToString());
}
}

BTW: The KB article is as the link below.
To fix the problem in the KB article, you may need to contact MSPSS to
obtain the hotfix.
FIX: A security token leak occurs when you use the System.Management
namespace and you set the ConnectionOptions.EnablePrivileges property to
true in a .NET Framework-based application
http://support.microsoft.com/?id=887814

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no
rights.

Peter,

Your code works, but the same code changed to reboot a local machine
doesn't.
Here is the adapted code, changes made are:
- removed ConnectionOptions because not needed/allowed for local machine
connections
- added scope.Options.EnablePrivileges = true; to enable the privilege
required to reboot/sutdown etc.
This option is NOT required/checked when executing a remote shutdown/reboot
....

//Begin code
ManagementScope scope = new ManagementScope("\\\\" + "." +
"\\root\\cimv2" );
try
{
scope.Options.EnablePrivileges = true;
scope.Connect() ;
System.Management.ObjectQuery oq = new System.Management.ObjectQuery
("SELECT * FROM Win32_OperatingSystem");
ManagementObjectSearcher query1 = new ManagementObjectSearcher ( scope
,oq );
ManagementObjectCollection queryCollection1 = query1.Get ( ) ;
foreach ( ManagementObject mobj in queryCollection1 )
{
string [ ] str= { "" } ;
mobj.InvokeMethod("Reboot",str);
}
}
catch(Exception ex)
{
Console.WriteLine(ex.ToString());
}
}
// Code end

Here is the Exception stack.

System.Management.ManagementException: Privilege not held.
at
System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus
errorCode)
at System.Management.ManagementObject.InvokeMethod(String methodName,
ManagementBaseObject inPara
meters, InvokeMethodOptions options)
at System.Management.ManagementObject.InvokeMethod(String methodName,
Object[] args)
at Wmis.Main()

Note that this works with v2.0 Beta1 and Beta2 and v1.0 and v1.1, but fails
with v1.0 SP3 and v1.1 SP1.
The problem is that "Options.EnablePrivileges = true;" is a NOP, that is, it
doesn't enable the required privilege (I traced this in the debugger and
noticed that Wminet_utils.dll is the culpritt - see later) and this for ALL
methods that require the privileges to be enabled!!
I filed a bug for this at the time v1.1 SP1 and v1.0 SP3 was released, it's
status is closed/solved without any more info.

If you copy the v1.1 no SP version of Wminet_utils.dll to the v1.1 SP1
framework install dir. above code works as expected.

Finally, the question to be answered is - does the fix
(http://support.microsoft.com/?id=887814
) solves this problem too? If it does it should be mentioned in the KB, if
it doesn't the problem should be re-opened.


Willy.
 
Hi Willy and All,

I never got the privilege not held, but access denied errors for async
queries to the eventlog when using ConnectionOptions.EnablePrivileges. My
application logs the eventlogs from about 100 machines to a central DB, but
dies after .Net SP1. I contacted MS and got a hotfix, which solves the
problem, but is not publsihed as a KB.

Just FYI.

Best regards,
Manfred Braun

(Private)
Mannheim
Germany

mailto:[email protected]
(Remove the anti-spam-underscore to mail me!)

Willy Denoyette said:
"Peter Huang" said:
Hi Mark,

Based on my test, the code below works file.
The client is windows xp + sp2+.NET FW 1.1 SP1
The server is windows 2003 +SP1 + .NET FW1.1 SP1
You may have a try and let me know the result.
private void button1_Click(object sender, System.EventArgs e)
{
ConnectionOptions op = new ConnectionOptions ( ) ;
op.Username =@"domain\user"; //The domain\user is an administrator of the
machinename
op.Password ="Password";
ManagementScope scope = new ManagementScope("\\\\" + "machinename" +
"\\root\\cimv2", op ) ;
try
{
scope.Connect( ) ;
System.Management.ObjectQuery oq = new System.Management.ObjectQuery
("SELECT * FROM Win32_OperatingSystem");
ManagementObjectSearcher query1 = new ManagementObjectSearcher ( scope ,
oq ) ;
ManagementObjectCollection queryCollection1 = query1.Get ( ) ;
foreach ( ManagementObject mobj in queryCollection1 )
{
string [ ] str= { "" } ;
mobj.InvokeMethod("Reboot",str);
}
}
catch(Exception ex)
{
MessageBox.Show(ex.ToString());
}
}

BTW: The KB article is as the link below.
To fix the problem in the KB article, you may need to contact MSPSS to
obtain the hotfix.
FIX: A security token leak occurs when you use the System.Management
namespace and you set the ConnectionOptions.EnablePrivileges property to
true in a .NET Framework-based application
http://support.microsoft.com/?id=887814

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no
rights.

Peter,

Your code works, but the same code changed to reboot a local machine
doesn't.
Here is the adapted code, changes made are:
- removed ConnectionOptions because not needed/allowed for local machine
connections
- added scope.Options.EnablePrivileges = true; to enable the privilege
required to reboot/sutdown etc.
This option is NOT required/checked when executing a remote shutdown/reboot
...

//Begin code
ManagementScope scope = new ManagementScope("\\\\" + "." +
"\\root\\cimv2" );
try
{
scope.Options.EnablePrivileges = true;
scope.Connect() ;
System.Management.ObjectQuery oq = new System.Management.ObjectQuery
("SELECT * FROM Win32_OperatingSystem");
ManagementObjectSearcher query1 = new ManagementObjectSearcher ( scope
,oq );
ManagementObjectCollection queryCollection1 = query1.Get ( ) ;
foreach ( ManagementObject mobj in queryCollection1 )
{
string [ ] str= { "" } ;
mobj.InvokeMethod("Reboot",str);
}
}
catch(Exception ex)
{
Console.WriteLine(ex.ToString());
}
}
// Code end

Here is the Exception stack.

System.Management.ManagementException: Privilege not held.
at
System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus
errorCode)
at System.Management.ManagementObject.InvokeMethod(String methodName,
ManagementBaseObject inPara
meters, InvokeMethodOptions options)
at System.Management.ManagementObject.InvokeMethod(String methodName,
Object[] args)
at Wmis.Main()

Note that this works with v2.0 Beta1 and Beta2 and v1.0 and v1.1, but fails
with v1.0 SP3 and v1.1 SP1.
The problem is that "Options.EnablePrivileges = true;" is a NOP, that is, it
doesn't enable the required privilege (I traced this in the debugger and
noticed that Wminet_utils.dll is the culpritt - see later) and this for ALL
methods that require the privileges to be enabled!!
I filed a bug for this at the time v1.1 SP1 and v1.0 SP3 was released, it's
status is closed/solved without any more info.

If you copy the v1.1 no SP version of Wminet_utils.dll to the v1.1 SP1
framework install dir. above code works as expected.

Finally, the question to be answered is - does the fix
(http://support.microsoft.com/?id=887814
) solves this problem too? If it does it should be mentioned in the KB, if
it doesn't the problem should be re-opened.


Willy.
 
Manfred Braun said:
Hi Willy and All,

I never got the privilege not held, but access denied errors for async
queries to the eventlog when using ConnectionOptions.EnablePrivileges. My
application logs the eventlogs from about 100 machines to a central DB,
but
dies after .Net SP1. I contacted MS and got a hotfix, which solves the
problem, but is not publsihed as a KB.

Just FYI.

Best regards,
Manfred Braun

(Private)
Mannheim
Germany

Manfred,
IMO this isn't exactly the same problem, but as most of the security related
stuff is found in Wminet_utils.dll, chances are that both are related.
Anyway it's always best to check with PSS to see if fixes are available.

Willy.
PS. Could you check and post the version of this dll?
 
Manfred Braun said:
Hello Willy and All,

yes, of course:1.1.4322.1073 (engl.).,

Best regards,
Manfred

Great, this is an older version than the SP1 version (not 100% sure I guess
but the v1.1 without SP ), I hope you didn't have to pay for it.

Willy.
 
Hi

I am sorry for later response due to my sick leave the two days.
Based on my search we have confirmed this is a problem in our product and
it is planned to be fixed in Whidbey Beta2.
Since the KB887814 is applied to both .net 1.1 and 1.1 sp1, but the problem
occured only on 1.1 sp1.
I think it would better to contact MSPSS direct to ask for a hotfix for
this problem, because the hotfix is specifed to windows version, language
version.

Since we have confirmed this problem, the incident fee will be free of
charge.
Thanks!

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Smile ;-)
I never have noticed this, but it works ;-)

I had not to pay for it, because they confirmed this is abug ;-)

Regards,
Manfred
 
Back
Top