We have Cisco Security Manager 4.5.0 Patch 3 and using it to manage hundreds of Cisco ASA FWs.
We found many failure attempts on our Radius servers. These records say the radius client is an ASA FW and calling station is Cisco Security Manager.
Debug on one of the Cisco ASA FWs revealed Cisco Security Manager uses first a NULL username to access Cisco ASA FWs and then the configured username ( we have it configured as 'use primary credentials' and the same for all FWs ). This is not dependent on the OS version we have on ASA FWs.
Here is the debug from a Cisco ASA FW, first Cisco Security Manager uses a username with no characters in it and when this attempt fails it uses the username that is configured in Cisco Security Manager by us as primary credentials.
%ASA-6-113005: AAA user authentication Rejected : reason = AAA failure : server = IPADDRESSREMOVED : user =
%ASA-6-611102: User authentication failed: Uname:
%ASA-6-605004: Login denied from IPADDRESSREMOVED/59208 to inside:IPADDRESSREMOVED/https for user ""
%ASA-6-725007: SSL session with client inside:IPADDRESSREMOVED/59208 terminated.
%ASA-6-302013: Built inbound TCP connection 1221667 for inside:1IPADDRESSREMOVED/59222 (1IPADDRESSREMOVED/59222) to identity:IPADDRESSREMOVED/443 (IPADDRESSREMOVED/443)
%ASA-6-725001: Starting SSL handshake with client inside:IPADDRESSREMOVED/59222 for TLSv1 session.
%ASA-7-725010: Device supports the following 4 cipher(s).
%ASA-7-725011: Cipher[1] : RC4-SHA
%ASA-7-725011: Cipher[2] : AES128-SHA
%ASA-7-725011: Cipher[3] : AES256-SHA
%ASA-7-725011: Cipher[4] : DES-CBC3-SHA
%ASA-7-725008: SSL client inside:PADDRESSREMOVED/59222 proposes the following 15 cipher(s).
%ASA-7-725011: Cipher[1] : RC4-MD5
%ASA-7-725011: Cipher[2] : RC4-SHA
%ASA-7-725011: Cipher[3] : AES128-SHA
%ASA-7-725011: Cipher[4] : DHE-RSA-AES128-SHA
%ASA-7-725011: Cipher[5] : DHE-DSS-AES128-SHA
%ASA-7-725011: Cipher[6] : DES-CBC3-SHA
%ASA-7-725011: Cipher[7] : EDH-RSA-DES-CBC3-SHA
%ASA-7-725011: Cipher[8] : EDH-DSS-DES-CBC3-SHA
%ASA-7-725011: Cipher[9] : DES-CBC-SHA
%ASA-7-725011: Cipher[10] : EDH-RSA-DES-CBC-SHA
%ASA-7-725011: Cipher[11] : EDH-DSS-DES-CBC-SHA
%ASA-7-725011: Cipher[12] : EXP-RC4-MD5
%ASA-7-725011: Cipher[13] : EXP-DES-CBC-SHA
%ASA-7-725011: Cipher[14] : EXP-EDH-RSA-DES-CBC-SHA
%ASA-7-725011: Cipher[15] : EXP-EDH-DSS-DES-CBC-SHA
%ASA-7-725012: Device chooses cipher : RC4-SHA for the SSL session with client inside:1IPADDRESSREMOVED/59222
%ASA-6-725002: Device completed SSL handshake with client inside:1IPADDRESSREMOVED/59222
%ASA-6-302014: Teardown TCP connection 1221666 for inside:IPADDRESSREMOVED/59208 to identity:1IPADDRESSREMOVED/443 duration 0:00:01 bytes 1054 TCP FINs
%ASA-6-113004: AAA user authentication Successful : server = IPADDRESSREMOVED : user = USERNAMEREMOVED
%ASA-6-113008: AAA transaction status ACCEPT : user = USERNAMEREMOVED
%ASA-6-611101: User authentication succeeded: Uname: USERNAMEREMOVED
%ASA-6-605005: Login permitted from IPADDRESSREMOVED/59222 to inside:1IPADDRESSREMOVED/https for user "USERNAMEREMOVED"
%ASA-7-111009: User 'USERNAMEREMOVED' executed cmd: show vpn-sessiondb full svc
%ASA-6-725007: SSL session with client inside:IPADDRESSREMOVED/59222 terminated.
Does anyone know is this a bug and is workaround known?
Thank you,
Vlad
