<?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 Re: Double Authentication on ASA using ISE in Network Access Control</title>
    <link>https://community.cisco.com/t5/network-access-control/double-authentication-on-asa-using-ise/m-p/3731607#M489264</link>
    <description>&lt;P&gt;Hsing,&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;This is more of a product request, but one thing that would help in cases like this is if we were able to use the DestPort field in our rule set.&amp;nbsp; If you look at the RADIUS authentication details you can see the destination port of the RADIUS call (1645 or 1812).&amp;nbsp; If there were a Network Access:Destination Port value we could use it for several use cases:&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;OL&gt;
&lt;LI&gt;This use case where I want different RADIUS calls from the same host and same scenario to be treated differently.&lt;/LI&gt;
&lt;LI&gt;The RADIUS callback trick for portals in ISE.&amp;nbsp; We could do callbacks on different ports to differentiate which portal is making the call and allowing different AD groups to authenticate to the portal.&lt;/LI&gt;
&lt;/OL&gt;
&lt;P&gt;The data is already there.&amp;nbsp; It doesn't seem like it would be that hard to expose that data in the conditions.&amp;nbsp;&lt;/P&gt;</description>
    <pubDate>Wed, 24 Oct 2018 12:43:22 GMT</pubDate>
    <dc:creator>paul</dc:creator>
    <dc:date>2018-10-24T12:43:22Z</dc:date>
    <item>
      <title>Double Authentication on ASA using ISE</title>
      <link>https://community.cisco.com/t5/network-access-control/double-authentication-on-asa-using-ise/m-p/3730780#M489147</link>
      <description>&lt;P&gt;Our customer uses double authentication for ASA VPN with ACS as primary authentication using AD and ISE as secondary authentication using Safenet and RSA (both in one single identity source).&lt;/P&gt;
&lt;P&gt;They now want to move both primary and secondary authentications to ISE as they are getting rid of ACS.&lt;/P&gt;
&lt;P&gt;I am reading below link&lt;/P&gt;
&lt;P&gt;&lt;A href="https://community.cisco.com/t5/identity-services-engine-ise/anyconnect-vpn-with-2-factor-authentication-on-ise/td-p/3464708" target="_blank"&gt;https://community.cisco.com/t5/identity-services-engine-ise/anyconnect-vpn-with-2-factor-authentication-on-ise/td-p/3464708&lt;/A&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Was anyone able to find any attribute to distinguish between two radius requests ?&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;We have two datacenters with 4 PSNs. The idea to send different requests to different PSNs and making check on that also sounds feasible.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;If none of the above works we will send AD authentications requests directly to AD from ASA.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Is there any other option anyone can think ? Maybe some kind of chaining&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Tue, 23 Oct 2018 14:10:33 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/double-authentication-on-asa-using-ise/m-p/3730780#M489147</guid>
      <dc:creator>umahar</dc:creator>
      <dc:date>2018-10-23T14:10:33Z</dc:date>
    </item>
    <item>
      <title>Re: Double Authentication on ASA using ISE</title>
      <link>https://community.cisco.com/t5/network-access-control/double-authentication-on-asa-using-ise/m-p/3731196#M489263</link>
      <description>&lt;P&gt;I think it simpler to send the AD auth directly from ASA. If the 2 requests are sent to different sets of PSNs, then you may use "Network Access·ISE Host Name" as a condition.&lt;/P&gt;</description>
      <pubDate>Wed, 24 Oct 2018 03:34:57 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/double-authentication-on-asa-using-ise/m-p/3731196#M489263</guid>
      <dc:creator>hslai</dc:creator>
      <dc:date>2018-10-24T03:34:57Z</dc:date>
    </item>
    <item>
      <title>Re: Double Authentication on ASA using ISE</title>
      <link>https://community.cisco.com/t5/network-access-control/double-authentication-on-asa-using-ise/m-p/3731607#M489264</link>
      <description>&lt;P&gt;Hsing,&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;This is more of a product request, but one thing that would help in cases like this is if we were able to use the DestPort field in our rule set.&amp;nbsp; If you look at the RADIUS authentication details you can see the destination port of the RADIUS call (1645 or 1812).&amp;nbsp; If there were a Network Access:Destination Port value we could use it for several use cases:&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;OL&gt;
&lt;LI&gt;This use case where I want different RADIUS calls from the same host and same scenario to be treated differently.&lt;/LI&gt;
&lt;LI&gt;The RADIUS callback trick for portals in ISE.&amp;nbsp; We could do callbacks on different ports to differentiate which portal is making the call and allowing different AD groups to authenticate to the portal.&lt;/LI&gt;
&lt;/OL&gt;
&lt;P&gt;The data is already there.&amp;nbsp; It doesn't seem like it would be that hard to expose that data in the conditions.&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Wed, 24 Oct 2018 12:43:22 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/double-authentication-on-asa-using-ise/m-p/3731607#M489264</guid>
      <dc:creator>paul</dc:creator>
      <dc:date>2018-10-24T12:43:22Z</dc:date>
    </item>
    <item>
      <title>Re: Double Authentication on ASA using ISE</title>
      <link>https://community.cisco.com/t5/network-access-control/double-authentication-on-asa-using-ise/m-p/3732764#M489265</link>
      <description>&lt;P&gt;Many thanks for your input. However, such might not be as simple. If both requests for one RA-VPN session gone into the same PSN, anything sensitive to the state of the session might mess up. If the requests gone into different PSNs, then it's unclear&amp;nbsp;which PSN is the true owner of the session, as the whole deployment shares one session directory.&lt;/P&gt;</description>
      <pubDate>Thu, 25 Oct 2018 13:50:56 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/double-authentication-on-asa-using-ise/m-p/3732764#M489265</guid>
      <dc:creator>hslai</dc:creator>
      <dc:date>2018-10-25T13:50:56Z</dc:date>
    </item>
  </channel>
</rss>

