I am having an odd issue happen. This has happened twice within a couple months and I am not sure what is going on. I have ACL's created for multiple customers and my Contacts are assigned to the ACL's. The problem that has happened is the Non System Default ACL's keep disappearing. I currently only had 2 ACLs so it wasnt to harmful to add them back but I need to know why they keep getting removed. I haven't made changes to NMS or anything, I come back from the weekend and they are gone. Any Ideas?
Hi Jarrod, All the ACL information should be stored in the security files, and replicated across your environment to each hub. The security.cfg file in the $nimroot\hub directory should have the references to all your ACLs. If this file gets corrupted or deleted in some fashion, you will be asked to "Re-initialize" security on your hub, and a new set of security files will be created (with blank/standard ACLs). It sounds like this may be happening in your environment; Does the "reinitialize security" message seem familiar?
What does your hub architecture look like? (Tunnels, secondary/failover hubs?)
There should be a backup of the security file (security.bak), but it may be wise to keep an "off-site" backup of this file, as the backup is overwritten each time you make a change to your security (users,acls,etc).
I ran into a rare but recurring problem where only certain sections of the security.cfg file would go missing rather than the whole file being deleted. I know for a fact that this included the <acls> and <acl_template> sections; I am not sure if it included any other sections. I know it did not include the <users> section; we still could login but could not make any changes because our ACLs were gone. And every time this occurred it affected the same sections; that behavior was consistent. I know that this only happened when we setup brand new hubs that connected and downloaded the security.cfg file for the first time. However, we were never able to determine why it happened or why it did not happen consistently with every new hub. Because we never determined the root cause, I do not know if it has been fixed.
I am not sure if this is the same issue you are seeing, but it may be related. Do you think you added new hubs at the times the ACLs disappeared?-Keith
Thanks for the replys. This happened again today and it this time wiped out all of the ACL's so my login lets me login to Infrastructure Manager but I have no permissions. The Security.cfg file has users but no ACL's in it, the Security.bak has the correct information in it. I replaced the file, do I have to restart the HUB? My coworker was deploying HUBS this week so that may be what happened earlier this week, but today the ACLS are gone and its the default ones as well as newly added ones and we have not added any HUBs since I fixed the ACLs yesterday only probe deploys and we had setup some Queues today for existing HUBS. I don't remember any issues with this before we upgraded to NMS 5.0, only since the upgrade. I will start backing the file up daily but would love to get a solution to this.
My infrastructure is multiple DMZ Tunneling HUBS, One Primary backend HUB, Seperate SQL Server and Seperate UMP server. I am running NMS 5.0 with UMP 2.0.
I restarted the Main Hub after i replaced the Security.cfg with the good security.bak and the ACLS now show up. I did get the Reinitialize Security message and had to type in the admin password when i start infrastructure manager back up after the main HUB started up but now the ACLS are good.
Years later this still occasionally happens to us. Just the ACL's disappear everything else remains intact.
This happened weeks ago at one of my customer. All ACL's disappear in the security.cfg, everthing else remains. Due to hub sync all security.cfg lost the ACLs. It happened for the first and hopefully the last time.
I have 2300 hubs and yes, this happens to me all the time.
What I have been told is that this is caused by a race condition in the hub code that addresses handling updates to the security file. There also seems to be some dependence on the installation of a probe that needs to add itself to the <probes> section of the security.cfg file but that's not a definite.
Use of hub 7.72 everywhere seems to be the sweet spot for minimizing the occurrence of the issue at this point in my experience. With 7.72 I've gone from a multi hour outage every week to about once a month due to this.
And when/if this happens, do make sure that the propagation storm that this creates is over before you try to fix the security. It seems like if you try to fix it while things are still changing, the system gets angry.