Re: IWbemConfigureRefresher->AddEnum & AddObjectByPath return WBEM_E_ACCESS_DENIED

From: Ivan Brugiolo [MSFT] (ivanbrug_at_online.microsoft.com)
Date: 02/24/04 

Date: Tue, 24 Feb 2004 15:35:44 -0800

Your process is running as SomeDomaiun\SomeAccount,
and your process receives calls (over DCOM or RPC) from external client.
Do you impersonate the clients or not ?
>From the point of view of the RPC binding handle, a leaked impersonation
on some thread is as good as a legitimate CoImpersonateClient to confuse
things.
Do you attempt to perform any usage
of the IWbemServices / IWbemRefresher pointer from those threads ?
Have you changed the cloaking on the IWbemServices pointer in any way ?
Do you smuggle Interface pointers from apartment to apartment ?
There are quite few varialbes that are not known at this point.
WinMgmt uses the ACCESS_DENIEND code to tell you something like
"the identity performing the current operation is not the same as the one
who initiated the operation" 

-- 
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Steve" <steve.ramsdell@honeywell.com> wrote in message
news:f9595dad.0402241324.1feb0dcd@posting.google.com...
> This is happening within a COM server that is registered to run as a
> specific user account.  Whenever it processes an incoming COM call
> (the case where I am having a problem), there is a different
> "identity" involved, HOWEVER, I am not using impersonation or cloaking
> - the intention is to access WMI using the process identity (as
> registered by dcomcnfg).
>
> It would appear that WMI has different ideas, since the thread (even
> though not impersonating the COM client) is getting access denied from
> these two calls.  A spawned thread that has no COM context is able to
> make the two calls successfully.
>
> You asked if I had more than one identity in my process.  In the test
> case I am running, both the COM server process (that is getting the
> error) and the client process that calls the COM server are running as
> the same Windows user (the interactive user), so I would think it
> should be safe to say that no, I do not have more that one identity in
> my process.
>
> Steve
>
>
> "Ivan Brugiolo [MSFT]" <ivanbrug@online.microsoft.com> wrote in message
news:<u7BDvCj#DHA.488@TK2MSFTNGP12.phx.gbl>...
> > So, do you have more than one identity on your process or not ?
> > An if you have more than one identity, are you using Dynamic Cloaking,
> > or playing well with static cloaking ?
> >
> > -- 
> > This posting is provided "AS IS" with no warranties, and confers no
rights.
> > Use of any included script samples are subject to the terms specified at
> > http://www.microsoft.com/info/cpyright.htm
> >
> >
> > "Steve" <steve.ramsdell@honeywell.com> wrote in message
> > news:f9595dad.0402201249.636f9d60@posting.google.com...
> > > I guess I do not understand what you mean by "identity of the thread".
> > >
> > > There is no impersonation in effect at either the time of the creation
> > > of the IWbemServices interface, or at the time of the creation of the
> > > refresher interface.
> > >
> > > Is there another identity involved besides the process token and the
> > > thread (impersonation) tokens?  Is WMI somehow making use of the COM
> > > callers identity without any impersonation being done?
> > >
> > > I guess the answer to you question might be "yes".  The thread that
> > > creates the IWbemServices interface is an async thread during startup
> > > of my server, so there is no COM context to provide any identity other
> > > than that of the process.  That interface is used as long as the
> > > server process runs, (or until the target system goes down and the
> > > interface has to be recreated).  The thread trying to use AddEnum &
> > > AddObjectByPath is sometimes a background thread (in which case it
> > > works) and sometimes a thread handling an incoming COM call (where it
> > > gets WBEM_E_ACCESS_DENIED).
> > >
> > > Assuming this is a COM identity issue, is there a way around it?
> > >
> > > "Ivan Brugiolo [MSFT]" <ivanbrug@online.microsoft.com> wrote in
message
> >  news:<eafTyL29DHA.3452@TK2MSFTNGP09.phx.gbl>...
> > > > Could it be that the identity of the thread who has obtained the
> > > > IWbemServices
> > > > pointer and the one of the thread being used to add Enumeratos
> > > > to the refresher are different ?
> > > >
> > > > -- 
> > > > This posting is provided "AS IS" with no warranties, and confers no
> >  rights.
> > > > Use of any included script samples are subject to the terms
specified at
> > > > http://www.microsoft.com/info/cpyright.htm
> > > >
> > > >
> > > > "Steve" <steve.ramsdell@honeywell.com> wrote in message
> > > > news:f9595dad.0402191646.74aa32dc@posting.google.com...
> > > > > I am accessing WMI from a COM server.  When attempting to AddEnum
or
> > > > > AddObjectByPath in a thread that I have started myself, the calls
> > > > > succeed.  However, when I attempt to make these calls in a thread
> > > > > processing an incoming COM call, these calls fail returning
> > > > > WBEM_E_ACCESS_DENIED.
> > > > >
> > > > > Is there a way around this problem?
> > > > >
> > > > > At this point, in order to get somthing working, when I need to
make
> > > > > these calls, I test the returned HRESULT.  If it is
> > > > > WBEM_E_ACCESS_DENIED, I create and wait for a thread that does
nothing
> > > > > but the AddEnum or AddObjectByPath call and exits.  When I do
this,
> > > > > everything seems to be working.
> > > > >
> > > > > This is not a solution I am happy to live with, as in the course
of
> > > > > normal execution, this creates thousands of very short-lived
threads.
> > > > >
> > > > > Any help would be greatly appreciated.

Relevant Pages

  • RE: Impersonation with IPCChannel
    ... The Client uses WCF TCP Binding to the server. ... I am trying out impersonation with IPCChannel but for some reason it always ... throws an Access Denied Exception when I tried to connect to the port. ...
    (microsoft.public.dotnet.framework.remoting)
  • Re: Application Flow / security issues
    ... impersonation and makes it possible for the server process to access remote ... resources while acting as the client." ... because i assume the root of this problem is the application pool. ... You can set impersonation in the web.config. ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: CoImpersonateClient() always succeed
    ... DCOM security is mostly short-circuited when the client ... and the server are running on the same machine. ... > I'm trying to turnoff impersonation using CoInitializeSecurity. ... The client which provides the callback calls ...
    (microsoft.public.vc.atl)
  • passing impersonation token to out-of-proc COM server
    ... The client application uses LogonUser and ImpersonateLoggedOnUser to ... COM server uses CoImpersonateClient to change identity. ... Has anyone an idea on how to pass impersonation ...
    (microsoft.public.win2000.security)
  • Re: Question about Permissions
    ... > thread that would have the permissions matching what ... The topic in question is called "Client ... Impersonation" and is quite broad. ... impersonate the client as the operating system knows full well who is at the ...
    (microsoft.public.win32.programmer.kernel)