CSM 4.0.1 is removing ACS Server password and then cannot add a new

[pweichmann]

Hi,

We just wanted to use CSM 4.0.1 to change ACS Server keyword on a FWSM 3.2(5) but in the transcript I see how he removes the key and then the next statement is to add a 127.0.0.1 ACS Server that I have never defined and that failes because the connection is lost.

Can CSM be used to change the ACS keyword and not loose the connection before changing it? The product allows such a change and does not stop albeit it should now that this is unsuccessful.

Here is the transcript!

Line# 2. (SUCCESS) Sent (Thu Dec 16 16:22:13 CET 2010): no snmp-server host fwsm-admin-context xxxx poll community comm1

Received (Thu Dec 16 16:22:14 CET 2010):

Line# 3. (SUCCESS) Sent (Thu Dec 16 16:22:13 CET 2010): aaa-server aaa-central (fwsm-admin-context) host xxxx

Received (Thu Dec 16 16:22:14 CET 2010):

Line# 4. (SUCCESS) Sent (Thu Dec 16 16:22:13 CET 2010):  no key oldkey

Received (Thu Dec 16 16:22:14 CET 2010):

Line# 5. (SUCCESS) Sent (Thu Dec 16 16:22:13 CET 2010): exit

Received (Thu Dec 16 16:22:14 CET 2010):

Line# 6. (SUCCESS) Sent (Thu Dec 16 16:22:13 CET 2010): no logging host fwsm-admin-context xxxx

Received (Thu Dec 16 16:22:14 CET 2010):

Line# 7. (SUCCESS) Sent (Thu Dec 16 16:22:13 CET 2010): ssh timeout 30

Received (Thu Dec 16 16:22:14 CET 2010):

Line# 8. (SUCCESS) Sent (Thu Dec 16 16:22:13 CET 2010): ssh version 2

Received (Thu Dec 16 16:22:14 CET 2010):

Line# 9. (SUCCESS) Sent (Thu Dec 16 16:22:13 CET 2010): logging buffer-size 1048576

Received (Thu Dec 16 16:22:14 CET 2010):

Line# 10. (SUCCESS) Sent (Thu Dec 16 16:22:13 CET 2010): no logging debug-trace

Received (Thu Dec 16 16:22:14 CET 2010):

Line# 11. (SUCCESS) Sent (Thu Dec 16 16:22:13 CET 2010): logging trap informational

Received (Thu Dec 16 16:22:14 CET 2010):

Line# 12. (SUCCESS) Sent (Thu Dec 16 16:22:13 CET 2010): logging asdm debugging

Received (Thu Dec 16 16:22:14 CET 2010):

Line# 13. (SUCCESS) Sent (Thu Dec 16 16:22:13 CET 2010): logging buffered debugging

Received (Thu Dec 16 16:22:14 CET 2010):

Line# 14. (ERROR) Sent (Thu Dec 16 16:22:13 CET 2010): aaa-server aaa-central host 127.0.0.1

Received (Thu Dec 16 16:22:14 CET 2010): ERROR: Interface "(inside)" does not exist. Please specify a valid interface name for this server

! COMMENT: Device reported error here and stopped accepting further commands

! COMMENT: BULK END

Line# 15. (ERROR) Sent (Thu Dec 16 16:22:14 CET 2010): https://xxxx/config?context=admin Received (Thu Dec 16 16:22:14 CET 2010): 24300 : Login failed

Caused by: Authentication failed on device [193.47.16.28]. Check the credentials.

Error: Server returned HTTP response code: 401 for URL: https://xxxx/config?context=admin

I think there are multiple problems, first it removes the key but does not add one and then it wants to add 127.0.0.1 to it and does not use an interface?

[Stefano De Crescenzo]

Hi,

I have seen this problem in the past and it was usually related to the fact that you did not specify a specific interface in the aaa-server settings in the CSM.

Can you please try to edit the aaa-server on which you changed the key and add the interface where the ACS is located?

That should fix workaround the issue. If it is still does not work, this might be a new defect, so I advise you to open a SR so that TAC can investigate further.

Stefano

[pweichmann]

I would say that it it the interface problem but not that it had no interface but it had another interface.

The whole interface story is somewhat stupefying for me.

What I wanted to do is to use a single AAA Server definition for all my contexts on a FWSM, due to multiple imports in the beginning I ended up having 40 or so in the objects.

Each interface that we have on a context has a different name and it looks like CSM has a problem with this. We have tried to use interface with wildcards, but you cannot specify something like *context* or *vlan*. For us *context* is inside and *vlan* is outside.

This verification of the AAA Server should be done before trying to deploy and then not having access. Luckily all our contexts had their own AAA connection setup, so I could make changes. Because we have not used the local use for more than 3 years and had 3 weeks to search it. We almost rebooted the FWSM this Sunday (using a maintenance window) but found the password last thursday.