<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Cisco Security Manager uses a NULL username to access Cisco ASA FWs in Network Security</title>
    <link>https://community.cisco.com/t5/network-security/cisco-security-manager-uses-a-null-username-to-access-cisco-asa/m-p/2539405#M921754</link>
    <description>&lt;P&gt;&lt;A name="_GoBack" target="_blank"&gt;&lt;/A&gt;We have Cisco&amp;nbsp;Security Manager 4.5.0 Patch 3 and using it to manage hundreds of Cisco ASA FWs.&lt;BR /&gt;We found many failure attempts on our Radius servers. These records say the radius&amp;nbsp;client is an ASA FW and calling station is&amp;nbsp;Cisco&amp;nbsp;Security Manager.&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;Debug on one of the Cisco ASA FWs revealed&amp;nbsp;Cisco&amp;nbsp;Security Manager uses first a&amp;nbsp;&amp;nbsp;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.&lt;/P&gt;&lt;P&gt;Here is the debug from a Cisco ASA FW, first&amp;nbsp;Cisco&amp;nbsp;Security Manager uses a username with no characters in it and when this attempt fails it uses the username that is configured in&amp;nbsp;Cisco&amp;nbsp;Security Manager by us as&amp;nbsp;primary credentials.&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;%ASA-6-113005: AAA user authentication Rejected : reason = AAA failure : server = IPADDRESSREMOVED&amp;nbsp;: user =&lt;BR /&gt;%ASA-6-611102: User authentication failed: Uname:&lt;BR /&gt;%ASA-6-605004: Login denied from IPADDRESSREMOVED/59208 to inside:IPADDRESSREMOVED/https for user ""&lt;/STRONG&gt;&lt;BR /&gt;%ASA-6-725007: SSL session with client inside:IPADDRESSREMOVED/59208 terminated.&lt;BR /&gt;%ASA-6-302013: Built inbound TCP connection 1221667 for inside:1IPADDRESSREMOVED/59222 (1IPADDRESSREMOVED/59222) to identity:IPADDRESSREMOVED/443 (IPADDRESSREMOVED/443)&lt;BR /&gt;%ASA-6-725001: Starting SSL handshake with client inside:IPADDRESSREMOVED/59222 for TLSv1 session.&lt;BR /&gt;%ASA-7-725010: Device supports the following 4 cipher(s).&lt;BR /&gt;%ASA-7-725011: Cipher[1] : RC4-SHA&lt;BR /&gt;%ASA-7-725011: Cipher[2] : AES128-SHA&lt;BR /&gt;%ASA-7-725011: Cipher[3] : AES256-SHA&lt;BR /&gt;%ASA-7-725011: Cipher[4] : DES-CBC3-SHA&lt;BR /&gt;%ASA-7-725008: SSL client inside:PADDRESSREMOVED/59222 proposes the following 15 cipher(s).&lt;BR /&gt;%ASA-7-725011: Cipher[1] : RC4-MD5&lt;BR /&gt;%ASA-7-725011: Cipher[2] : RC4-SHA&lt;BR /&gt;%ASA-7-725011: Cipher[3] : AES128-SHA&lt;BR /&gt;%ASA-7-725011: Cipher[4] : DHE-RSA-AES128-SHA&lt;BR /&gt;%ASA-7-725011: Cipher[5] : DHE-DSS-AES128-SHA&lt;BR /&gt;%ASA-7-725011: Cipher[6] : DES-CBC3-SHA&lt;BR /&gt;%ASA-7-725011: Cipher[7] : EDH-RSA-DES-CBC3-SHA&lt;BR /&gt;%ASA-7-725011: Cipher[8] : EDH-DSS-DES-CBC3-SHA&lt;BR /&gt;%ASA-7-725011: Cipher[9] : DES-CBC-SHA&lt;BR /&gt;%ASA-7-725011: Cipher[10] : EDH-RSA-DES-CBC-SHA&lt;BR /&gt;%ASA-7-725011: Cipher[11] : EDH-DSS-DES-CBC-SHA&lt;BR /&gt;%ASA-7-725011: Cipher[12] : EXP-RC4-MD5&lt;BR /&gt;%ASA-7-725011: Cipher[13] : EXP-DES-CBC-SHA&lt;BR /&gt;%ASA-7-725011: Cipher[14] : EXP-EDH-RSA-DES-CBC-SHA&lt;BR /&gt;%ASA-7-725011: Cipher[15] : EXP-EDH-DSS-DES-CBC-SHA&lt;BR /&gt;%ASA-7-725012: Device chooses cipher : RC4-SHA for the SSL session with client inside:1IPADDRESSREMOVED/59222&lt;BR /&gt;%ASA-6-725002: Device completed SSL handshake with client inside:1IPADDRESSREMOVED/59222&lt;BR /&gt;%ASA-6-302014: Teardown TCP connection 1221666 for inside:IPADDRESSREMOVED/59208 to identity:1IPADDRESSREMOVED/443 duration 0:00:01 bytes 1054 TCP FINs&lt;BR /&gt;&lt;STRONG&gt;%ASA-6-113004: AAA user authentication Successful : server = &amp;nbsp;IPADDRESSREMOVED : user = USERNAMEREMOVED&lt;BR /&gt;%ASA-6-113008: AAA transaction status ACCEPT : user =&amp;nbsp;USERNAMEREMOVED&lt;BR /&gt;%ASA-6-611101: User authentication succeeded: Uname:&amp;nbsp;USERNAMEREMOVED&lt;BR /&gt;%ASA-6-605005: Login permitted from IPADDRESSREMOVED/59222 to inside:1IPADDRESSREMOVED/https for user "USERNAMEREMOVED"&lt;BR /&gt;%ASA-7-111009: User 'USERNAMEREMOVED' executed cmd: show vpn-sessiondb full svc&lt;/STRONG&gt;&lt;BR /&gt;%ASA-6-725007: SSL session with client inside:IPADDRESSREMOVED/59222 terminated.&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Does anyone know is this a bug and is workaround known?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Thank you,&lt;/P&gt;&lt;P&gt;Vlad&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
    <pubDate>Fri, 21 Feb 2020 13:18:14 GMT</pubDate>
    <dc:creator>vladakoci</dc:creator>
    <dc:date>2020-02-21T13:18:14Z</dc:date>
    <item>
      <title>Cisco Security Manager uses a NULL username to access Cisco ASA FWs</title>
      <link>https://community.cisco.com/t5/network-security/cisco-security-manager-uses-a-null-username-to-access-cisco-asa/m-p/2539405#M921754</link>
      <description>&lt;P&gt;&lt;A name="_GoBack" target="_blank"&gt;&lt;/A&gt;We have Cisco&amp;nbsp;Security Manager 4.5.0 Patch 3 and using it to manage hundreds of Cisco ASA FWs.&lt;BR /&gt;We found many failure attempts on our Radius servers. These records say the radius&amp;nbsp;client is an ASA FW and calling station is&amp;nbsp;Cisco&amp;nbsp;Security Manager.&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;Debug on one of the Cisco ASA FWs revealed&amp;nbsp;Cisco&amp;nbsp;Security Manager uses first a&amp;nbsp;&amp;nbsp;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.&lt;/P&gt;&lt;P&gt;Here is the debug from a Cisco ASA FW, first&amp;nbsp;Cisco&amp;nbsp;Security Manager uses a username with no characters in it and when this attempt fails it uses the username that is configured in&amp;nbsp;Cisco&amp;nbsp;Security Manager by us as&amp;nbsp;primary credentials.&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;%ASA-6-113005: AAA user authentication Rejected : reason = AAA failure : server = IPADDRESSREMOVED&amp;nbsp;: user =&lt;BR /&gt;%ASA-6-611102: User authentication failed: Uname:&lt;BR /&gt;%ASA-6-605004: Login denied from IPADDRESSREMOVED/59208 to inside:IPADDRESSREMOVED/https for user ""&lt;/STRONG&gt;&lt;BR /&gt;%ASA-6-725007: SSL session with client inside:IPADDRESSREMOVED/59208 terminated.&lt;BR /&gt;%ASA-6-302013: Built inbound TCP connection 1221667 for inside:1IPADDRESSREMOVED/59222 (1IPADDRESSREMOVED/59222) to identity:IPADDRESSREMOVED/443 (IPADDRESSREMOVED/443)&lt;BR /&gt;%ASA-6-725001: Starting SSL handshake with client inside:IPADDRESSREMOVED/59222 for TLSv1 session.&lt;BR /&gt;%ASA-7-725010: Device supports the following 4 cipher(s).&lt;BR /&gt;%ASA-7-725011: Cipher[1] : RC4-SHA&lt;BR /&gt;%ASA-7-725011: Cipher[2] : AES128-SHA&lt;BR /&gt;%ASA-7-725011: Cipher[3] : AES256-SHA&lt;BR /&gt;%ASA-7-725011: Cipher[4] : DES-CBC3-SHA&lt;BR /&gt;%ASA-7-725008: SSL client inside:PADDRESSREMOVED/59222 proposes the following 15 cipher(s).&lt;BR /&gt;%ASA-7-725011: Cipher[1] : RC4-MD5&lt;BR /&gt;%ASA-7-725011: Cipher[2] : RC4-SHA&lt;BR /&gt;%ASA-7-725011: Cipher[3] : AES128-SHA&lt;BR /&gt;%ASA-7-725011: Cipher[4] : DHE-RSA-AES128-SHA&lt;BR /&gt;%ASA-7-725011: Cipher[5] : DHE-DSS-AES128-SHA&lt;BR /&gt;%ASA-7-725011: Cipher[6] : DES-CBC3-SHA&lt;BR /&gt;%ASA-7-725011: Cipher[7] : EDH-RSA-DES-CBC3-SHA&lt;BR /&gt;%ASA-7-725011: Cipher[8] : EDH-DSS-DES-CBC3-SHA&lt;BR /&gt;%ASA-7-725011: Cipher[9] : DES-CBC-SHA&lt;BR /&gt;%ASA-7-725011: Cipher[10] : EDH-RSA-DES-CBC-SHA&lt;BR /&gt;%ASA-7-725011: Cipher[11] : EDH-DSS-DES-CBC-SHA&lt;BR /&gt;%ASA-7-725011: Cipher[12] : EXP-RC4-MD5&lt;BR /&gt;%ASA-7-725011: Cipher[13] : EXP-DES-CBC-SHA&lt;BR /&gt;%ASA-7-725011: Cipher[14] : EXP-EDH-RSA-DES-CBC-SHA&lt;BR /&gt;%ASA-7-725011: Cipher[15] : EXP-EDH-DSS-DES-CBC-SHA&lt;BR /&gt;%ASA-7-725012: Device chooses cipher : RC4-SHA for the SSL session with client inside:1IPADDRESSREMOVED/59222&lt;BR /&gt;%ASA-6-725002: Device completed SSL handshake with client inside:1IPADDRESSREMOVED/59222&lt;BR /&gt;%ASA-6-302014: Teardown TCP connection 1221666 for inside:IPADDRESSREMOVED/59208 to identity:1IPADDRESSREMOVED/443 duration 0:00:01 bytes 1054 TCP FINs&lt;BR /&gt;&lt;STRONG&gt;%ASA-6-113004: AAA user authentication Successful : server = &amp;nbsp;IPADDRESSREMOVED : user = USERNAMEREMOVED&lt;BR /&gt;%ASA-6-113008: AAA transaction status ACCEPT : user =&amp;nbsp;USERNAMEREMOVED&lt;BR /&gt;%ASA-6-611101: User authentication succeeded: Uname:&amp;nbsp;USERNAMEREMOVED&lt;BR /&gt;%ASA-6-605005: Login permitted from IPADDRESSREMOVED/59222 to inside:1IPADDRESSREMOVED/https for user "USERNAMEREMOVED"&lt;BR /&gt;%ASA-7-111009: User 'USERNAMEREMOVED' executed cmd: show vpn-sessiondb full svc&lt;/STRONG&gt;&lt;BR /&gt;%ASA-6-725007: SSL session with client inside:IPADDRESSREMOVED/59222 terminated.&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Does anyone know is this a bug and is workaround known?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Thank you,&lt;/P&gt;&lt;P&gt;Vlad&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Fri, 21 Feb 2020 13:18:14 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/cisco-security-manager-uses-a-null-username-to-access-cisco-asa/m-p/2539405#M921754</guid>
      <dc:creator>vladakoci</dc:creator>
      <dc:date>2020-02-21T13:18:14Z</dc:date>
    </item>
    <item>
      <title>Not sure but it happens in</title>
      <link>https://community.cisco.com/t5/network-security/cisco-security-manager-uses-a-null-username-to-access-cisco-asa/m-p/2539406#M921755</link>
      <description>&lt;P&gt;Not sure but it happens in CSM 4.4.0SP2 as well. &amp;nbsp;I am hoping it goes away as of 4.7. &amp;nbsp;But, it doesn't seem tremendously harmful, either.&lt;/P&gt;</description>
      <pubDate>Tue, 11 Nov 2014 00:56:18 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/cisco-security-manager-uses-a-null-username-to-access-cisco-asa/m-p/2539406#M921755</guid>
      <dc:creator>PAUL TRIVINO</dc:creator>
      <dc:date>2014-11-11T00:56:18Z</dc:date>
    </item>
    <item>
      <title>I just got asked to look at</title>
      <link>https://community.cisco.com/t5/network-security/cisco-security-manager-uses-a-null-username-to-access-cisco-asa/m-p/2539407#M921757</link>
      <description>&lt;P&gt;I just got asked to look at the same situation by one of our security people.&lt;/P&gt;&lt;P&gt;We have exactly the same problem but it reports a username of "*****" and we are running CSM 4.7 (upgraded last week)&lt;/P&gt;</description>
      <pubDate>Mon, 02 Feb 2015 14:40:34 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/cisco-security-manager-uses-a-null-username-to-access-cisco-asa/m-p/2539407#M921757</guid>
      <dc:creator>bgl-group</dc:creator>
      <dc:date>2015-02-02T14:40:34Z</dc:date>
    </item>
    <item>
      <title>Same Problem with CSM 4.12</title>
      <link>https://community.cisco.com/t5/network-security/cisco-security-manager-uses-a-null-username-to-access-cisco-asa/m-p/2539408#M921758</link>
      <description>&lt;P&gt;Same Problem with CSM 4.12&lt;/P&gt;
