System 800xA OPC DA security
I found, to my surprise, that domain users, not being members of any 800xA groups like Everyone, Operators, etc., can read and write to any OPC property in the control structure regardless of the property's permissions using a third party OPC client (e.g. Matrikon OPC Explorer) with AfwOpcDaSurrogate. Is it normal or we have some serious security issue with our 800xA?
Asked 2 months ago
Voted best answer
5
That does not sound right.
What are your DCOM settings for the afwdsopcsurrogate.exe?
Never use any administrator account for Identity (”Run as this user”) - doing so would cause what you describe. Verify active setting by examining the account by which the surrogate appear in the Task Manager.
The account used to run the surrogate should have as little authority as possible.
If read-only access is desired, the account only need to be member of the Everyone group in System 800xA user structure.
Once you have found the appropriate security for the running user you can start to lock down who can launch the surrogate process and become the running user.
Make sure to notice the difference between the Launching User and the Running User. The first decide who have access while the last govern what permission he reaches inside System 800xA.
The default setting for Identity, ”The launching user” is not valid for remote (DCOM) launch due to a Microsoft Security hole. You need to decide what account that the surrogate dresses as in case you must use DCOM. For local only access (=no DCOM), the default setting (The launching user) will still work.
Last, whatever Running User you set, security is still governed by your Security Settings (the Security Definition aspects). Enabling the Guest account (disabled by default) would allow anyone to connect. To write, operator permission is required by default but can be overridden.
What are your DCOM settings for the afwdsopcsurrogate.exe?
Never use any administrator account for Identity (”Run as this user”) - doing so would cause what you describe. Verify active setting by examining the account by which the surrogate appear in the Task Manager.
The account used to run the surrogate should have as little authority as possible.
If read-only access is desired, the account only need to be member of the Everyone group in System 800xA user structure.
Once you have found the appropriate security for the running user you can start to lock down who can launch the surrogate process and become the running user.
Make sure to notice the difference between the Launching User and the Running User. The first decide who have access while the last govern what permission he reaches inside System 800xA.
The default setting for Identity, ”The launching user” is not valid for remote (DCOM) launch due to a Microsoft Security hole. You need to decide what account that the surrogate dresses as in case you must use DCOM. For local only access (=no DCOM), the default setting (The launching user) will still work.
Last, whatever Running User you set, security is still governed by your Security Settings (the Security Definition aspects). Enabling the Guest account (disabled by default) would allow anyone to connect. To write, operator permission is required by default but can be overridden.
Add new comment