DeltaV Remote Desktop Connection From a Remote Client Server to Other DeltaV Application Stations

Hi

I have a Remote Client Server (RCS) that is used for connections into DeltaV from an external Business Domain.

I cannot currently "hop" from the RCS to any other DeltaV application station. The application stations appear to be enable for remote connections and the is no policy denying connections.

Appreciate any thoughts. Is this discouraged for any reason?

Thanks!

5 Replies

  • Colin,

    remote connections to DeltaV using Remote Desktop Protocol are not meant to be used so that you can "hop" to each DeltaV station, but instead it is used to provide you the operations or engineering functionality while working remotely and being able to effectively enforce permissions accordingly. This functionality is called DeltaV Remote Client and the landing zone within DeltaV for this solution is a remote session hosted by a Remote Desktop Server that happens to be a DeltaV server (Professional Plus or Operator Station) that is purposefully configured that way. You don't enable remote access to Application Stations or other DeltaV stations for direct access to "session 0" as you are describing.

    It's OK to have an intermediary server (aka. jump server) between the business domain and the DeltaV system, but this jump server would normally be outside of the DeltaV system security boundary - in your diagram, this jump server would be on the left side of the Emerson Smart Firewall for example - and then either the Professional Plus or an Operator Station (usually a Base Station if you have several connections needed) will host the remote sessions that are configured and licensed from within DeltaV Explorer.

    For a better user experience (and higher security profile), instead of using a multi-hop structure with "daisy-chained" Remote Desktop Servers, you can use Microsoft Remote Desktop Gateways instead which are described in Books Online as of DeltaV v13.3.1.

    You may want to review the DeltaV Remote Client PDS for additional information about this topic: www.emerson.com/.../product-data-sheet-deltav-remote-client-en-56200.pdf

    I hope this helps!
  • In reply to Alexandre Peixoto:

    By defualt DeltaV disables remote desktop functionality, check and changed it to automatic the following services:
    Remote Desktop Configuration
    Remote Desktop Services
    Remote Desktop Services UserMode Port Redirector
  • In reply to Lun.Raznik:

    Lun, we disable direct access to DeltaV stations via RDP as part of the recommended hardening implemented during DeltaV installation, and also because direct access to a station doesn't allow concurrent session use. The supported and recommended approach for remote access to DeltaV systems is using the DeltaV Remote Client solution (session-based RDP) alluded to on my previous comments.

    Manually enabling the services listed above will provide limit user's experience and also deviate from hardening guidelines for DeltaV systems' implementation which directly impact the good automated manufacturing practices offered in an out-of-the-box manner (via install) with the DeltaV installation.
  • In reply to Alexandre Peixoto:

    Hi Alexandre , it's very important to follow best practice to install properly and safely any DeltaV Fonctionnality
    For remote desktop I invite you to read and follow the KBA NK-1600-0267 that you can find on your DeltaV Guardian Portal with the addtionnal comment that installing remote sessions roles must be done prior deltav software installation.
    Anyway , when you try remote dektop from business domain network you have often several barriers to outcome :
    - DNS resolution in the domain
    - routing table , are you sure that IP routing is correct ( what happen if you ping the deltav remote server station with it's IP ?
    - Are all firewall between Deltav remote server and the client you'are using , open on right IP adress and allow rdp protocol ?
    - GPO of business domain must be checked out for any restriction
    - a sample test to perform is to connect temporarely a "simple" PC in workgroup directely to deltaV smart firewall, instead of connexion on business domain and try a remote connexion. If it's work the issue is coming from business network, try to discuss with your IT team to know the eentire connexion architecture from your business PC to DeltaV Smart firewall
    If it doesn't work make a new try without DeltaV Smart Firewall by connecting a workgroup PC directly to DeltaV remote server ( without any switch) If it works that means you have issue with DeltaV Smart Firewall, if it's not working consider the installation of server with the KBA.
  • In reply to LaurentB:

    It appears that Colin is looking to have administrative access to the servers, and not to run any DeltaV client applications. All such applications are available to him on his Remote Client session on the RD Server.

    KBA NK-1200-0138 documents the use of RealVNC product to allow remote administration functions for Application stations. It explains that the change in Microsoft Server 2008 and beyond altered the mstsc /console command to access the Session 0 of a server. The KBA goes on to state that remotely administering Applications stations is not addressed with DeltaV Remote Client.

    The KBA states RealVNC can be used to remotely adminster Batch Application Manager, Continuous Historian Administration tool, Event Chronicle Administration Tool and OPC Mirror. The problem is that this solution assumes you are connecting to RealVNC from a Thick Client, that is a PC or workstation. there is a client side component that is installed on the Client computer. There is no discussion that this can be installed on the DeltaV Remote Client server for use by a client session. This would require the Firewall to allow the VNC connection to the Application station. Although VNC provides encryption, it is not supported for the Professional Plus.

    In a separate KBA, it is pointed out that the use of DeltaV Remote DeskTop Connection (DRDC) can be used to connect the the RDP session of a server without the RDS Role, this connection requires the login user to have administrative and remote management privileges, and cautions that if this is not acceptable in terms of cyber security, to use Real VNC. This is offered when the computers are virtualized. As Alexandre points out, physical server installations do not have the RDP services enabled as part of the workstation hardening.

    In my opinion, the topology suggested by Colin limits access to the DeltaV system via the signal remote session connection through the firewall. Enabling RDP on these additional servers but also blocking connection to them via the firewall mitigates the risk. In addition, only the Remote Client server session is expected to make an RDP connection to these machines so each server can be further restricted as to which users will be allowed to connect. The connection could be made through the DeltaV Secondary network via IP address to further limit the visibility of the RDP session.

    But Alexandre pointed out a specific issue. During a software update of the Application station, where DeltaV Workstation configuration is run, the settings on Remote Desktop services may be altered and if these are set to disabled, the remote connection will be disabled. And if you were using the remote connection to install the software, well, that would put an end to the remote installation. This would likely be during a software upgrade. For day to day administration, and even applying hotfixes from time to time, the remote connection would not be disabled.

    The choices seem to be:
    - RealVNC - supports direct encrypted connection from a thick client.
    Not sure if it can be used via the RDP connection to remote client session or will require a PC to run the client.
    Software must be purchased. and it is not supported on the Professional Plus.  This does not mean it can not be installed, but it has not been tested.  If installing RealVNC client is possible on the RDS server and works within the remote client session, this could deploy locally in the DeltaV system without passing through Firewall.  

    - Enable RDP services on the servers, without enabling RDS Role

        This is not supported on physical servers but is known to work.  Software Installation may disable services as part of hardening of workstations.  Does not require any software purchase or installation of 3rd party software.  User requires admin and remote management privileges to connect.  Not recommended from L3 to L2 directly, but between L2 RDS server and L2 Application station, security risk is limited.  User should have no DeltaV access for Windows Admin reasons.  A separate DeltaV user would be used at DeltaV logon if needed.

    Cybersecurity and system access are diametrically opposed to each other.  One has to strike a balance.  Out of the Box, DeltaV provides a system with a high level of cyber security.  Changing RDP settings on servers needs to be carefully considered and appropriately safeguarded.  If RDP security risks are not acceptable, then Real VNC is an alternative.

    There does not appear to be any supported solution that works for all these servers, other than in a Virtual Environment were the Hyper V connection to the 0 session of any VM is provided.  

    Andre Dicaire