Remote launch fails with E_ACCESSDENIED

[Paul Baker [MVP, Windows Desktop Experience]]

CoCreateInstance with a remote server name is returning E_ACCESSDENIED
before it even launches the remote server process. The client is Windows XP
SP2 and the server is Windows Server 2003. I am not calling
CoInitializeSecurity. The user is an administrator on both client and server
and the DCOM configuration and security settings are default, as far as I
know, and nothing looks wrong.

It works if I configure the AppID on both the client and server to run as
the "interactive user" (use DCOMCNFG) and the user is logged on to the
client and server console sessions. However, I get E_ACCESSDENIED if I
configure the AppID on both the client and server to run as "the launching
user", which is what I want (to avoid having to logon to the console session
or expose it to an interactive user).

Can anyone offer a suggestion on how to troubleshoot this?

Thanks,

Paul

[Sam Hobbs]

In the security (not OLE) programming newsgroup, they often say that a user
in one system is not the same in another system just because the names (such
as Administrator) are the same. So perhaps previous answers in the security
programming newsgroup will help.

"Paul Baker [MVP, Windows Desktop Experience]"
<paulrich...@community.nospam> wrote in message
news:%23ZA%23ELWqI...@TK2MSFTNGP06.phx.gbl...

[Paul Baker [MVP, Windows Desktop Experience]]

Thanks. This is a domain user and both machines are attached to the domain.
So I don't think that applies here.

Paul

"Sam Hobbs" <sam...@social.rr.com_change_social_to_socal> wrote in message
news:ueXcSaWq...@TK2MSFTNGP06.phx.gbl...

[Gerry Hickman]

Hi Paul,

Before going any further, can you try running this simple code from the
client - look out for word wrap!

// TestDCOM.js
// Get the Agent Version
var strCmp = "YourServer";
var oAgentInfo = new ActiveXObject("Microsoft.Update.AgentInfo", strCmp);
var strVersion = oAgentInfo.GetInfo("ProductVersionString");
WScript.Echo("Agent Version " + strVersion);

If this works, it means both computers are configured for DCOM and
remoting and points to a problem specific to the object you are trying
to launch - in that case we'd need full details of the object.

--
Gerry Hickman (London UK)

[Paul Baker [MVP, Windows Desktop Experience]]

Gerry,

Thanks. That script works (Agent Version 7.0.6000.381).

I am not sure what details of my DCOM server are relevant. I will offer some
further details and maybe you have specific questions?

These are 32-bit systems and 32-bit Win32 processes and the server is out of
process. It has a user interface, but can also function through a command
line interface or DCOM server in a non-interactive window station. I have
recently moved some interactive functions from the server to the client to
facilitate running the server non-interactively without loss of
functionality. DCOM does not even launch the process, so I won't go into the
details of classes, interfaces, etc. at this point.

Paul

"Gerry Hickman" <gerry...@newsgroup.nospam> wrote in message
news:OyPGhnXq...@TK2MSFTNGP02.phx.gbl...

[Paul Baker [MVP, Windows Desktop Experience]]

As you would probably guess, CoGetClassObject also fails with
E_ACCESSDENIED.

If I replace my EXE with a copy of Notepad.exe, it also fails to launch
that.

Paul

"Paul Baker [MVP, Windows Desktop Experience]"

<paulrich...@community.nospam> wrote in message news:...

[Brian Muth]

See if the following helps:

http://technet.microsoft.com/en-ca/library/bb457156.aspx

in particular pay attentin to the "DCOM Security Enhancements" section.

[Gerry Hickman]

Hi Paul,

The main point of my test was that we now know you have a client and
server that work perfectly for remote instantiation of a properly
written COM server (including the security involved), so the problem
appears to be with your specific object - either a design flaw or a
config flaw.

I find (in general) I can instantiate remote objects (that have been
designed for remoting) using DEFAULT security, even on Vista, so (in
general) you should not need to get bogged down in the fine details of
security. Obviously I've only ever tested servers that run without a UI!
A server with a UI is alien to me.

