Error Publishing WMI Instance

[John Webb]

Thanks for reading and for any comments you have. The solution eludes
me…

Our application is instrumented with WMI. It contains 1 WMI Event
class and 1 WMI Instance class. We are getting an error in our staging
environment when we attempt to publish the instance. The problem does
not occur in our Dev environment. Also, the problem does not occur in
our Staging environment if the user credentials the app runs as are
part of the local administrators group.

In dev, we set the WMI security for the "USER" to Enable Account,
Remote Enable and Execute Methods on the root/cimv2 namespace and
subnamespaces, and the root\abc\xyz\mynamespace where the WMI Instance
schema is installed. The "USER" has modify access to the directory
structure in which the instrumented assemblies reside.

In stage, we set security up the same way. However, when the app
reaches the Publish() method, it fails with the following error
message:

Unhandled Exception System.Exception: This schema for this assembly
has not been registered with WMI.
at System.Management.Instrumentation.Instrumentation.Initialize(Assembly
assembly)
at System.Management.Instrumentation.Instrumentation.GetInstrumentedAssembly(Assembly
assembly)
at System.Management.Instrumentation.Instance.set_Published(Boolean
value)
at System.Management.Instrumentation.Instrumentation.Publish(Object
instanceData)
at Dell.DDW.DWS.StepProcessor.JobRunner.RunJob() in
c:\dws\buildmaster\middleware\03-11-2003-06-28-pm\build\JobRunner\JobRunner.cs:line
137
at Dell.DDW.DWS.StepProcessor.Class1.Main(String[] args) in
c:\dws\buildmaster\middleware\03-11-2003-06-28-pm\build\JobRunner\Class1.cs:line
75

//The code – m_Data is a
[InstrumentationClass(InstrumentationType.Instance)]
if(m_WMIPublishData)
{
//Publish Data Instance
System.Management.Instrumentation.Instrumentation.Publish(m_Data);
}

