Lockdown the DeltaV System Time Application

The DeltaV System Time Sync Application can be invoked by non-administrator DeltaV users and can cause significant problems with historical data collection if system time is set without proper consideration to these systems.

A antiquated approach to this problem was to hide the application launch button in Operate.  However, the application can also be called through DeltaV Diagnostics and DeltaV Explorer in buttons that cannot be hidden.  Both of these applications can be called by non-administrators as well.

The better approach is to define user access permissions for the application.  This way, no matter how the application is called, it will be restricted based on user authority.  In the following figures, members of the DeltaV group (all users) have full permissions.  Members of the DeltaV Basic Operators group have the proper permissions, denying access to the application.

 

However, many sites do not use the DeltaV Basic Operators group (configured through Security Manager, it adds users to a group that is under very tight access control). 

It would be ideal to use this more secure group at all sites (provided a full evaluation of required rights and limitations is conducted), but typically most non-administrator users fall into the user group DeltaV. 

You can easily set the access control for the DeltaV group to this application by deleting the group from the access control list or by removing all 'Allows'  (DO NOT JUST ADD DENY as DeltaV Administrators are also members of the DeltaV Group and DENY beats ALLOW).

Having to do this for all workstations in a system, and ensuring it is set when workstations get replaced or rebuilt requires more thought, rather than repetetive and unmanageable change procedures.

Using Domain Group policy, you can specify the file permissions and have it apply automatically to all domain members.  In the domain group policy editor, add to any group policy a Computer Setting for File System access specification as shown in this figure.  The access control editor should match exactly what was installed with the exception of removal of the DeltaV group.

This policy setting can be easily exported and archived, is duplicated between domain controllers, and is automatic for all domain member computers provided the Group policy scope is configured in this manner.

6 Replies

  • Thank you for this update.

  • In reply to DCS Newbie:

    This Set/Synchronize Network Time tool should not be used to set the DeltaV system time!

    Please see DeltaV KBA "NA-0200-0147 Operational Tips on Network Time Protocol and Set/Synchronize Network Time Tool" for more information on NTP in DeltaV. You need user access to the DeltaV SMS site to access a KBA.

    To prevent access to this function the DeltaV application "systemtime.exe" can be either renamed so it is not easily accessible or simply deleted from the DeltaV directory.

    The systemtime application will force all of the DeltaV Nodes to the time of the workstation on which it is run. It does not just change the time of that specific workstation. Resetting tiime on all nodes is not a desirable thing to do.

    We will be removing it from the DeltaV provided software in v13.3 and removing the BOL information.

    DeltaV provides time synchronization for all nodes from a centralized NTP application on a DeltaV workstation.

    Bob Huba

  • In reply to BobHuba:

    Bob,

    This is good news! Thanks for making this happen expeditiously.

    Regarding the workaround of deleting / renaming the DeltaV Time app, I would like to state that my original guidance:

    "Having to do this for all workstations in a system, and ensuring it is set when workstations get replaced or rebuilt requires more thought, rather than repetetive and unmanageable change procedures.

    Using Domain Group policy, you can specify the file permissions and have it apply automatically to all domain members"

    is still applicable, but should actually be taken further to ensure that the all users are denied permission to the application. Renaming or deleting the application for new or replaced workstations manually introduces the possibility that it won't be done consistently througout a system lifecycle.

  • In reply to BobHuba:

    Bob,

    This is good news! Thanks for making this happen expeditiously.

    Regarding the workaround of deleting / renaming the DeltaV Time app, I would like to state that my original guidance:

    "Having to do this for all workstations in a system, and ensuring it is set when workstations get replaced or rebuilt requires more thought, rather than repetetive and unmanageable change procedures.

    Using Domain Group policy, you can specify the file permissions and have it apply automatically to all domain members"

    is still applicable, but should actually be taken further to ensure that the all users are denied permission to the application. Renaming or deleting the application for new or replaced workstations manually introduces the possibility that it won't be done consistently througout a system lifecycle.

  • Good point and a reasonable suggestion. Does this work on a workgroup system or just a domain based system? Perhaps it would be good to clarify that situation too. I still like the removal idea where possible as it does remove the possibly it would get changed back by an admin who is not aware of the situation is trying to resolve an "access denied" message by changing the permissions. But this is a good suggestion.
  • In reply to BobHuba:

    Thanks Bob.  

    There are ways to manage files through policy as well.  Worst case, a logon or startup script that deletes or renames the file.  

    Of course group policy applies only to domain situations.  

    If using DeltaV on a workgroup the decision to centrally manage operating system of workgroup members has been made in favor of  manual and distributed management, hopefully through documented procedures.   A script could also be placed on the pro-plus to periodically rename the file on all workgroup members, if such procedures cannot be put in place.