[Paul Baker [MVP, Windows Desktop Experience]]

Thanks. I also read about the same change in default access and launch
permissions in Windows Server 2003 Service Pack 1. However, the user is an
administrator and therefore has remote launch access under the default
permissions.

Please also see my reply to Gerry.

Paul

"Brian Muth" <bm...@mvps.org> wrote in message
news:ecNeoTiq...@TK2MSFTNGP02.phx.gbl...

[Paul Baker [MVP, Windows Desktop Experience]]

Yes, this makes sense. It is not even launching the process. It seems to me
like it is a configuration problem.

The registry entries look like this:

HKCR\<progid>\
@=<desc>
CLSID\
@=<clsid>
HKCR\<clsid>\
@=<desc>
LocalServer32\
@=<path>
ProgID\
@=<progid>
TypeLib
@=<libid>
Version
@=1.0

There is a type library and interfaces registered, but I don't think that
comes into play here.

I tried adding equivalent registry entries using different values for
<progid> and <clsid>, and I was able to create an instance of that class
just fine. So, it would seem that there is some configuration of the class
that causes it to fail but that I have yet to find in the registry or that
resides in another database that I am not seeing.

SysInternals Process Monitor proves that it is not even launching the
process (it logs all process creation). And it shows equivalent registry
access attempts and results for both the real Prog ID/CLSID and the test
ProgID/CLSID, the only difference (besides the values themselves) being that
when and only when it works, there is activity from the svchost.exe process
hosting the DCOM Launcher service.

If I use the Windows Server 2003 Service Pack 1 machine to create a remote
instance of the same class on the Windows XP Service Pack 2 machine, it
works just fine. And each machine is able to create a local instance just
fine.

Paul

"Gerry Hickman" <gerry...@newsgroup.nospam> wrote in message

news:eMLPlGjq...@TK2MSFTNGP02.phx.gbl...

[Paul Baker [MVP, Windows Desktop Experience]]

Sorry. This is obviously slightly inaccurate. I mean to say that it was able
to launch the process just fine. So it got further. Of course, the server is
not calling CoRegisterClassObject for the test class, so it times out with
CO_E_SERVER_EXEC_FAILURE.

Paul

"Paul Baker [MVP, Windows Desktop Experience]"

<paulrich...@community.nospam> wrote in message
news:%23AwjKtj...@TK2MSFTNGP03.phx.gbl...
[snip]

> I tried adding equivalent registry entries using different values for
> <progid> and <clsid>, and I was able to create an instance of that class
> just fine.

[snip]

[Brian Muth]

If I understand you correctly, you have found that if the client is Win 2003 Server SP1 and the server is Win XP SP2, the remote
object is successfully instantiated. However the reverse (where the client is WIn XP SP2 and the server is Win 2003 Server SP1) you
get an access denied.

Sanity check:

Is the user a member of the "Distributed DCOM Users" group? Using Component Services, right-click on "My Computer", "Properties",
"COM Security", and check the Access and Launch Permissions.

[Paul Baker [MVP, Windows Desktop Experience]]

The user is not a member of the "Distributed COM Users" group, but they are
a member of the "Administrators" group, which does give them remote launch,
activation and access permissions.

Today, it is working for some reason. I tried it again just to be sure where
I was at. But it is not working on three similar servers. I did find AppID
related registry entries I thought I had deleted. I made sure to delete them
all from all servers. I wonder if that is something to do with it. Maybe I
need to restart a service for it to take effect.

HKCR\AppID\<clsid>
HKCR\AppID\<exe>\
HCKR\CLSID\<clsid>\AppID

Paul

"Brian Muth" <bm...@mvps.org> wrote in message

news:OPKCr8jq...@TK2MSFTNGP06.phx.gbl...

[Paul Baker [MVP, Windows Desktop Experience]]

