Upgrade fails due to truncated USER entries in the Security file

The upgrade process can fail when the makesec script compiles the Security file and encounters duplicate USER definitions caused by character truncation.

The role-based security model automatically generates USER entry keys in the Security file by concatenating the security role name, the string of, and the security domain name, as follows:

<Role>of<Domain>

The maximum allowed length for a USER definition key in the Security file is 36 characters, as stated in Security domain definition, Security role definition. If the concatenated <Role>of<Domain> string exceeds this limit, HCL Workload Automation truncates the key at the 36th character.

If multiple role and domain combinations share the same initial 36 characters, truncation produces identical USER keys. During an upgrade or compilation, the makesec script detects these identical keys as duplicate USER entries and stops the process with an error similar to the following, indicating ambiguous or duplicate definitions:
AWSDEJ115E The same user ("<too_long_user_name>") is defined more than once.

Example scenario

Consider the following scenario where a role name exceeds the character threshold:

  1. A security role is defined with a long name: ENTERPRISE_OPERATIONS_ADMINISTRATOR.
  2. This role is associated with two domains: PRODUCTION_EAST and PRODUCTION_WEST.
  3. The system attempts to generate two unique keys:
    • ENTERPRISE_OPERATIONS_ADMINISTRATORofPRODUCTION_EAST
    • ENTERPRISE_OPERATIONS_ADMINISTRATORofPRODUCTION_WEST
  4. Due to the 36-character limit, both keys truncate to the exact same 36-character string: 
    ENTERPRISE_OPERATIONS_ADMINISTRATORo
  5. When makesec runs during an upgrade, it flags the second occurrence as a duplicate entry and halts the process.

Resolution strategy

To resolve this issue and complete the upgrade, shorten the security role or domain names so that the concatenated <Role>of<Domain> string does not exceed 36 characters:

  1. Revert the system to the pre-upgrade snapshot.
  2. Back up existing security role and access control list configurations using composer or the Dynamic Workload Console.
  3. Create a new security role with a shorter name and copy the contents from the original role.
  4. Update existing ACL definitions to reference the new security role.
  5. Delete the original security role from the database.
  6. Verify that the security file compiles cleanly using the makesec or the composer scripts.
  7. Retry the upgrade process.