&lt;P&gt;&lt;/P&gt;
&lt;P&gt;...hope it will be fixed soon...&lt;/P&gt;</description>
      <pubDate>Mon, 26 Sep 2016 15:26:24 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/cisco-security-manager-uses-a-null-username-to-access-cisco-asa/m-p/2539408#M921758</guid>
      <dc:creator>Jens Weber</dc:creator>
      <dc:date>2016-09-26T15:26:24Z</dc:date>
    </item>
    <item>
      <title>I'm seeing the same thing.</title>
      <link>https://community.cisco.com/t5/network-security/cisco-security-manager-uses-a-null-username-to-access-cisco-asa/m-p/2539409#M921760</link>
      <description>&lt;P&gt;I'm seeing the same thing. &amp;nbsp;Is there a bug related to this behavior?&lt;/P&gt;</description>
      <pubDate>Thu, 20 Oct 2016 19:22:44 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/cisco-security-manager-uses-a-null-username-to-access-cisco-asa/m-p/2539409#M921760</guid>
      <dc:creator>chrissa</dc:creator>
      <dc:date>2016-10-20T19:22:44Z</dc:date>
    </item>
    <item>
      <title>Re: Cisco Security Manager uses a NULL username to access Cisco ASA FWs</title>
      <link>https://community.cisco.com/t5/network-security/cisco-security-manager-uses-a-null-username-to-access-cisco-asa/m-p/3313838#M921762</link>
      <description>&lt;P&gt;Hi&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;The problem is related to the following bug:&lt;/P&gt;
