IWbemServices::CreateInstanceEnum return E_ACCESSDENIED

[howard]

hi folks,

I experienced some bizarre problems ... I installed the
provider in a stand-alone Windows XP box. To enable the
client applicaiton remotely connect to it, I created a
test account in administrator group on this box, I aslo
gave all the permissions on the "\root" and "\root\test"
namespace to the test account.

Before I lauched the client application, everything works
perfectly. Wbemtest can access the namespace ( query or
execute method) without any problem, no matter locally or
remotely. But the client applicaion failed to query the
class in "\root\test" from another machine. The client
application is built on the C++ COM API.

It's really a surprise as the application didn't have any
problem calling IWbemServices::ConnectServer with the test
account and password. But once the connection is set up,
IWbemServices::CreateInstanceEnum or
IWbemServices::ExecQuery returned E_ACCESSDENIED
(0x80070005)

This shouldn't be a credential problem, as
IWbemServices::ConnectServer() does not return any error.
And shouldn't be the permission problem on the provider,
as wbemtest can remotely query or execute without any
problem. I also looked at the log file of the provider,
IWbemInstProviderImpl::CreateInstanceEnumAsync() was not
called at all. The problem should happen at some point
before that.

The wbemcore.log looks like this

(Mon May 31 20:30:54 2004.57605593) : CFactory construct
(Mon May 31 20:30:54 2004.57605593) : CFactory destruct
(Mon May 31 20:30:54 2004.57605609) : CALL
ConnectionLogin::NTLMLogin
wszNetworkResource = \\192.168.50.175\ROOT\Test
pPreferredLocale = (null)
lFlags = 0x0
(Mon May 31 20:30:54 2004.57605609) : DCOM connection from
test\amtest at authentiction level Packet, AuthnSvc = 10,
AuthzSvc = 0, Capabilities = 0
(Mon May 31 20:31:48 2004.57659546) : DllCanUnloadNow was
called
(Mon May 31 20:31:48 2004.57659546) : DllCanUnloadNow is
returning S_FALSE

...

If anyone's ever seen this, pls give me a hint, any input
would be appreciated.

thanks
howard

[Ivan Brugiolo [MSFT]]

RPC_C_AUTHN_LEVEL_CALL need to be changed to
RPC_C_AUTHN_LEVEL_PKT ot RPC_C_AUTHN_LEVEL_PKT_PRIVACY
for WinXP, and it's accepted from Win2000 as well.
WinXP and above will not accept inbound calls at CALL authentication level

--
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

"Erik J Sawyer" <anon...@discussions.microsoft.com> wrote in message
news:10603252-D858-4117...@microsoft.com...
> I ran into something similar. Make sure you're calling CoSetProxyBlanket
on the WbemServices object before your query calls. It appears that the COM
security is tighter on XP, so you have to grant impersonation permission to
the proxy object. For example:
>
> hr = CoSetProxyBlanket(pWbemServices, RPC_C_AUTHN_WINNT, RPC_C_AUTHZ_NONE,
NULL, RPC_C_AUTHN_LEVEL_CALL, RPC_C_IMP_LEVEL_IMPERSONATE, NULL, EOAC_NONE)
>
> - Erik J Sawyer
>
> ----- howard wrote: -----

> ....

[Ivan Brugiolo [MSFT]]

if hte transport of the DCOM call is RPC-over-LPC,
then there is no per-call / per-packet authentication.
There is one for other DCOM transports.

Anyway, the original poster seems to have a different problem
where a DCOM access denied comes to play before any WinMgmt access-denied.

--
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

"Erik J Sawyer" <anon...@discussions.microsoft.com> wrote in message

news:15F70AFD-8493-499B...@microsoft.com...
> I was able to use RPC_C_AUTHN_LEVEL_CALL on WinXP, with a client running
as Admin against the local system. Does the requirement you described come
into play under different conditions?
>
> ----- Ivan Brugiolo [MSFT] wrote: -----