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
1. Close any open clients such as Infrastructure Manager and any other open clients such as nas or other probe windows. Kill any leftover Infrastructure Manager application processes using task manager.
2. Copy the secedit7.exe (attached) to the hub folder on the primary hub (CA UIM/Nimsoft Server).
a) Using services.msc, stop the Nimsoft Robot watcher service.
b) Create a 'backup' folder within the hub folder.
NOTE: If you do not KNOW the administrator password or it is not working, use the Move option below, otherwise use the Copy option:
Move Option: MOVE the hub security.* files (security.bak, security.cfg, and security.dta) into the backup folder.
Copy Option: Copy the hub security.* files (security.bak, security.cfg, and security.dta) into the backup folder
c) Remove the hubs.sds and robot.sds files
* Note that you may first have to disable all Inbound firewall rules related to Nimsoft application and/or disable broadcast and/or tunneling, IF the hub security.* files are getting updated (overridden) when you start up the Robot service again.
d) Start the Nimsoft Robot watcher service.
NOTE: The next two sections ONLY apply if you used the MOVE option above.
e) Log into IM and it will prompt you to initialize security, then select Yes
Initialize Security (Initialize Security = Remove the security.cfg then try to log in with IM and you will be prompted to set an administrator password)
f) Enter a password for the administrator and click Ok.
Do NOT login if IM prompts you...just perform the next step below...
3. Next, double click to run secedit7.exe
Enter administrator for the Login and enter the administrator password. This is the same login and password you use to login to the Infrastructure Manager.
4. That will create and open up a notepad.txt file with the security information included.
5. Replace the text file contents with all contents of your security.cfg backup...OR if you know of any configuration adjustments that need to be made, make them, e.g., add missing sections, users etc., but be very careful.)
Note also that at the top of the file you will see the version, e.g.,
version = 0095
expire = 21600
ignore_ip = no
auth_mode = 0
signature = Z/zq/sj6qCC3iJ9G6ttoZw==
domain = holje07-U157934_domain
This version number MUST be the highest version number in your environment, otherwise when the hub connect, the security.cfg may get overridden by another hub’s security file.
You can check your remote/secondary hubs security.cfg files to be certain or set the number much higher than the current hub.
6. Click File -> Save to save the notepad security.txt file and then close the window. The secedit window will also close automatically.
7. Restart the Nimsoft Robot Watcher service.
8. Login to Infrastructure Manager and verify the configuration changes, ACLs, users, etc.
9. If everything checks out, make sure you re-enable any hub or firewall settings mentioned above or otherwise that you disabled to prevent overwriting the security file.
Note that under normal circumstances, you do not have to change the version of the security file. This is automatically set when the security file is created and increases every time a change is made. That said, MAKE SURE that you are using the most current version of the security.cfg file. The new file MUST contain a version higher than the current version otherwise a remote/secondary hub, once connected to the primary, may overwrite it, hence you will lose any changes.
Here is the secedit7 attachment:
Further troubleshooting information:
If you still cannot login and you see a prompt from using secedit:
This utility lets you change the security.cfg file in notepad.
Make sure that no one is modifying the configuration while you edit it.
Login as administrator.
...and/or you see a prompt in the Infrastructure Manager (IM),
"The user name or password is incorrect. Letters must be typed using the correct case. Make sure the Caps Locks is not accidentally on" for correct password and usernames, same for LDAP access."
Then on the primary or remote hub you're trying to login to, check the hub.cfg <hub> section, and make sure that the login parameter setting is NOT set to nobody, e.g.,
login = nobody
Instead it should be set to normal.
login = normal
If it is set to nobody take the following steps:
- Login to the hub
- Deactivate the hub robot (controller) service
- edit the hub.cfg and set
login = normal
- Activated the hub robot
You should then able to login with no problem.