We just started using this solution to backup ASA firewalls and some other Cisco devices for our clients and we are getting syslog alerts when this polls the device to get the backup. We add the device into the system and the discovery runs/completes without any issues. We run the backup manually and it grabs the config with no issues on the Unimus side.
Our syslogs for ALL ASA firewalls show entries as shown below for our connection when Unimus logs into the firewall. The credentials are working properly for all devices and the configs get backed up fine but we don't understand the commands/timeouts/etc. that Unimus uses for the devices when it runs the backup job. Are we able to adjust these? get more info on why this occurs for ALL ASA firewalls when the backup runs either manually or automated? any help would be greatly appreciated.
%ASA-6-113015: AAA user authentication Rejected : reason = Invalid password : local database : user = user-configs : user IP = 199.x.x.x
Backup runs/completes - ASA Syslog shows invalid password?
Hi,
Are you using credential discovery or credential binding? It's possible those alerts are from Discovery (Unimus runs both a discovery and a backup during scheduled jobs). I would also suggest reviewing our Wiki articles for Discovery, Backup and Timeout Configuration.
It might also be useful to enable "Device output logging" under "Zones > your_zone > Debug mode". This will log the entire device communication (the data on the SSH session) to the device output log file, and you can review this to see how Unimus logs in to the device during the scheduled jobs. Hopefully this might show what's going on to generate those alerts.
Hope this helps.
Are you using credential discovery or credential binding? It's possible those alerts are from Discovery (Unimus runs both a discovery and a backup during scheduled jobs). I would also suggest reviewing our Wiki articles for Discovery, Backup and Timeout Configuration.
It might also be useful to enable "Device output logging" under "Zones > your_zone > Debug mode". This will log the entire device communication (the data on the SSH session) to the device output log file, and you can review this to see how Unimus logs in to the device during the scheduled jobs. Hopefully this might show what's going on to generate those alerts.
Hope this helps.