Accessing openPDC service from a remote desktop with Manager and Console

GPA Products openPDC
1

Hello,
I still trying to build a proof of concept for my ‘secured’ PDC server. My PDC server is running openPDC service, in a VLAN ; acquiring PMU data through firewalls rules.
I want to be able to configure this openPDC server, using Manager and Console, from a desktop which would not be in the same VLAN ; with a Windows account not in the same AD domain. That’s because I’ll will not be allowed to access with a remote desktop session to the future production server.
I’ve read several posts (how to make OpenPDC service working on Linux ; with the Console/Manager working on Windows) ; which addresses the same desire to run Manager and Console on a remote workstation from the server hosting the service. But I encounter some difficulties.

  • My PDC Server (Windows) has the following configuration :
    – OpenPDC 2.9.315
    – Local MySQL Server database (with a remote account declared on it ; allowing access from the remote desktop).
    – For the initial config (local Manager and Console) ; I have the following parameters :
    openPDCConsole.exe.Config :
    “ConnectionString” value=“Server=localhost:8500; interface=0.0.0.0”
    “IntegratedSecurity” value=“True”
    openPDCManager.exe.Config :
    “ConnectionString” value=“Allow User Variables=true; Server=localhost; Database=openPDC29315; Uid=root; Pwd=DBPWD”
    System Node configuration
    RemoteStatusServerConnectionString={server=PDC_SERVER_IP:8500; interface=0.0.0.0; integratedSecurity=True}; dataPublisherPort=6165; AlarmServiceUrl=http://PDC_SERVER_IP:5018/alarmservices; WebHostURL=http://PDC_SERVER_IP:8280/

=> Locally, everything works fine ; which is not surprising because it’s a standard standalone ‘by default’ local configuration.

  • My remote Desktop (Windows too) has the following configuration :
    – OpenPDC Manager and Console files stored locally.
    openPDCConsole.exe.Config :
    “ConnectionString” value=“Server=PDC_SERVER_IP:8500; interface=0.0.0.0”
    “IntegratedSecurity” value=“True”
    openPDCManager.exe.Config :
    “ConnectionString” value=“Allow User Variables=true; Server=PDC_SERVER_IP; Database=openPDC29315; Uid=RemoteDBUser; Pwd=RemoteDBPWD”

=> Console doesn’t work. I can log in the Manager and, because it access the remote database with success, I can see all the stored measurements, devices and so on ; but Manager can’t access to the remote windows service (light on the upper right corner is red).

As I’ve read that it may be due to the IntegratedSecurity parameters, I’ve then changed the following values :

  • PDC Server Side :
    openPDCConsole.exe.Config : “IntegratedSecurity” value=“False”
    System Node configuration :
    RemoteStatusServerConnectionString={server=PDC_SERVER_IP:8500; interface=0.0.0.0; integratedSecurity=False}; dataPublisherPort=6165; AlarmServiceUrl=http://PDC_SERVER_IP:5018/alarmservices; WebHostURL=http://PDC_SERVER_IP:8280/

Event before testing the remote desktop Console and Manager ; I notice some issues on the local PDC server :
=> The console does no work properly :

image
image751×401 16.3 KB

=> Manager is not as stable as in the default configuration :
the light in the upper right corner stay green most of the time ; but at some moments start to blink green/red quickly and constantly.
2024-05-31_14h56_19

The server informations on the home page are not fully displayed and the ‘restart service’ button is not available.
image

In the error logs I have the following exceptions :
(Outer Exception)
Date and Time: 5/31/2024 3:01:34 PM
Machine Name: XXXXXXXXXXXX
Machine IP: XXXXXXXXXXX
Machine OS: Microsoft Windows NT 6.2.9200.0

Application Domain: openPDC.exe
Assembly Codebase: D:/openPDC/openPDC.exe
Assembly Full Name: openPDC, Version=2.9.315.0, Culture=neutral, PublicKeyToken=null
Assembly Version: 2.9.315.0
Assembly Build Date: 5/19/2024 1:44:34 AM
.Net Runtime Version: 4.0.30319.42000

