Hello Dojo,
we are running a DMS on version 10.3.0.0-13374-CU7, and right now we are implementing several measures described in the DataMiner hardening guide.
One of the measures concerns secure client-server communication based on gRPC. Since this will be standard from 10.4.0 onwards, we wanted to take this step already now. So we followed the description here: https://docs.dataminer.services/user-guide/Advanced_Functionality/Security/DataMiner_hardening_guide.html#dataminer-cube (which is also including this here: https://docs.dataminer.services/user-guide/Reference/Skyline_DataMiner_Folder/More_information_on_certain_files_and_folders/ConnectionSettings_txt.html)
At first, everything seemed to work just fine, and the Cube connection was working on gRPC as it should. Cube “About” -> connection:
Attributes = AcceptsCollaborationMessages, Cube, AllowMessageThrottling, GrpcConnection
Then we realized that on some machines, concerning some users, login was no longer possible:
This definitly seems to be connected to the implementation of gRPC. Before activating gRPC, we’ve had no such issues. After performing some testing, including Cube updates and re-installs, we deactivated gRPC again (type=LegacyRemotingConnection;polling=1000;zip=true), and login was possible again immediatly.
Any idea what might be the solution for this one?
Thanks a lot for your thoughts on this!
KR
Nils
Hi Marieke,
this is indeed still an open task for us. We’ve found out recently that this might be an issue related to our proxy / VPN solution, but further investigation with the administrators responsible for this needs to be done.
Anyway, my assumption is that the cause for this trouble has to be found out of SLCs scope…
Eventually, this issue resolved itself “somehow”. We continued to keep our DMS updated, and when looking into the issue again one year later on, we observed that all clients where able to connect via gRPC as expected. The issue we observed initially could not be reproduced…
So indeed (now) everything works as it should. Thank you for your feedback!
Hi Nils,
Not 100% sure, but I’m suspecting those clients doing difficult, to be fixed on .NET Remoting. Maybe you can check if those clients who had problems are effectively configured on “Auto” in the setting indicated in the below screenshot. No need to switch the server back, you can check this immediately without changing anything.
This should always be on Auto except if you want to test something. With this setting you basically override what the server specifies and then the connection might indeed fail (although the error message is not matching that well, so I might be wrong as well).
Let us know if this was helpful or not.
Bert
Hi Bert,
thanks a lot! We will look into this.
KR
Nils
Hi Bert,
finally we could test this. The following is the case:
– the client in question, which has connection problems as described above, actually is set to Auto.
– when changing this to Remoting, a LegacyRemotingConnection is established, despite an active configuration of gRPC in ConnectionSettings.txt
So not only that the client already is set to Auto and a gRPC connection is not established, but on top a LegacyRemoting Connection is set up despite being disabled in the configuration on the server (as I understand it).
Maybe the proper activation of gRPC is somehow not entirely rolled out or activated? At the same time, my client is nicely connecting via gRPC…
Hi,
Is this issue still present?
I would like to clarify that changing the connectionsettings.txt to gRPC will not disable .NET remoting. The connectionsettings.txt are used to determine which connection type Cube should use when set to auto, but it is possible to overrule this.
If you want to enforce gRPC connections, you can close port 8004 for inbound connections in the firewall.
Hi Nils,
Do you still need help with this? If not, could you select the answer to indicate that this question can be closed?