08/22/2022
Hello, I have downloaded the 109 version.
I used the OPC DA sample Client to perform my DCOM testing.
In file …\NET API\Sample Client\Da\MainForm.cs Line 878 there is loop for connecting to the OPC Server :
m_server.Connect(…)
The first time we execute this function, the connection doesn’t work because we are not providing credentials explicitly.
So the function “Allocate” from file …\NET API\COM Wrapper\OpcCom.Interop.cs doesn’t provide the pAuthInfo in the serverInfo structure:
Line 465 :
serverInfo.pAuthInfo = (credential != null) ? m_hAuthInfo.AddrOfPinnedObject() : IntPtr.Zero;
And so the RPC_C_AUTHN_LEVEL_PKT_INTEGRITY level is not set !
I would suggest to always set the pAuthInfo info into serverInfo structure:
serverInfo.pAuthInfo = m_hAuthInfo.AddrOfPinnedObject()
If no explicit credentials are provided then process credentials (eg current windows user credentials) are used for DCOM.
Let me know if you agree on my proposal.
08/22/2022
I spent several days before understanding all of that.
I used 2 Virtual Machines to make DCOM testing, using Windows Event viewer, Wireshark to check which level of authentication was used for DCOM.
Then I modified the code like I explained in my previous post. And checked, using whireshark that the level of authentication was now at the right level (eg RPC_C_AUTHN_LEVEL_PKT_INTEGRITY).
For my testing I used Schneider Electric OPC DA server (eg OFS DA). Everything is working fine, DCOM connexion was established without providing explicit credentials on Windows 10 machine requesting DCOM RPC_C_AUTHN_LEVEL_PKT_INTEGRITY level.
05/30/2017
It is not clear why you did not set the default for the process to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY.
Passing in null allows the caller to control the security settings.
If it is always set then the caller can no longer control them. This means this could be a breaking change to other applications.
2 Guest(s)