security.cfg file keeps getting corrupted - need to find way to notify if this file gets changed

Document ID : KB000117227
Last Modified Date : 09/10/2018
Show Technical Document Details
We have had a number of incidents where somehow the security.cfg file becomes changed or corrupted or *something* happens that erases all of the groups and permissions we have set up in it. When this propagates to the other hubs we lose all settings. There is a KB out there that shows how to replace and/or restore the security.cfg file, but it has never worked for our environment. Regardless. What we need is a way to be notified if this file changes so we can get out ahead of the issue, restore the config file manually (as we have had to do the last several times this has happened) before this starts to impede our alarming. thank you!
- UIM 8.5.1
- hub v7.93
hub security.cfg file corruption is usually caused by competing security updates or something going wrong in transit.
For notification of security.cfg file changes, you could probably setup dirscan or logmon to check the file information and send an alert based on the result.

Make sure you are on the latest hub v7.93 and you also may want to implement this solution (see below).

* By default, changes to security.cfg are propagated from any hub. Two configuration keys affect this behavior:

o Set secure_callbacks_from_primary_hub_only in security.cfg. Default: no
- When the key is set to yes:
The primary hub propagates security changes to all hubs in the domain. When this value is set to no, a hub only propagates security changes to nearby hubs. Nearby hubs are hubs that are one level away.
- A secondary hub rejects security updates from other version, 7.92HF1 and above secondary hubs. Updates from pre-7.92HF1 secondary hubs and primary hubs are accepted. Accepting updates from pre-7.92HF1 hubs eases an incremental upgrade.

A user cannot make security-related callbacks on a secondary hub. Security-related callbacks include:

- user_change_password
- user_delete
- user_edit
- user_new
- probe_delete
- probe_new
- profile_delete
- profile_delete_ex
- profile_put
- profile_put_ex
- profile_users_set
- hubsec_delete
- hubsec_edit
- hubsec_new
- hubsec_restore
- hubsec_setup_put
- hubsec_update

When a probe is installed, the secondary hub receives a request to add a probe to the security file, this request is forwarded to the Primary hub. The Primary hub then executes the request and propagates the security file update to all the other hubs in the domain.

When the key-> secure_callbacks_from_primary_hub_only is disabled, the primary hub propagates the change to all other hubs before disabling it in itself.
This value is changed with the hubsec_setup_put callback.

o Set security_config_propagation in hub.cfg. Default: yes
- When the key is set to yes, the hub can propagate updates to security.cfg to all other hubs in the domain.
- When the key is set to no, the hub cannot propagate updates that it receives.
-The primary hub ignores the value of this key, and propagates updates even when the key is set to no.
- This value must be explicitly set in each hub.cfg file. Restart the hub for the change to take effect.

***** The following configuration is recommended for all domains:*****
- Set secure_callbacks_from_primary_hub_only to yes
- Set security_config_propagation to no

This combination ensures that:

- Security updates propagate from the primary hub only.
- Security updates propagate to all the hubs in the domain, regardless of the proximity to the primary hub.
Additional Information:
The information above is documented.