Enhanced security.cfg

CA UIM 20.3.0 provides the following enhancements in the security.cfg file:
  • Uses a strong hashing algorithm PSV2 (PBKDF2) for password hashing in hub 9.31/9.31S.
  • Encrypts user information (for example, email ID, phone, profile, permissions) in hub 9.31/9.31S for users available in the security.cfg file.
The complete information is covered as follows:
2
Parameters
The following parameters let you control the user password hashing and user information encryption behavior:
  • psv2_password:
    Lets you specify whether you want to convert the user passwords created with PSV1 (MD5) to PSV2 (PBKDF2). The applicable parameter values are
    yes
    and
    no
    . You add this parameter to 9.31/9.31S hub.cfg.
  • encrypt_user_info:
    Lets you specify whether you want to encrypt the user information. The applicable parameter values are
    yes
    and
    no
    . You add this parameter to 9.31/9.31S hub.cfg.
  • You
    MUST
    take a backup of the security.cfg and security.dta files before enabling this functionality.
  • You
    cannot
    revert the changes in security.cfg after the password hashing is changed to PSV2. Therefore, you must back up the existing files.
Considerations
Review the following considerations:
  • When the encrypt_user_info parameter is enabled, the user information in security.cfg is propagated in a non-encrypted format to the hubs that are lower than 9.31/9.31S. For 9.31/9.31S hubs, the user information is propagated in the encrypted format.
  • When you enable the encrypt_user_info parameter on any 9.31/9.31S hub, then all 9.31/9.31S (and above) hubs will get the encrypted security.cfg file irrespective of the fact whether this parameter is enabled on those hubs or not. However, security propagation must be enabled on those hubs. Furthermore, in the case of primary hubs, security propagation always happens.
  • Once you enable the encrypt_user_info parameter on any 9.31/9.31S hub and the user information is encrypted, it is recommended that you do not go back to the decrypted state unless it is very important to do so. The reason is that the encrypted security.cfg file is already propagated to all the hubs (9.31/9.31S and above)
  • If you do not add these parameters to 9.31/9.31S hub.cfg, CA UIM follows the
    no-no
    scenario, which is the first row in the table.
Scenarios
The following table summarizes the information based on the values of the two parameters:
psv2_password
encrypt_user_info
Behavior
no
no
In this case:
psv2_password=no
  • PSV1 password is not converted to PSV2 when a user logs in to hub 9.31/9.31S because psv2_password is set to no.
    • Any new user created in hub 9.31/9.31S uses PSV2 for password by default. This user cannot log in to 7.97 (or earlier).
    • Users coming from hub 7.97 (or earlier) use PSV1 password. Their password is not converted to PSV2.
encrypt_user_info=no
  • Other user information is not encrypted in hub 9.31/9.31S because encrypt_user_info is set to no.
    • For all hub versions, security.cfg includes user information in a non-encrypted format because encrypt_user_info is set to no. This file is propagated to all hub versions with the same non-encrypted user information.
no
yes
In this case:
psv2_password=no
  • PSV1 password is not converted to PSV2 when a user logs in to hub 9.31/9.31S because psv2_password is set to no.
    • Any new user created in 9.31/9.31S uses PSV2 for password by default. This user cannot log in to 7.97 (or earlier).
    • Users coming from hub 7.97 (or earlier) use PSV1 password. Their password is not converted to PSV2.
encrypt_user_info=yes
  • User information is encrypted while propagating the security.cfg file to hub 9.31/9.31S.
  • For hub versions lower than 9.31/9.31S, the user information is decrypted while propagating the security.cfg file to the lower hub versions (7.97 or earlier).
yes
no
In this case:
psv2_password=yes
  • PSV1 password is converted to PSV2 when a user with PSV1 password logs in to hub 9.31/9.31S because the parameter is set to yes.
    • Any new user created in hub 9.31/9.31S uses PSV2 for password by default. This user cannot log in to 7.97 (or earlier).
    • Users coming from hub 7.97 (or earlier) use PSV1 password. Now, their password is converted to PSV2 when they log in to hub 9.31/9.31S. After logging in to 9.31/9.31S, they cannot log in back to 7.97 (or earlier) because of the PSV1 to PSV2 conversion.
encrypt_user_info=no
  • Other user information is not encrypted in hub 9.31/9.31S because encrypt_user_info is set to no.
    • For all hub versions, security.cfg includes user information in a non-encrypted format because encrypt_user_info is set to no. This file is propagated to all hub versions with the same non-encrypted user information.
yes
yes
In this case:
psv2_password=yes
  • PSV1 password is converted to PSV2 when a user with PSV1 password logs in to hub 9.31/9.31S.
    • Any new user created in hub 9.31/9.31S uses PSV2 for password by default. This user cannot log in to 7.97 (or earlier).
    • Users coming from hub 7.97 (or earlier) use PSV1 password. Now, their password is converted to PSV2 when they log in to hub 9.31/9.31S. After logging in to 9.31/9.31S, they cannot log in back to 7.97 (or earlier) because of the PSV1 to PSV2 conversion.
encrypt_user_info=yes
  • User information is stored in an encrypted format while propagating the security.cfg file to hub 9.31/9.31S.
    • For hub versions lower than 9.31/9.31S, the user information is decrypted while propagating the security.cfg file to the lower hub versions (7.97 or earlier).
Example Snippet
The following example shows that the user information is now available in the encrypted format in security.cfg for hub 9.31/9.31S:
<users> <pha1> password = $psv2$250406$wm2lyEX93qHfSpnjfnzykUQQZ41lSLbIOClbh0ikSJ3vyZJ0VrKcaWMd8H3HLaiMRRQJMFbVd4soZWy+4tFJdwCL5nYDYan7WIkyo6e18tT3x/xguQ== mobile = cUkLtAi5N59wz9fX7Q== email = 9Ou/8qEA/O/8sYAJRw== profile = GL9SVrpTnj46UB6igg== phone = cUkLtAi5N59wz9fX7Q== acl = FLKl1R+JomZPgag== </pha1> .... </users>
Restore the Backed-Up security.cfg File
If you want to restore the backed-up security.cfg file, you can do so.
The secedit file is applicable only for Windows. For Linux, the only way to restore the setup is to manually copy the backed-up files (security.cfg and security.dta).
Follow these steps:
  1. Get the secedit file from Support and put it in the ..\Nimsoft\hub folder.
  2. Disable both the parameters (
    psv2_password
    and
    encrypt_user_info
    )
    in the hub.cfg file.
  3. Stop the Nimsoft Robot watcher service.
  4. Close all instances of IM, Admin Console, and other components, if any.
  5. Delete the hubs.sds and robot.sds files from the ..\Nimsoft\hub folder.
  6. Start the Nimsoft Robot watcher service.
  7. Run secedit.exe.
  8. Enter the CA UIM administrator user and password. A notepad with the name security.txt is opened. This includes security information.
  9. Copy the contents of the backed-up security.cfg file into the opened notepad.
  10. Save the notepad.
  11. Restart the Nimsoft Robot watcher service.
  12. Log in to IM to verify the configuration changes, ACLs, users, and other settings.