Tobias Neubert

Hi Vikram, can you please help me with this? I found out more: It is the ping requests and the SCMActivator that produces the error messages in the windows 10 server I managed to get the ping requests work without errors by setting the default of rpc.ntlm.sign to true in JIComOxidStub But the SCMActivator does not work that way. I debugged into the code and think that I have to set rpc.ntlm.ntlm2 to true in the JIComServer in order to let the DefaultConnection signAndSeal the ndr. But doing so results...

Ok, changing the rpc.ntlm.sign property to true makes it worse. So let me ask: Is this the correct way of raising the activation authentication level? If so, what else do I have to do to prevent the access denied exception that I don't get if rpc.ntlm.sign is set to false. And if not, how do I raise the activation authentication level?

Ah, ok, I found the list of error codes.

Ok, where do you see that? And why should it be an access denied if the client does not get an access denied without setting the rpc.ntlm.sign to true? I am sorry, but I am not familiar with DCOM.

Hi and thank you for your answer. I think I managed to find the property that controlls the authentication level: rpc.ntlm.sign. This property is false by default, I changed it to true. That way, the NtlmConnection creates a Type1 message (whatever this is) with the NtlmFlags.NTLMSSP_NEGOTIATE_SIGN set and a AuithenticationVerifier with the protectionLevel 5, which is rpc.Security.PROTECTION_LEVEL_INTEGRITY. But now my j-interop client throws the following exception with the suspicious unknown code...

Hi everybody, my opc da server logs into the Windows Event Log the following message: The server-side authentication level policy does not allow the user OPCDASRV\user SID (...) from address x.x.x.x to activate DCOM server. Please raise the activation authentication level at least to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in client application. How can I do that for my jinterop client? I am thankful for any hint, Tobias (This may have to do with kb5004442 microsoft describes that I have to raise the )

Ok, I have patched the lib by changing not throwing an exception in JIRemActivation.read(ndr) as follows: hresult = ndr.readUnsignedLong(); if (hresult != 0) { //System.out.println("EXCEPTION FROM SERVER ! --> " + "0x" + Long.toHexString(hresult).substring(8)); //throw new JIRuntimeException(hresult); LOGGER.warn( "Unexpected NDR found. Expected {} to be 0 at index {}. Will continue anyway.", Long.toHexString(hresult), ndr.getBuffer().getIndex()); LOGGER.warn("Unexpected NDR is: {}", ndr.getBuffer().getBuffer());...

No, unfortunately not as far as I can see. On the contrary, it makes me suspect, the j-interop code has to be changed: Then your best bet is to get this other big company to fix it if their software depends on it working. From a Microsoft point of view, you're using a 3rd party program of unknown origin and if it doesn't work, that not a MS problem.