Questions regarding managing ASA 5525 & PRSM 9.3

[mark.levy]

Good day,

My company recently purchased a pair of ASA 5525s, and we're managing them with PRSM 9.3.  Unfortunately, we lost our security administrator, and while we understand the basics of managing the system, we were never "cross-trained" on this device, and we don't know how to do some of the basic administration of the system.  I've been through the "User Guide for ASA CX and Cisco Prime Security Manager" and I simply haven't been able to locate how to do these things.

We were originally told that we never change ANYTHING directly from the ASA CLI or ASDM, with the exception of setting up VPNs.  Having been through the docs, google searched, and scouring the PRSM interface, I haven't been able to find how to change the ASA usernames & passwords, or the enable password.  It appears that they can only be changed through the CLI or ASDM.  I'm not talking about the PRSM user accounts, but the actual ASA device accounts, created with the "username" CLI command, as well as the enable password.  Would changing the administrative user & enable passwords through the CLI or ASDM cause the PRSM database to go out-of-sync with the ASAs?

In that vein is how to find if the ASAs are out of sync with the PRSM database.  It appears that we had an error on 4/27, and it showed up in the Administration => Change History:  The original error on the 27th was from an attempt to add a range of IP addresses to the "Allowed-IP" network group object, complaining about a bad certificate.  However, it appeared to accept the same change 4 minutes later, when the user tried again to enter it, from the same client.  That error seems to still be in the change history, and then just this morning, one of our administrators reported seeing an error, but the change was accepted.  That error seems to appear as a second, additional entry in the 4/27 error in the change log (please see attached jpg, with both errors, however the user was adding a domain name to an "allowed sites" network group object.  The link to the transcript was useless, as all 3 tabs (Delta CLI, Full Configuration, Full Deplyment Transcript) had the same information, "This transcript type was not found for the device."

Any help would be very much appreciated, as well as pointers to some useful documentation, that will help us better manage the ASA/PRSM system.

Thanks!

Mark

[Marvin Rhoads]

PRSM has the ability to manage to CX module, the base ASA (in a limited fashion) or both. It sounds like the former admin set it up for both (but perhaps not completely correctly).

The certificate error means PRSM doesn't like the certificate is gets from the base ASA when connecting via https to perform its management action. That could be because it was not cirrectly setup, because the ASA didi not have a persistent self-signed certificate and had been reloaded, or due to a bug in PRSM.

My recommendation would be to unmanage the base ASA and only use PRSM for the CX module. Then you can simply do all of the usually ASA configuration bits via cli or ASDM and only go the PRSM for the CX policy setup and monitoring. Even though that sounds a bit more complex, I'd say it will make management of the ASA easier in the long run.

[mark.levy]

I just wanted to contact you to let you know that we, thanks to the consultant who installed our ASA/PRSM ststen have figured out where the problem was.

The first problem seemed to be that the certificates just needed to be refreshed, though the problem only occurred a few times in over a month.

The main problem was the fact that of the administrative passwords we had changed in the ASA using the "username" command, one of those accounts was also the PRSM sync account.  We didn't change the CX password on the ASA, so that explains why we were still able to partly manage PRSM.  Once we changed that sync account password in the PRSM, everything went back to normal.

Thanks very much for your assistance!

Mark

[Marvin Rhoads]

Glad it's working. I hope my pointers helped.

Thanks for letting us know the outcome.

[mark.levy]

Thanks to the consultant who installed our ASA/PRSM ststen have figured out where the problem was.

The first problem seemed to be that the certificates just needed to be refreshed, though the problem only occurred a few times in over a month.

The main problem was the fact that of the administrative passwords we had changed in the ASA using the "username" command, one of those accounts was also the PRSM sync account.  We didn't change the CX password on the ASA, so that explains why we were still able to partly manage PRSM.  Once we changed that sync account password in the PRSM, everything went back to normal.