&lt;P&gt;&lt;A href="https://bst.cloudapps.cisco.com/bugsearch/bug/CSCua86550" target="_blank"&gt;https://bst.cloudapps.cisco.com/bugsearch/bug/CSCua86550&lt;/A&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;You can fix it with the following workaround:&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&lt;SPAN&gt;Following steps are for Reporting Component:&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;1. Go to &lt;/SPAN&gt;\MDC\reports\config&lt;BR /&gt; needs to be substituted by the directory where CSM has been&lt;BR /&gt;installed.&lt;BR /&gt;For example: E:\Program Files\CSCOpx\MDC\reports\config&lt;BR /&gt;2. Open the "communication.properties" file using a text editor.&lt;BR /&gt;This file contains the configuration for how CSM logs into devices when&lt;BR /&gt;it collects information for the Report Manager.&lt;BR /&gt;3. Locate the line that reads:&lt;BR /&gt;USE_ENABLE_PASSWORD_FIRST=true&lt;BR /&gt;4. Replace the word "true" with the word "false". The line should now&lt;BR /&gt;read:&lt;BR /&gt;USE_ENABLE_PASSWORD_FIRST=false&lt;BR /&gt;5. Save the changes that have been made to the file&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;Following steps are for HPM Component:&lt;BR /&gt;&lt;BR /&gt;1. Go to \MDC\hpm\config\&lt;BR /&gt; needs to be substituted by the directory where CSM has been&lt;BR /&gt;installed.&lt;BR /&gt;For example: E:\Program Files\CSCOpx\MDC\hpm\config\&lt;BR /&gt;2. Open the "communication.properties" file using a text editor.&lt;BR /&gt;This file contains the configuration for how CSM logs into devices when&lt;BR /&gt;it collects information for the Health and Performance Monitor.&lt;BR /&gt;3. Locate the line that reads:&lt;BR /&gt;USE_ENABLE_PASSWORD_FIRST=true&lt;BR /&gt;4. Replace the word "true" with the word "false". The line should now&lt;BR /&gt;read:&lt;BR /&gt;USE_ENABLE_PASSWORD_FIRST=false&lt;BR /&gt;5. Save the changes that have been made to the file&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&lt;BR /&gt;The following is for Discovery/Deployment:&lt;BR /&gt;&lt;BR /&gt;1. Go to \MDC\athena\config&lt;BR /&gt; needs to be substituted by the directory where CSM has been&lt;BR /&gt;installed.&lt;BR /&gt;For example: E:\Program Files\CSCOpx\MDC\reports\config&lt;BR /&gt;2. Open the "DCS.properties" file using a text editor.&lt;BR /&gt;This file contains the configuration for how CSM logs into devices&lt;BR /&gt;during Discovery/Deployment/Image Management.&lt;BR /&gt;3. Locate the line that reads:&lt;BR /&gt;DCS.useEnablePasswordFirstForFw=true&lt;BR /&gt;4. Replace the word "true" with the word "false". The line should now&lt;BR /&gt;read:&lt;BR /&gt;DCS.useEnablePasswordFirstForFw=false&lt;BR /&gt;5. Save the changes that have been made to the file&lt;BR /&gt;&lt;BR /&gt;Restart the daemon manager:&lt;BR /&gt;&lt;BR /&gt;1. Open the Windows Command Prompt&lt;BR /&gt;2. Execute the following command: net stop crmdmgtd&lt;BR /&gt;3. Wait for the message that indicates that the services have stopped&lt;BR /&gt;4. Execute the following command: net start crmdmgtd&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Regards Andrin&lt;/P&gt;</description>
      <pubDate>Thu, 18 Jan 2018 16:00:39 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/cisco-security-manager-uses-a-null-username-to-access-cisco-asa/m-p/3313838#M921762</guid>
      <dc:creator>arickenbach</dc:creator>
      <dc:date>2018-01-18T16:00:39Z</dc:date>
    </item>
  </channel>
</rss>