Hey! These registry entries were not present but were re-added someow while
I was testing one of the servers that fails:

HKCR\AppID\<clsid>
HCKR\CLSID\<clsid>\AppID

This registry entries was not and is still not present:

HKCR\AppID\<exe>\

Perhaps I should try restarting the DCOM Process Launcher service, but this
seems to require a reboot.

Paul

"Paul Baker [MVP, Windows Desktop Experience]"
<paulrich...@community.nospam> wrote in message

news:OpGdwStq...@TK2MSFTNGP03.phx.gbl...

[Gerry Hickman]

Hi Paul,

Paul Baker [MVP, Windows Desktop Experience] wrote:
> Hey! These registry entries were not present but were re-added someow while
> I was testing one of the servers that fails:
>
> HKCR\AppID\<clsid>
> HCKR\CLSID\<clsid>\AppID
>
> This registry entries was not and is still not present:
>
> HKCR\AppID\<exe>\

As I remember it, you don't usually need the EXE one, although I'm
mainly using DLLs, maybe your's is an EXE?

Look out for tools like OLEVIEW and DCOMCNFG, they will sometimes CHANGE
registry settings if they think they are wrong.

One thing I have for my DCOM testing is a quick remote registry checker
that tells me the exact keys on each remote server - at least you'd be
able to make sure they look correct. I've never needed to reboot to get
remote instantiation working. To set DCOM security to default, you can
just delete the security related values under your AppID

[Paul Baker [MVP, Windows Desktop Experience]]

I have been routinely checking and cleaning AppID and other registry
entries. Yes, I have been using OLEVIEW and DCOMCNFG, but nothing
consistently seems to add these entries and they have not appeared in about
a day of troubleshooting.

To summarise the current, odd, situation:

2003 SP1 (1) -> XP SP 2 ok always
2003 SP (2) -> XP SP 2 ok always

XP SP2 -> 2003 SP1 (1) ok now
XP SP2 -> 2003 SP1 (2) E_ACCESSDENIED
2003 SP1 (3) -> 2003 SP1 (2) launches does not return unless process forced
to terminate (does not time out with server execution failed) - could be
something to do with my implementation.

This is all a bit unspecific to troubleshoot through a newsgroup, I think. I
have all the tools I need at my disposal. I will let you know what I
discover. Thanks,

Paul

"Gerry Hickman" <gerry...@newsgroup.nospam> wrote in message

news:eVBtl8wq...@TK2MSFTNGP04.phx.gbl...

[Paul Baker [MVP, Windows Desktop Experience]]

I am close to a resolution now. There are at least two problems:

1. Turning on all auditing shows that Windows Firewall is blocking LSASS
listening on various UDP ports. When the DCOM Server Process Launcher
service cannot communicate with LSASS, it returns E_ACCESSDENIED and does
not launch the process. This is odd because Windows Firewall is shown to be
"Off" in the UI. Another odd thing is that nothing is logged in
C:\Windows\pfirewall.log. Disabling the Windows Firewall service prevents
this. I am still looking into this.

2. When the process launches, it sometimes terminates within a few seconds
because of my own sporadic bug. It eventually times out with a
CO_E_SERVER_EXEC_FAILURE (when I said it didn't time out, I wasn't waiting
long enough). Does anyone know what type of logon the DCOM Server Launcher
Process uses for a non-interactive logon? For some reason, the temp path is
C:\Windows\Temp\ instead of C:\Documents and Settings\<user>\Local
Settings\Temp\, which contributes to this bug.

Paul

"Paul Baker [MVP, Windows Desktop Experience]"

<paulrich...@community.nospam> wrote in message
news:OLxb784q...@TK2MSFTNGP02.phx.gbl...

[Paul Baker [MVP, Windows Desktop Experience]]

Regarding #1: I am posting to microsoft.public.platformsdk.security about
this.

