DCOM launch and access rights problems (OPCEnum)
Peter
I faced some interesting effects concerning launch and access rights when
trying to get remote access from an OPC (OLE for process control) client on
one PC to an OPC server on another PC.
For reasons of simplicity, the PCs are called "client" and "server" and the
accounts used are called account "a" (with password "b") and account "c"
(with password "d"). All accounts used have admin rights.
In all scenarios described below an OPC client is running on "client",
OPCEnum and an OPC server(s) are running on "server". Background info for
those not familiar with OPC: When an OPC server is installed on a PC, it is
guaranteed that OPCEnum is installed there, too. It fulfils different tasks,
especially it can be asked to return a list of OPC servers (of some type -
there are different types of such servers) on that PC by seeking its
registry. It provides the corresponding CLSIDs and ProgIDs. This allows the
OPC client in a second step to use the CLSID of the desired server and
connect with it.
Scenario 1: Local scenario.
"client" and "server" are the same Win2000 PC. Everything works fine. No
access rights problems. I can get a list of installed OPC servers by
accessing OPCEnum. I then can connect the OPC client with any of these OPC
servers.
Scenario 2:
"client" is a Win2000 PC, "server" a WinXP Professional PC. Both are in the
same workgroup. Domains are not used. I installed the OPC server on "server"
, OPCEnum was installed by this procedure, too. Both PCs have the account
"a" with password "b". OPC client is run under "a" on "client". It can't
access OPCEnum on "server" because of E_ACCESSDENIED.
Scenario 3:
Vice versa: OPC client on WinXP, OPC server (some other OPC servers than in
scenario 2) and OPCEnum installed on Win2000. Both use the same account.
Everything works fine.
Scenario 2, analysis of the reason of E_ACCESSDENIED:
When the client is calling CoCreateInstanceEx(CLSID_OPCServerList...) to get
an IUnknown interface pointer (for OPCEnum), this normally results in an
E_ACCESSDENIED but can be influenced by changing the DCOM settings of
OPCEnum using dcomcnfg. If on the identity tab the default "user who starts
the application" is selected, E_ACCESSDENIED is the result. If however on
the identity tab some explicit user "a" with password "b" is selected and
the user is furthermore added to the list of users with launch rights on the
security tab, S_OK is the result. If however OPCEnum is already running on
"server" while CoCreateInstanceEx is executed, it needn't be launched again
and so S_OK will be the result in this special case even if on the identity
tab "user who starts the application" is selected.
Assuming I got an S_OK on the above and thus OPCEnum is launched and
running. When then trying to get a second interface pointer using e.g. hr =
pUnknown->QueryInterface( UUD_IOPCServerlist,.), I always get an
E_ACCESSDENIED. Using dcomcnfg again, I can add whatever user I want on the
security tab concerning access rights. The result won't change. If I
understand this correctly, QueryInterface is an access, no launch. And I
can't give the user "a" on "client" access rights since this simply can't be
selected on the security tab. Selecting "everybody" is not sufficient.
My conclusion of this was: user "a" on "client" and user "a" on "server",
both having the same password, are the same if "server" is a Win2000 PC and
are different if "server" is a WinXP PC. But a few days later I faced
further effects:
Scenario 4:
Same as scenario 3 ("client": Win XP, "server": Win2000, both in the same
workgroup), but using different accounts. OPC client on "client" is run
under an account "c" which does not exist on the "server". Normally, there
are no access rights for an OPC client on "client" to launch and access
OPCEnum on "server" in this case. It works, however, if we use dcomcnfg for
OPCEnum and define and select on the identity tab an explicit user "a" with
password "b" (this account exists on "server") and add this account on the
security tab in the lists for launch and for access rights.
But there seems to be a strange behavior. It seems that the authentification
level for OPCEnum should be set to "none". (At least in the OPCEnum on my PC
which is installed as an EXE this is the case. It is installed as local
server and residing in C:\WINNT\System32\Opcenum.exe.) If this auth level
setting is changed to some other value, I don't get access rights
(E_ACCESSDENIED) on OPCEnum when trying to access from the "client" PC.
Strangely, changing this setting back to "none" and retrying to connect from
the client still results in E_ACCESSDENIED. Reason: After this failed launch
attempt of OPCEnum with wrong settings for the authentification level
nevertheless an OPCEnum process is started and running on "server". After
this is killed via the task manager, the OPC client connect (with auth level
"none") to OPCEnum succeeds.
This disturbing OPCEnum process is only started and running if we got
E_ACCESSDENIED on trying to launch OPCEnum (via
CoCreateInstanceEx(CLSID_OPCServerList...) with a wrong auth level. It is
however not started if we got E_ACCESSDENIED with the correct auth level
"none" but without the correct user "a" on the identity tab. So there are
two different reasons for E_ACCESSDENIED resulting in two different
behaviours of OPCEnum. I am not sure if this is a problem of OPCEnum or DCOM
itself. The client can't see any difference since it in both cases gets an
HRESULT of E_ACCESSDENIED. Does anybody know more about this problem?
Scenario 5:
After the irritations of scenario 4 I went back to scenario 2, hoping that I
might gain access to OPCEnum (running on WinXP) when testing different
settings for the authentification level. And now the confusing thing
happened: I was always able to connect where a few days before I was
completely unable to connect. Any setting for the auth level worked here (in
contrast to scenario 4). It is even hard to get an E_ACCESSDENIED now: On
the security tab of dcomcnfg for OPCEnum in the list for the launch rights I
must explicitly forbid the administrators the launching to get
E_ACCESSDENIED. Interestingly, changing the auth level has no effects at
all. And I was unable to find a setting in which I get an E_ACCESSDENIED on
hr = pUnknown->QueryInterface( UUD_IOPCServerlist.) which I always got in
scenario 2.
Of course I wonder what may have happened to this WinXP PC in the meantime.
It is not my PC, but as far as I know there was only one thing changed
concerning DCOM and OPC: For test reasons I had installed a further OPC
server on this PC in the meantime (which I only tested locally since I had
given up remote testing after the frustrating experiences with
E_ACCESSDENIED). Now I am not sure whether in this case a new OPCEnum might
have been installed together with this server which may behave differently.
I've already seen different OPCEnum installations on other PCs. The one I am
now facing in scenario 5 is different from that from that mentioned in
scenario 4: It is a local service, too, but I can't find a local path for it
with dcomcnfg. Is it possible that different OPCEnums behave differently
concerning launch and access rights?
Last hypothetic scenario:
What about the following scenario: "server" and "client" are Win 2000 PCs,
different accounts are used on both. This so far is scenario 4 with
replacing WinXP on "client" by Win2000, but this should work as well here
since the "server" and not the "client" is critical here concerning OPCEnum
access rights. But now no more workgroups shall be used. The "client" shall
be in one domain and shall just be connected via a network cable with the
"server" which is in another domain. The client shall access the server via
its IP address. Is a DCOM connection from the OPCClient on "client" to
OPCEnum on "server" in this case possible, too?
Greetings from Germany,
Peter
Slava Gurevich
Please check out the following and see if that explains the behavior
you're observing:
Slava Gurevich
On Thu, 28 Aug 2003 13:03:09 +0200, "Peter" <Pete...@lycos.de>
wrote:
Peter
> Please check out the following and see if that explains the behavior
> you're observing:
>
> http://tinyurl.com/lgkw
>
> Slava Gurevich
Thank you, it explained at least one of the behaviours I observed: It
explained the difference between scenario 2 and scenario 5. In scenario 5
WinXP behaved like Win2000 because in the meantime the settings you
described in the given URL must have changed.
Greetings from Germany,
Peter
Alexander Nickolov
fallback to matching username/password pairs is by default disabled in
WinXP.
--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnic...@mvps.org
MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================
"Peter" <Pete...@lycos.de> wrote in message news:bin6h6$bcc0m$1...@ID-196326.news.uni-berlin.de...
Peter
news:egYDgIlb...@TK2MSFTNGP12.phx.gbl...
> It explains them all. Translated, it means that legacy NT
> authentication fallback to matching username/password
> pairs is by default disabled in WinXP.
Hi Alexander,
the behavior of OPCEnum which I described in scenario 4 of my original mail
was not explained by it as far as I understand this. But this seems to be a
problem of the OPCEnum implementation itself. Of course Slava's link
explained all the differences between Win2000 and WinXP I observed.
Greetings,
Peter
Frank Perry
I am having similar trouble with an app I'm working on. I
need to log data from a bunch of machines and can't get
the client to connect to remote machines using XP.
I tried changing the authentication as Slava suggested and
that has made a change but not for the better. In the
beginning, the calls to connect to the servers would
return right away with a fail. Now they take minutes to
return with a fail.
Did you find anything else that needed doing?
Thanks in advance.
Frank Perry
LavaLeaf Software
frank...@lavaleaf.net
>.
>
Slava Gurevich
Here is a few troubleshooting notes to help you:
Event Log:
----------------------
The most underappreciated and forgotten resource. Check it frequently
for specific information while debugging. It may be useful to clear
the logs in between the tests.
Authentication:
-----------------------
It may be helpful to enable auditing of logon events ( both success
and failure) via the security policy. Then you could see the identity
of the network callers as they are authenticated and seen by the
server machine by checking the security section of the event log.
In some cases, the server may make call-backs to the client while
trying to access data through the interface pointers the client passed
in either explicitly, or implicitly ( ex.: IIS intrinsics). Because
this causes the client machine(s) to effectively act as a server, it
may be helpful to enable auditing of the logon events on the client
machine(s) as well.
Authorization:
---------------------
Once the incoming call is authenticated as a particular user, you may
still experience problems related to authorization; the user may not
have the permission to access a particular resource such as files, COM
objects, the registry, etc.
To troubleshoot permissions problems I frequently use regmon and
filemon free utilities from www.sysinternals.com and make a trace
capture of the object(s) access while running the test.
Additionally, it is possible to enable auditing of the object access
via the security policy. After enabling object access auditing at the
policy level, it is necessary to enable auditing individually for each
object of interest (via that object's properties) -- this is turned
off by default to prevent generation of huge trace logs and system
slowdown.
Other issues:
----------------------
- Firewall interference. In some installation cases, the built-in
Windows XP firewall is enabled by default. Check the Advanced tab of
the network connection properties for all machines involved.
- default network authentication policy in Windows XP ( already
discussed). Should be switched to "Classic" at least for the
debugging.
- Network issues. The machines involved should be able to "see" each
other as well as other machines involved, such as DC, WINs and DNS
servers etc. It is important that the resolution is successful both
ways. Some simple tests include pinging by both IP and name in both
directions. Additionally all machines must support the same protocol
used for communications ( TCP/IP etc.)
- Problems with COM+ identity and role-based security.
- Windows Server 2003 should be configured in the role of Application
Server; this will enable DCOM which disabled by default for security.
This is by no means a complete list, but should be a good starting
point. If you're still unable to resolve the problem please post the
details of how your application is setup and I will try and help you
further .
Regards,
Slava Gurevich