Professional OPC
Development Tools

logos

Access Denied on DASSIDirect

More
07 Apr 2020 16:46 #8357 by support
Yes, it is possible that this is the case.
The following user(s) said Thank You: csm

Please Log in or Create an account to join the conversation.

More
07 Apr 2020 10:47 #8356 by csm
Replied by csm on topic Access Denied on DASSIDirect
Hi,

Thanks for the additional input, that could be a helpful option.

The end result is still the same i.e. DCOM changes are required when using QuickOPC .Net, but other OPC Clients work without any DCOM changes.

Please Log in or Create an account to join the conversation.

More
06 Apr 2020 18:06 #8355 by support
Regarding "The only way the sample would work, is to ensure the login used by the remote OPC Server is also a local user in the Administrator group on the host system running XMLLogger.".

Isn't the reason why you needed to put that use into Administrator group because on the client computer, DCOM is configured to allow Administrator to access applications.

If you start DCOMCNFG on the client computer, navigate Console Root -> Component Services -> Computers -> My Comuter, right-click on My Computer, select Properties, switch to the COM Security tab and then in the Access Permissions group, make sure that the OPC server user is under "Edit Limits" and "Edit Default", does that help?

Regards
The following user(s) said Thank You: csm

Please Log in or Create an account to join the conversation.

More
02 Apr 2020 08:53 #8346 by csm
Replied by csm on topic Access Denied on DASSIDirect
Getting a service to work with QuickOPC is the final goal.

The original problem was connecting to the OPC Server on a remote machine from the XMLLogger sample, this scenario can be expanded to say that the remote OPC server is using a service login that is unknown to the host running the XMLLogger sample.

My testing so far has indicated that this is will never work with QuickOPC, although other clients (Matrikon, OPC Expert, and our native service) will work.

The only way the sample would work, is to ensure the login used by the remote OPC Server is also a local user in the Administrator group on the host system running XMLLogger. It was then possible to subscribe to data changes with default values for the QuickOPC security settings under SharedParameters.ClientParameters.

From what I have since read about CoInitializeSecurity and .NET, it appears to be impossible to control unless a "Native Shim" is used prior to loading a .NET Module. Would this be the approach we would need to take when writing a service with QuickOPC?

Stack Overflow

Please Log in or Create an account to join the conversation.

More
01 Apr 2020 19:07 #8344 by support
I did not know (not sure if you wrote it) that you project is a service.

Among many problems with DCOM, there is one with DCOM initalization: Whoever makes the call to CoInitializeSecurity first in the process, wins. Further calls cannot change it.

In hosted environments, it happens that the host calls CoInitializeSecurity before QuickOPC gets the chance. It then really does not matter what QuickOPC does - it is all ignored. This can very well be the case here.

Regards
The following user(s) said Thank You: csm

Please Log in or Create an account to join the conversation.

More
01 Apr 2020 15:41 #8340 by csm
Replied by csm on topic Access Denied on DASSIDirect
We want to capture a high volume of data changes from the OPC Server, so using asynchronous subscriptions has to be the way for this to work.

We were able to make this work by changing the OPC Server service to use a login that was also part of the local Admin group on the host system running the XMLLogger sample.

In our native application we initialise COM security as below. Our application can subscribe to OPC data changes without any requirement to change the OPC Server configuration. Is this something that can be replicated on the QuickOPC side?

CSecurityDescriptor sd;
sd.InitializeFromThreadToken();
hr = CoInitializeSecurity(sd, -1, NULL, NULL, RPC_C_AUTHN_LEVEL_PKT, RPC_C_IMP_LEVEL_IMPERSONATE, NULL, EOAC_NONE, NULL) ;

Please Log in or Create an account to join the conversation.

More
27 Mar 2020 09:36 #8331 by support
I do not have many more tricks in my sleeve.

Can you please try whether ReadItem/ReadItemValue methods work OK - and if not, whether they work OK when you set
client.InstanceParameters.Mode.AllowAsynchronousMethod = false;
Reason: Subscriptions (as in your code) need bi-directional DCOM calls. Asynchronous reads/writes need that as well. But synchronous reads/writes need just one direction. So, if synchronous read worked, we would at least know that it is the reverse direction (from server to client) which is causing the problem.

Thank you
The following user(s) said Thank You: csm

Please Log in or Create an account to join the conversation.

More
26 Mar 2020 08:52 #8330 by csm
Replied by csm on topic Access Denied on DASSIDirect
Thanks for your input with regard to the Identity setting. This is a "Workgroup" scenario, and the users have been synchronised between the machines, once the OPC Server is restarted we can re-test.

Irrespective of this Identity setting, there are 3 other OPC Clients that do work, is it possible to adjust Quick OPC settings to work in a similar way?

Please Log in or Create an account to join the conversation.

More
25 Mar 2020 18:26 #8325 by support
There are no "widest" settings - different setups may require different settings.

If the two (client vs. server) machines are not in the same Windows domain (specifically, if they are in Windows workgroup), then - unless security is left totally open, without any authentication - the user account used needs to be duplicated on both machines, meaning identical username and identical password.

Regards
The following user(s) said Thank You: csm

Please Log in or Create an account to join the conversation.

More
25 Mar 2020 12:27 #8319 by csm
Replied by csm on topic Access Denied on DASSIDirect
Thanks for the suggestion to use the GUID, but I'm getting the same results.

We have discovered that the remote OPC Server has DCOM "Identity" settings configured as "This User" and a specific user account, so it may be that this is the issue for Quick OPC. We will ask for this user to be added to the Client machine and re-test.

We still don't understand why all the other OPC Clients can subscribe to data changes with the current DCOM setup and the Quick OPC test application does not. What are the most "open" settings we can apply to the XMLLogger example?

Please Log in or Create an account to join the conversation.

Moderators: support
Time to create page: 0.289 seconds

      

 Recommend this on Google