E
Enquiring Mind
Hi there!
I have spent more time than I can afford trying to configure DCOM security
settings on two machines in a Workgroup network both running Windows XP SP2
Pro, so as to allow a Win32 client application on one computer to call
methods of a DCOM out-of-process (automation) server on another. Both
applications were developed by me, and work together when on the same
computer. Although I have disabled caller authentication and assigned
'Everyone' and 'Anonymous logon' to the list of users permitted to launch
and access the DCOM server, and opened appropriate exceptions in the
firewalls, I persistently get an 'Access is denied' error message, even
though the server does get launched when the client application tries to
connect to the remote COM object.
Due to the lack of clear documentation on the logic of how the DCOM runtime
handles the security settings, it's difficult to see where along the line
of DCOM security checks the access right is being denied. Consequently DCOM
is proving to be more trouble than it's worth so I will probably ditch it in
favour of another RPC technology. (Without clear documentation of the logic
by which DCOM security settings are handled, one has to proceed by following
step-by-step recipes posted on the internet. These usually afford little
understanding of what the the final behaviour will be, with the net effect
that one could end up with a set-up that is less secure than if there were
no operating system level security support whatsoever.)
So my question is this: how I can I roll back the DCOM setting changes that
I have applied using the Component Services administrative tool to the
default values set up by the initial Windows XP installation (without
falling back on System Restore)?
Thanks for any guidance.
Enquiring Mind
I have spent more time than I can afford trying to configure DCOM security
settings on two machines in a Workgroup network both running Windows XP SP2
Pro, so as to allow a Win32 client application on one computer to call
methods of a DCOM out-of-process (automation) server on another. Both
applications were developed by me, and work together when on the same
computer. Although I have disabled caller authentication and assigned
'Everyone' and 'Anonymous logon' to the list of users permitted to launch
and access the DCOM server, and opened appropriate exceptions in the
firewalls, I persistently get an 'Access is denied' error message, even
though the server does get launched when the client application tries to
connect to the remote COM object.
Due to the lack of clear documentation on the logic of how the DCOM runtime
handles the security settings, it's difficult to see where along the line
of DCOM security checks the access right is being denied. Consequently DCOM
is proving to be more trouble than it's worth so I will probably ditch it in
favour of another RPC technology. (Without clear documentation of the logic
by which DCOM security settings are handled, one has to proceed by following
step-by-step recipes posted on the internet. These usually afford little
understanding of what the the final behaviour will be, with the net effect
that one could end up with a set-up that is less secure than if there were
no operating system level security support whatsoever.)
So my question is this: how I can I roll back the DCOM setting changes that
I have applied using the Component Services administrative tool to the
default values set up by the initial Windows XP installation (without
falling back on System Restore)?
Thanks for any guidance.
Enquiring Mind