//installer
[assembly:Instrumented("root/abc/xyz/mynamespace")]
namespace abc.xyz.mynamespace
{

// . . .

If we move the "USER" into the local admins group on stage this error
does not occur. Also, this error does not occur in our development
environment where the "USER" is not part of the local admins group.

Also, though the error message above indicates that the schema has not
been registered, it really has been. As indicated by the successful
running of installutil on the instrumented assembly. The log file
indicates success. Also, we use CIM Studio to browse to the stage
server using the "USER' account credentials and verify that the WMI
instance definition for the object we are trying to publish does in
fact exist.

We need to be able to run this app in our staging and production
environment as the "USER" without admin privileges and still be able
to publish the instance.

Does anyone have any ideas what could be causing this?
Thanks for any help…

John

PS..

C#,Win2K SP3, .Net SP1

[Tejinder]

To write(publish) a new instance, as some user who is not part of admins,
you also need to set PARTIAL_WRITE permission on the namespace. 'Enable
Account' only gives read permission for the user

"John Webb" <john...@objecttoolbox.com> wrote in message
news:456da840.03031...@posting.google.com...

> Thanks for reading and for any comments you have. The solution eludes

> me.

> //The code - m_Data is a

> [InstrumentationClass(InstrumentationType.Instance)]
> if(m_WMIPublishData)
> {
> //Publish Data Instance
> System.Management.Instrumentation.Instrumentation.Publish(m_Data);
> }
>
>
> //installer
> [assembly:Instrumented("root/abc/xyz/mynamespace")]
> namespace abc.xyz.mynamespace
> {
>
> // . . .
>
> If we move the "USER" into the local admins group on stage this error
> does not occur. Also, this error does not occur in our development
> environment where the "USER" is not part of the local admins group.
>
> Also, though the error message above indicates that the schema has not
> been registered, it really has been. As indicated by the successful
> running of installutil on the instrumented assembly. The log file
> indicates success. Also, we use CIM Studio to browse to the stage
> server using the "USER' account credentials and verify that the WMI
> instance definition for the object we are trying to publish does in
> fact exist.
>
> We need to be able to run this app in our staging and production
> environment as the "USER" without admin privileges and still be able
> to publish the instance.
>
> Does anyone have any ideas what could be causing this?

> Thanks for any help.

[John Webb]

Well, that sounds reasonable except that in the dev environment, the
user "USER" does not have PARTIAL_WRITE and is not an admin and the
publish works fine there.

Also, in the staging environment, I gave the user, "USER", all of the
WMI permissions. The publish attempt still fails there...

Do you think I can rule out WMI permissions since I gave the user all
of them and the publish attempt still fails? Are there any other W2K
security privileges I should be giving the user?

Thanks...

John

"Tejinder" <teji....@verizon.net> wrote in message news:<#vHLnhP6...@TK2MSFTNGP12.phx.gbl>...

[John Webb]

Here is a little more information...

Dev Envirnment:
1. The user, "USER" has been totally removed from the Admin group
2. WMI security for the user, "USER", has been reduce to Enable
Account for the namespace in question
3. the user, "USER", has been granted full control to a single
directory structure which is not related to WMI. All other permissions
for the user have been removed.

Under these conditions, a Service running as the user, "USER", kicks
off the program which publishes the WMI instance. The publish attempt
is successful...

Stage Environment:

1. Same exact security is applied for user, "USER".

When the app attempts to publish the instance, this error occurs:

This schema for this assembly has not been registered with WMI.

If I make the user, "USER" and admin on the stage box, the publish
attempt is successful...

I have verified that the schema has in fact been registered. Both with
the WMI SDK CIM Object Browser and by viewing the WBEM directory
structure and by the fact that under the right conditions (user=admin)
the publish attempt works...

I have scanned the WBEM logs as well. They don't seem to offer any
useful information about the failure.

Searching the news groups caused me to believe the issue may be DCOM
related. Could this be the case?

john...@objecttoolbox.com (John Webb) wrote in message news:<456da840.0303...@posting.google.com>...

[John Webb]

Here is a little more information...

Dev Envirnment:
1. The user, "USER" has been totally removed from the Admin group
2. WMI security for the user, "USER", has been reduce to Enable
Account for the namespace in question
3. the user, "USER", has been granted full control to a single
directory structure which is not related to WMI. All other permissions
for the user have been removed.

Under these conditions, a Service running as the user, "USER", kicks
off the program which publishes the WMI instance. The publish attempt
is successful...

Stage Environment:

1. Same exact security is applied for user, "USER".

When the app attempts to publish the instance, this error occurs:

This schema for this assembly has not been registered with WMI.

If I make the user, "USER" and admin on the stage box, the publish
attempt is successful...

I have verified that the schema has in fact been registered. Both with
the WMI SDK CIM Object Browser and by viewing the WBEM directory
structure and by the fact that under the right conditions (user=admin)
the publish attempt works...

I have scanned the WBEM logs as well. They don't seem to offer any
useful information about the failure.

Searching the news groups caused me to believe the issue may be DCOM
related. Could this be the case?

john...@objecttoolbox.com (John Webb) wrote in message news:<456da840.0303...@posting.google.com>...

[Daniel Pravat [MSFT]]

The registration for your provider is restricted to administrators and some
special account like LOCAL_SERVICE, LOCAL_SYSTEM including
NT AUTHORITY\SERVICE. When your C# providers starts as service
S-1-5-6 is attached as group to your token and the providers works.
When the same user run the apps fails since the service group is missing.
You can attribute(InstrumentedAttribute.SecurityDescriptor ) your class
with another security descriptor specified in SDDL to include the user etc.

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

[John Webb]

Daniel,

Thanks for commenting on my post. Can you elaborate a little more on your
response? Are you saying that I should perform some additional attribution
to my instrumented classes because the app gets kicked off by a service?

thanks...

"Daniel Pravat [MSFT]" <dpr...@online.microsoft.com> wrote in message news:<eTTv7oo6...@TK2MSFTNGP12.phx.gbl>...

[John Webb]

Daniel,

Thanks again for your response. I spent some time trying to understand
what you are saying and I think I got it now. (maybe)

The assembly in which the instrumented objects reside was attributed
in this way;

[assembly:Instrumented("root/abc/xyz/mynamespace")]

You seem to be saying that the assembly should be instrumented in this
way;

[assembly:InstrumentedAttribute("root/abc/xyz/mynamespace", "SDDL
String")]

I am not sure I understand the difference between the two attributes,
Instrumented and InstrumentedAttribute... Both are in the docs and
seem to apply at the assembly level. Also they seem to overlap in
functionality since both accept a NameSpace string.

The documentation clearly indicates that if the SDDL String is not
provided, the default behavior will be that only members of the Local
Admin group will be able to publish instances or fire events for the
assembly.

This very well may be related to the issue I am having. Though it does
not explain why my dev environment is working without the user being a
part of the admin group...

I would like to give this a try by changing the way I attribute the
assembly but constructing the SDDL string seems extremely cryptic. So
before I go off learning SDDL, is there a utility that will construct
the string for me? It seems like I ought to be able to open a security
dialog and select some users and groups and get back an SDDL String...

Trudging on...

Any more comments would be greatly appreciated...

"Daniel Pravat [MSFT]" <dpr...@online.microsoft.com> wrote in message news:<eTTv7oo6...@TK2MSFTNGP12.phx.gbl>...

[John Webb]

Ok. I think we have resolved this problem. Thanks to Daniel for the
tip about including the SDDL string in the assemble attribute.

Apparently, I was using the wrong syntax in attributing my
instrumented assembly and was failing to provide the required SDDL
(Security Descriptor Definition Language) string. The SDDL String is
required because we intend to run the application under the
credentials of a user who is not a member of the local admin group.

I was attributing my assembly like this:

[assembly:Instrumented("root/abc/xyz/mynamespace")]
namespace abc.xyz

When I should have been attributing it like this:

[assembly:InstrumentedAttribute("root/abc/xyz/mynamespace",
"O:LAG:LAD:(A;;RPWPCCDCLCRCWOWDSDSW;;;DA)(A;;RPWPCCDCLCRCWOWDSDSW;;;SY)(A;;RPWPCCDCLCRCWOWDSDSW;;;WD)(A;;RPLCRC;;;AU)S:(AU;SAFA;WDWOSDWPCCDCSW;;;WD)")]
namespace abc.xyz

The cryptic SDDL string specifies exactly which users/groups will be
allowed to fire events and publish instances. In this case, the Domain
Admins, Local Admins and Everyone are indicated. I don't know how to
express a specific user account using the SDDL format. So Everyone was
used...

I am not 100% confident that we fully understand the issue but it
appears to be gone. We now get similar behavior in both our dev and
stage environments.

If anyone sees anything that sounds stupid, please let me know.
Learning and correctly using this technology is very important to
me...

thanks again all...

john...@objecttoolbox.com (John Webb) wrote in message news:<456da840.03031...@posting.google.com>...

[Daniel Pravat [MSFT]]

The problem you faced was:
1. The provider fails under userX identity when logon as service.
2. The provider works under userX identity when logon interactively.

Since the token were created by different entities, the token representing
userX in the first case is different that the second one.
The first token contains the service account S-1-5-6 (NT AUTHORITY\SERVICE)
while the second contains
the interactive group S-1-5-4 (Well Known Group: NT AUTHORITY\INTERACTIVE) .

The default SD on provider allows S-1-5-6 access to the providers, motivated
by the fact only Administrators can install a
service. This explain why is working on the service as user case.
With regards to complexity, I don't recommend a manual SD generation but a
runtime generation executed at install time.

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"John Webb" <john...@objecttoolbox.com> wrote in message
news:456da840.03031...@posting.google.com...