Document ID: TEC1201257Last Modified Date: 05/27/2016 Hide Technical Document Details
Products
Releases
Components
Sometimes it is necessary to recover a corrupted security.cfg file or add sections to the file that have been removed or have disappeared from the file for some unknown reason. The security.cfg file contains all security data: users, passwords, ACLs and probe permissions. All hubs have a security.cfg file and all hubs sync to the highest version number. You can see this version number at the top of your security.cfg. It is sometimes necessary, in the event of corruption, to recover a security.cfg file. It is also a best practice back this file up regularly. If you have a backup of your security.cfg file, you can use this procedure to recover a corrupt security.cfg for your hub.
CA UIM (NMS) version 7.x or higher
KB000043713 - How to use the secedit utility to recover a corrupted security.cfg file or add missing sections to the security.cfg file
Updated the link to point to the knowledge doc (KB000043713)
Nine instructions goes to a 404 error.
Hi,
If you only have Linux hubs you could create a temporary windows secondary hub. Let the security file sync to it.
Then use secedit on that system making sure to increase the version number in the file along with your other changes
and then this will be synced back to the other systems.
Hi Tomas,
There is no secedit for Linux. The security files for the hub are in the hub folder in the Nimsoft install folder on the primary hub. You should see several files here: security.cfg, security.dta and security.bak. If you have single hub, and you did not change the hub ip, you could try to restore the security files from a file backup. If you can reach the system via the Infrastructure Manager (IM), then all you need to do to reset hub security is stop the robot service on the hub, rename /opt/nimsoft/hub/security.cfg, security.back and .dta files, start the robot service, then connect to IM and it should prompt you to reset security and enter a new password.
Do you have more than one hub, and are any of these hubs connected directly to the primary hub? If you do, you could try to do the following: - stop the robot on the primary hub - remove the current security.* files from the hub folder (to another folder for example) - restart the robot, this will also start the hub probe - you should see the hub syncing the security files with the ones present on the secondary hub (you can confirm this by opening the security.cfg using notepad and check the version at the top, a new file usually has a version of 0001 or 0002 and the latest security.cfg file has the highest number, e.g., 5556.
Steve
Valid for Linux?