Exception Source: System
Exception Type: System.IO.IOException
Exception Message: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
Exception Target Site: EndProcessAuthentication

---- Stack Trace ----

  • System.Net.Security.NegoState.EndProcessAuthentication(result As IAsyncResult)*
  •   openPDC.exe: N 2316332*
  • GSF.Communication.TlsServer.ProcessIntegratedSecurityAuthentication(asyncResult As IAsyncResult)*
  •   openPDC.exe: N 00167*

(Outer Exception)
Date and Time: 5/31/2024 3:01:34 PM
Machine Name: XXXXXXXXXXXXXX
Machine IP: XXXXXXXXXXXXX
Machine OS: Microsoft Windows NT 6.2.9200.0

Application Domain: openPDC.exe
Assembly Codebase: D:/openPDC/openPDC.exe
Assembly Full Name: openPDC, Version=2.9.315.0, Culture=neutral, PublicKeyToken=null
Assembly Version: 2.9.315.0
Assembly Build Date: 5/19/2024 1:44:34 AM
.Net Runtime Version: 4.0.30319.42000

*Exception Source: *
Exception Type: System.Exception
Exception Message: Unable to authenticate connection to client [PDC_SERVER_IP]: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.

I have the same behavior using Manager and Console on the remote desktop.

Have I forgot something ?

Sorry for the long post,

Regards

2

I think I’ve found :
In addition to the previous parameters (node and openPDCConsole.exe.Config), I have to change the following parameter in openPDC.exe.Config :
“IntegratedSecurity” value=“False” description=“True if the client Windows account credentials are used for authentication, otherwise False.”

Is this seems OK to you ?

Regards

3

The setting is related to Windows/Kerberos authentication for TCP sockets. This is used to allow a client connection to authenticate with a server with a user’s running credentials, like a pass-through authentication option.

If the server can’t authenticate the client, because say it didn’t have access to domain credentials, then the authentication would fail. Note that we disable this option on Linux deployments since this is a Windows only type thing.

Disabling this typically means you will have to use local accounts and/or database accounts for authentication. However, if the service has access to the domain, it may be able to still authenticate domain accounts, but you will always need to enter your credentials when logging in.

Also, disabling needs to occur for all client/server socket configurations, e.g., the remotingServer configuration in the openPDC.exe.config, the settings in the openPDCConsole.exe.config as you discovered, and in the openPDC Manager node configuration, as you listed above.

Make sure you have local and/or database user accounts setup before fully disabling the integrated security so you can continue to login after disabling this feature.

Thanks!
Ritchie

4

Thank you very much, Ritchie, for this very comprehensive response, which confirms that I have correctly identified all the parameters to modify in order to carry out this migration of the Console and Manager clients. I confirm that I use DB accounts so it’s OK for me.
There remains the PMU Connection Tester tool, which is essential for examining the contents of C37.118 streams and easily identifying the various Indexes and IdCodes they contain. This allows them to be correctly declared when manually creating Devices/Phasors/Measurements in the Manager. (I no longer use the import files generated by PMU Connection Tester in OpenPDC because they sometimes result in incomplete creations or data alterations when updating existing streams. In my opinion, manually declaring Devices/Phasors/Measurements is much more secure). Having a PMU Connection Tester tool whose graphical interface could be deployed on another workstation and/or server would be a real plus in terms of security and best maintenance practices in operational conditions. This would eliminate the need to connect to the OpenPDC server to configure new streams in OpenPDC. Indeed, the first action performed (at least in my case) is to analyze their content using this tool before creating the corresponding elements via the Manager. However, the OpenPDC server is often in a secure network zone, where we ideally want to minimize access, including ‘remote desktop’ sessions. Perhaps consider an additional Windows service on the OpenPDC server, whose role would be to process requests from the interface deployed on another workstation?

Regards,

Stephane