1

Our applications cannot poll OPC DA server (running on the SAME MACHINE) ONLY in asynchronous mode, because of (got from Windows Event Viewer -> Windows Logs -> System)

The server-side authentication level policy does not allow the user 
DESKTOP-AAAAA\Admin SID (S-1-5-21-239355189-745547292-2783995333-1001) 
from address 192.168.0.5 to activate DCOM server. 

Please raise the activation authentication level at least to 
RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in client application.

This is because of tricky and buggy Microsoft DCOM hardening. Thus our application already uses the highest authentication level (higher than RPC_C_AUTHN_LEVEL_PKT_INTEGRITY) and DCOM settings are configured according to recommendation of OPC DA Server provider (Matricon Simulation in our case).

From the error above I can conclude that j-interop (or something else in calling chain) uses wrong IP address of my machine, thus Windows applies wrong authentication rules. Because both the our application and OPC DA server run on the same machine, so I initialized JiSession with 127.0.0.1 as target host. But the error shows that request is from 192.168.0.5 - the IP of my WiFi adapter (by the way, my machine hasn't static IP):

$ ipconfig
....

Wireless LAN adapter:

   Connection-specific DNS Suffix  . :
   IPv6 Address. . . . . . . . . . . : 2a02:2698:582b:1606:91d4:8c27:683f:333f
   Temporary IPv6 Address. . . . . . : 2a02:2698:582b:1606:8042:9881:a089:37e3
   Link-local IPv6 Address . . . . . : fe80::ac0:a10c:425:4577%8
   IPv4 Address. . . . . . . . . . . : 192.168.0.5
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : fe80::1%8

After digging into j-interop source code, I found it supports only ncacn_ip_tcp RPC endpoint disregarding remote address or localhost. For the latter j-interop might use ncalrpc RPC endpoint. I guess it could be the root cause of the error mentioned at the begging on the question.

At the moment my questions are:

  1. Did anyone try to force j-interop using ncalrpc for 127.0.0.1 (i.e. localhost)?
  2. Or maybe someone solved the error of authentication level check?
devaskim
  • 492
  • 3
  • 10
  • These are not bugs, just reports that your client requires changes to support servers DCOM hardening. Not familiar with your overall environment, but about RPC and DCOM, you need to determine precisely in what part of your setup you (or components you use) configure DCOM (CoInitializeSecurity calls) authentication level. Note the way you authenticate is somewhat another matter at this point. This is not clear to me reading your question. You can also check for messages event viewer message 10037 and 10038 they may add some info. – Simon Mourier Apr 20 '23 at 07:26
  • `j-interop` is Java library, so there is no `CoInitializeSecurity `. I added mentioned `Admin` Windows user to default DCOM activation and access permissions via `dcomcnfg`, grant both local and remote access and ensured that OPC server uses that default DCOM settings. – devaskim Apr 20 '23 at 07:57
  • I guess I am not correct in terms. But also my app "formes" outgoing NDR buffer with `PROTECTION_LEVEL_PRIVACY` (so it is stronger than `PROTECTION_LEVEL_INTEGRITY`) and authentication service is NTLM – devaskim Apr 20 '23 at 08:15
  • These configuration settings are (at that point) irrelevant. Java or not, if you want to talk to a hardened DCOM server using DCOM you must call CoInitializeSecurity with RPC_C_AUTHN_LEVEL_PKT_INTEGRITY or higher somehow. If you don't, you'll use default security. – Simon Mourier Apr 20 '23 at 08:15
  • @SimonMourier I guess you are talking about the same as in [this SO](https://stackoverflow.com/a/6125335/17782348), right? – devaskim Apr 20 '23 at 10:29
  • Impersonation is another subject. I'm just talking about calling CoInitializeSecurity with RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in the client. – Simon Mourier Apr 20 '23 at 12:40
  • Leave here [useful article about RPC on Windows](https://flylib.com/books/en/2.294.1.111/1/) – devaskim Apr 25 '23 at 05:58
  • @SimonMourier Could you explain me again how [this C++ OPC DA](https://github.com/edimetia3d/OPC-Client-X64) client even with [RPC_C_AUTHN_LEVEL_NONE](https://github.com/edimetia3d/OPC-Client-X64/blob/master/OPCClientToolKit/OPCClient.cpp#L57) in `CoInitializeSecurity` works out of the box on my the same test machine? Here is its [CoCreateInstanceEx](https://github.com/edimetia3d/OPC-Client-X64/blob/master/OPCClientToolKit/OPCHost.cpp#L69) call for more information. – devaskim Apr 26 '23 at 14:12
  • 1
    You say "on the same test machine". Is this client connecting to a DCOM-hardened machine through network? Otherwise have you checked the AppID registry key (for this client and yours) https://learn.microsoft.com/en-us/windows/win32/com/appid-key. Note there's also an auto-elevation patch (see end of https://support.microsoft.com/en-us/topic/kb5004442-manage-changes-for-windows-dcom-server-security-feature-bypass-cve-2021-26414-f1400b52-c141-43d2-941e-37ed901c769c) that works for most non-anonymous clients. It's possible that this client benefits fromt it since it's non-anonymous. – Simon Mourier Apr 26 '23 at 15:01
  • @SimonMourier 1) Working C++ client, non-working Java client and OPC DA server are on the same machine - my laptop, so `localhost` connection. 2) I guess there is no AppID for both clients (I didn't find source code of editing registry) and they runs as raw `exe` binaries built from source code, so no installers that might add that registry AppID. 3) You said `this client benefits fromt it since it's non-anonymous` Explain me, please, how do to you know that the C++ client is non-anonymous, because I thought that setting `RPC_C_AUTHN_LEVEL_NONE` in `CoInitializeSecurity` means anomymous. – devaskim Apr 27 '23 at 05:07
  • 4) `RequireIntegrityActivationAuthenticationLevel` is 0 (so disabled) and `RaiseActivationAuthenticationLevel` is 2 – devaskim Apr 27 '23 at 05:15
  • 1
    If system is under normal maintenance, post March 2023, `RequireIntegrityActivationAuthenticationLevel` (server) has no longer any effect, and settings `RaiseActivationAuthenticationLevel` (client) should not be needed (defaults to 2). This line of code here https://github.com/edimetia3d/OPC-Client-X64/blob/master/OPCClientToolKit/OPCClient.cpp#L57 tells this client seems (is it ran? can't say) to use anonymous activation security (https://learn.microsoft.com/en-us/windows/win32/com/turning-off-activation-security) that's whay it may work. Anonymous clients are not affected by DCOM hardening. – Simon Mourier Apr 27 '23 at 06:00
  • @SimonMourier Regarding to security setting under AppID, is there any way to set Java-wide DCOM settings (via registry)? As it is suggested in [this forum topic](https://forums.oracle.com/ords/apexds/post/coinitializesecurity-7100): `Change security for java.exe in the registry. This effects all java-DCOM applications` – devaskim Apr 27 '23 at 06:22
  • 1
    All is explained here https://learn.microsoft.com/en-us/windows/win32/com/appid-key so yes with something similar to this : https://forums.oracle.com/ords/apexds/post/running-as-administrator-2258 but if CoInitializeSecurity is used somehow, the AppID info concerning security will not be used https://learn.microsoft.com/en-us/windows/win32/api/combaseapi/nf-combaseapi-coinitializesecurity#remarks – Simon Mourier Apr 27 '23 at 06:51
  • @SimonMourier Do you know how manually create/edit `LaunchPermission` and `AccessPermission` registry values? – devaskim May 03 '23 at 12:53
  • 1
    Once you have created an APPID you can use DCOMCNFG https://learn.microsoft.com/en-us/windows/win32/com/setting-processwide-security-using-dcomcnfg example https://social.technet.microsoft.com/Forums/fr-FR/a28706ff-216c-437d-8210-311dd7dd93c5/how-to-grant-component-servicesdcom-permissions-for-an-application-via-gpo-ssis?forum=winserverGP – Simon Mourier May 03 '23 at 13:47

0 Answers0