Regarding #2: I am guessing that the temp path is C:\Windows\Temp, because
the process is launched by a service that runs under the Local System
account. If lpEnvironment==NULL is passed to CreateProcess, which I imagine
it is, it will get the environment of the parent process. Since the Local
System account has no profile, USERPROFILE will not be present.

Paul

"Paul Baker [MVP, Windows Desktop Experience]"
<paulrich...@community.nospam> wrote in message

news:ubyJqt6q...@TK2MSFTNGP03.phx.gbl...

[Kevin LZJ]

Hi, Paul,

I met similar problem before and unlukily remain unsolved so far. I
have a DCOM server, initially running under Windows 2000 Server. It worked
fine, with clients running under Windows 2000 Pro or XP Pro. However, when I
tried to move the DCOM sevrer to Windows server 2003, I got ACCESS DENIED
error when the client connects to the server (my DCOM Server run as a Windows
service). I did test it even I switch the Windows Fire Wall off, the problem
remains the same. I consulted some guys in MS, they replied that this belongs
to the scope of development, and if I want this resolved, I need initiate a
pay-case. And due to some reasons, I have it delayed till now. So I keep the
server running under Windows 2000 server all along.
However, I have tested such a case: that the DCOM server running under
2003, and the client running at the same machine, it worked fine. So I guess
this problem comes from the enhanced security by 2003 over 2000. But how to
fix it? I don't know.

Kevin

[Paul Baker [MVP, Windows Desktop Experience]]

I will follow up on this post if I ever get the time to have them remote
debug it and if it is ever resolved.

Paul

"Kevin LZJ" <Kevi...@discussions.microsoft.com> wrote in message
news:E5EDC7E2-0478-4766...@microsoft.com...

[Brian Muth]

"Kevin LZJ" <Kevi...@discussions.microsoft.com> wrote in message news:E5EDC7E2-0478-4766...@microsoft.com...

You need to tell us the security settings of the COM server, and the security context of the client in order to advise you, which
you haven't provided. Also under Windows 2003 ensure that the client user belongs to the "Distributed COM Users" group.

[Paul Baker [MVP, Windows Desktop Experience]]

True. Been there done that ;)

Paul

"Brian Muth" <bm...@mvps.org> wrote in message

news:%23WtpiRJ...@TK2MSFTNGP02.phx.gbl...

[Kevin LZJ]

Hi, Brian,

Our DCOM Server serves for some users acrossing multiple units within
an intranet. So, security is not
the most important thing we need to consider. Moreover, these users may
change the windows login user name &
password occasionally, so we switch off the DCOM security. On the server
site, we config the DCOM server to
user the interactive user account (indeed the administrator account) using
DCOMCNFG tool.
This is the server security config code :

void CServiceModule::Run ()
{
_Module.m_dwThreadID = GetCurrentThreadId () ;

// HRESULT hr = CoInitialize(NULL) ;
// If you are running on NT 4.0 or higher you can use
// the following call instead to make the EXE free threaded.
// This means that calls come in on a random RPC thread
HRESULT hr = CoInitializeEx (NULL, COINIT_MULTITHREADED) ;

_ASSERTE(SUCCEEDED(hr)) ;

m_pCCAppSvrApp = new CCCAppSvrApp ;

if (TRUE == GetApp()->InitAppServer () )
{
// This provides a NULL DACL which will allow access
// to everyone.
// CSecurityDescriptor sd ;
// sd.InitializeFromThreadToken() ;
hr = CoInitializeSecurity (NULL, 0, NULL, NULL,
RPC_C_AUTHN_LEVEL_NONE,
RPC_C_IMP_LEVEL_IMPERSONATE,
NULL, EOAC_NONE, NULL
) ;

if (SUCCEEDED(hr) )
{
hr = _Module.RegisterClassObjects (CLSCTX_LOCAL_SERVER |
CLSCTX_REMOTE_SERVER,
REGCLS_MULTIPLEUSE
) ;
if (SUCCEEDED(hr) )
{
VERIFY(COleObjectFactory::RegisterAll()) ;

LogEvent (_T("Service started")) ;

if (m_bService)
SetServiceStatus (SERVICE_RUNNING) ;

GetApp()->StartAllThreads () ;

MSG msg ;
while (GetMessage (&msg, 0, 0, 0) )
DispatchMessage (&msg) ;

AddToMessageLog (_T("Begin to revoke class objects") ) ;
_Module.RevokeClassObjects () ;
}
}
}

AddToMessageLog (_T("Begin to free CCAppSvrApp object") ) ;

delete m_pCCAppSvrApp ;

AddToMessageLog (_T("Begin to uninitialize COM")) ;

CoUninitialize () ;

AddToMessageLog (_T("Finish uninitialize COM")) ;
}

