I have a third-party vendor providing a solution that uses a proprietary OPC server that runs as a user process (not a service). It launches when the Administrator account is logged in and an OPC client attempts to connect. As such, it runs AS Administrator.
My OPC client (on remote computer) runs under the SYSTEM account as a service. Unfortunately, with this configuration, my OPC client can't access the vendor's OPC server, because they are running under different credentials.
If I run my OPC client AS Administrator (on remote computer), I can browse the vendor's OPC server just fine, because both client and server are now running AS Administrator with identical credentials.
I'd prefer not to have my OPC client run AS Administrator - I'd like it to run AS SYSTEM, like most services do. I don't like having to custom configure MY systems to talk to third-party systems - I'd rather the third-party systems be responsible for talking to my systems as-is.
I've managed to get the vendor's OPC server running AS SYSTEM via psexec. Unfortunately, my OPC client (running AS SYSTEM) still can't see/connect to the OPC server.
DCOM is configured for 'Connect' and 'Identify', and the SYSTEM account is granted Local/Remote Launch/Activation permissions.
this document Kepware OPC config guide suggests that communication via OPC running AS SYSTEM should work.
Just for fun, I launched both the OPC Server and a portable Matrikon OPC client on the vendor's app server, via psexec, both running AS SYSTEM, both running in session 0, with interactive services enabled. Even in this situation, the OPC client, set to browse LOCALHOST, was unable to connect to the OPC server.
This is in a workgroup environment, though I don't think that is the problem.
I've done a bit of reading and as far as I'm aware, Session 0 isolation only 'isolates' services that have GUIs... nothing about network isolation..
What am I missing? Is it something simple?
0 Answers