Updating the security file

About this task

By default, every workstation in an HCL Workload Automation network (domain managers, fault-tolerant agents, and standard agents) has its own security file. You can maintain that file on each workstation, or, if you enable centralized security management, you can create a security file on the master domain manager and copy it to each domain manager and agent, ensuring that all HCL Workload Automation users are assigned the required authorization in the file (see Centralized security management). Whether working on an agent workstation for an individual security file, or on the master domain manager to modify a centralized file, the steps are just the same; all that changes are the number of users you are defining - just those on the local system or all in the HCL Workload Automation network.

If you are updating or upgrading your fault-tolerant agents to version 9.5 Fix Pack 2 or later, you must manually update the security file on the fault-tolerant agents in your environment to add access to folders for all of the scheduling objects that can be defined or moved into folders. These updates are especially important if you plan to use the command line on the fault-tolerant agents to perform operations on the objects in folders. More specifically, if centralized security is enabled (enCentSec / ts = YES), then you must first update or upgrade all of the fault-tolerant agents in your environment to version 9.5 Fix Pack 2 or later before you begin using the folder feature. If centralized security management is not enabled (enCentSec / ts = NO), all stanzas that reference CPU are automatically updated to include folder access, for example, CPU CPU=@+FOLDER="/", unless you use wildcard characters (@) as matching criteria in your stanzas, for example, CPU CPU=@HR. In this case, if you want to be able to move these CPUs into folders, then you need to manually update those stanzas to include access to all folders, CPU CPU=@HR+FOLDER="/".

Neither the HCL Workload Automation processes nor the WebSphere Application Server Liberty infrastructure needs to be stopped or restarted to update the security file. You just need to close any open conman user interfaces before running makesec.
To modify the security file, perform the following steps:
  1. Configure the environment, running one of the following scripts:
    In UNIX®:
    • . ./TWA_home/TWS/tws_env.sh for Bourne and Korn shells
    • . ./TWA_home/TWS/tws_env.csh for C shells
    In Windows®:
    • TWA_home\TWS\tws_env.cmd
  2. Navigate to the following directory from where you can submit the dumpsec and makesec commands:
    TWA_home/TWS
    TWA_home\TWS
  3. Run the dumpsec command to decrypt the current security file into an editable configuration file. See dumpsec.
  4. Modify the contents of the editable security configuration file using the syntax described in Configuring the security file.
  5. Close any open conman user interfaces using the exit command.
  6. Stop any connectors on systems running Windows operating systems.
  7. Run the makesec command to encrypt the security file and apply the modifications. See makesec.
  8. If you are using local security, the file will be immediately available on the workstation where it has been updated.
    If you are using centralized security (see Centralized security management), perform the following steps:
    1. If you are using a backup master domain manager, copy the file to it.
    2. Distribute the centralized file manually to all fault-tolerant agents in the network (not standard, extended, or broker agents), and store it in the following directory:
      For a fresh installation of version 9.5.x or later
      TWA_DATA_DIR
      TWA_home\TWS
      Upgraded environment originating from a version earlier than 9.5:
      TWA_home/TWS
      TWA_home\TWS
    3. Run JnextPlan to distribute the Symphony file that corresponds to the new Security file.
    See dumpsec and makesec for a full description of the commands.