This is the client code for security :

// CoInitializeEx(NULL, COINIT_MULTITHREADED) ;
hr = CoInitializeEx (NULL, COINIT_APARTMENTTHREADED) ;
if (SUCCEEDED(hr) )
{
// Config COM Call Security to OFF。
hr = CoInitializeSecurity (NULL, 0, NULL, NULL,
RPC_C_AUTHN_LEVEL_NONE,
RPC_C_IMP_LEVEL_IMPERSONATE,
NULL, EOAC_NONE, NULL
) ;

if (SUCCEEDED(hr) )
{
bRes = CreateAppsvrIntf (strErrMsg) ;

if (FALSE == bRes)
{
strMsg = strErrMsg + "\n" ;

strText.LoadString (IDS_CONNECT_APPSERVER_FAILED) ;
strMsg += strText ;
strMsg += m_strPlsCheckSystem ;
}
}
else
{
strMsg.LoadString (IDS_SET_COMSECURITY_FAILED) ;
bRes = FALSE ;
}
}
else
{
strMsg.LoadString (IDS_COM_INIT_FAILED) ;
bRes = FALSE ;
}

if (!bRes)
{
AfxMessageBox (strMsg,
MB_OK | MB_ICONEXCLAMATION
) ;
}

in CreateAppsvrIntf () method, we create interface to server object, but we
get Access Denied error.
In detail, if we configure the windows firewall on, we get 0x800706BA error
(RPC server is not available),
and if we config the firewall off, we get 0x80070005 error (Access denied).

Thanks !

Kevin

[Kevin LZJ]

Hi, all

After discussion with MS support engineer, I found the real reason that
our DCOM client couldn't access the DCOM server with error code as
E_ACCESSDENIED: we need to add the "Anonymous Logon" account to the
permission list of DCOM activation and access.
MS support engineer just told me to add 2 registry to enable DCOM
activation logging, then DCOM will write information into System event when
DCOM activation fails, we then know the real reason why it fails and
re-config the DCOM security setting according to the log information.
We found that this 2 registry are very useful, but unfortunately they
are not enabled by default. They are :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\ActivationFailureLoggingLevel
--> Set to 1
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\CallFailureLoggingLevel -->
Set to 1

Of course we can find some knowledge base in MS website about the 2
registry, unfortunately we don't them before, and it's not easy to find them
in such a huge information database if you don't know the exact key word.

Hope this can help you to solve your problem. BTW, you need to reboot your
machine after adding the 2 registry.

Good Luck !

Kevin

[Paul Baker [MVP, Windows Desktop Experience]]

I wish Microsof had told me about these registry entries when they gave me
support. Hopefully, it would shed some light on launch failures too.

Remote launch fails with E_ACCESSDENIED:
http://groups.google.com/group/microsoft.public.win32.programmer.ole/browse_thread/thread/3dc75620d19decc1

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole:
http://msdn.microsoft.com/en-us/library/ms687309.aspx

I am going to try these registry entries when I get a chance.

Thanks,

Paul

"Kevin LZJ" <Kevi...@discussions.microsoft.com> wrote in message

news:D3587719-AF7E-4EB8...@microsoft.com...