In Windows 10 feature release 1809, the way Windows connects to a DCOM server changed in certain cases. As a result, a workaround is now required when DCOM clients connect to a Java server using a moniker as described in the "Zero Client Installation" article. Note that this change does not affect accessing COM objects over DCOM using proxies created using com2java.

Problem Description

When getting objects from a Java server over DCOM in the "Zero Client Installation" configuration, the client uses Windows' built-in mechanism to retrieve a remote COM object referenced by a moniker. This article contains an example of a Visual Basic script retrieving a Java object over DCOM by defining a moniker that includes a StringBinding specifying a hostname and TCP port, e.g. "192.168.0.120[4197]".

As of Windows 10 1809, a moniker may no longer include a port in the StringBinding. Where previously the binding would be in the format "192.168.0.120[4197]", it must now simply be "192.168.0.120". The client now assumes an endpoint of 135, which is the Windows RPC subsystem (RPCSS) endpoint. The RPCSS includes an object exporter ID (OXID) resolver, which resolves DCOM requests with a given OXID to the port the object exporter with that ID is listening on. In the example linked above, the Java server--the object exporter--is listening on a port defined using a parameter on the Java command line. There is no way to register the Java object exporter with the RPCSS OXID resolver. Now that clients must go through the Windows RPCSS to resolve the correct OXID, there is no way for DCOM clients to retrieve objects directly from the server using a moniker.

This issue affects clients retrieving objects from a Java server using a moniker generated using J-Integra's GetJvmMoniker class or via J-Integra's jintmk.dll library.

Workaround

The workaround involves a non-Windows proxy server forwarding DCOM traffic from the client directly to the Java server. The proxy redirects connections on its port 135 to the Java server running on the port that is specified as a parameter during server startup.

J-Integra Version Support

J-Integra version 2.13+ and 64.03+ support a workaround for this issue. These versions support the "JINTEGRA_OXID_PROXY_HOST" parameter, which must be used on the Java server's command line to specify the proxy hostname (or IP address). This will override the OXID resolver response that the server sends to the client when the DCOM connection is established, so that the client will to use the proxy to emulate the OXID resolver. Without this parameter, the server will use its own hostname when responding to the OXID resolve request and the client will try to connect to the server's RPCSS.

Workaround Details

The following steps will need to be done to implement the workaround:

1. Add the "-DJINTEGRA_OXID_PROXY_HOST=[host]" to the Java server command line, with [host] set to the proxy server's hostname or IP address.
2. Remove the port specification from the moniker in the client.
   1. When generating a moniker using the GetJvmMoniker class, omit the port parameter from the command line arguments.
   2. When using jintmk.dll, omit the port from the "binding" value in the registry configuration.
3. Create a proxy server that forwards port 135 to the port specified on the Java server command line.

The proxy server cannot be a Windows server, as Windows is not able to forward port 135. A Linux server with an iptables port forwarding rule will serve as an effective proxy. The proxy can be a virtual machine running on the Windows server, as long as the VM is connected to the network in bridge mode. This is required because the Windows host will not be able to forward port 135 to the VM, so the VM needs its own IP address that can be accessed directly by DCOM clients.

Here is an example iptables rules.v4 file that will forward traffic on the proxy's port 135 to a Java server running on the endpoint 192.168.0.120[4197]. The proxy's network interface is eth0.

# Generated by iptables-save v1.6.1 on Fri May 22 15:18:02 2020
*nat
:PREROUTING ACCEPT [6:980]
:INPUT ACCEPT [6:980]
:OUTPUT ACCEPT [10:3018]
:POSTROUTING ACCEPT [5:1576]
-A PREROUTING -i eth0 -p tcp -m tcp --dport 135 -j DNAT --to-destination 192.168.0.120:4197
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
# Completed on Fri May 22 15:18:02 2020
# Generated by iptables-save v1.6.1 on Fri May 22 15:18:02 2020
*filter
:INPUT ACCEPT [50952:568223292]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [69595:592703765]
COMMIT
# Completed on Fri May 22 15:18:02 2020

Workaround Network configuration

This diagram shows the network configuration, with the client having IP address 192.168.3.50, the proxy at 192.168.3.48, and the Java server running on 192.168.0.120[4197].

---