<?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 Hello Andy- in Network Access Control</title>
    <link>https://community.cisco.com/t5/network-access-control/re-validating-previously-profiled-ise-endpoints/m-p/2954793#M37909</link>
    <description>&lt;P&gt;Hello Andy-&lt;/P&gt;
&lt;P&gt;What you are experiencing is correct and expected behavior with the current mechanics of ISE. There is an enhancement request that was put in place a while back but it hasn't seen much traction:&lt;/P&gt;
&lt;P&gt;&lt;A href="https://bst.cloudapps.cisco.com/bugsearch/bug/CSCur48184"&gt;https://bst.cloudapps.cisco.com/bugsearch/bug/CSCur48184&lt;/A&gt;&lt;/P&gt;
&lt;P&gt;The only time a device would move from one profile group to another is when a profiling rule with higher Certainty Factor is hit. For instance, if you create a custom rule with CF of 100 and if that rule is hit then a profiled device will never move to another rule that has CF that is &amp;lt;= to 100.&amp;nbsp;&lt;/P&gt;
&lt;P&gt;As you can tell, profiling is not bullet-proof. This is why it is best practice to limit the network access for profiled devices. For instance, IP Phones should only need access to the voice subnets and the PBX, Printers should only need access to print servers on specific ports, etc&lt;/P&gt;
&lt;P&gt;I hope this helps!&lt;/P&gt;
&lt;P&gt;&lt;EM&gt;Thank you for rating helpful posts!&lt;/EM&gt;&lt;/P&gt;</description>
    <pubDate>Fri, 21 Oct 2016 02:09:24 GMT</pubDate>
    <dc:creator>nspasov</dc:creator>
    <dc:date>2016-10-21T02:09:24Z</dc:date>
    <item>
      <title>re-validating previously profiled ISE endpoints</title>
      <link>https://community.cisco.com/t5/network-access-control/re-validating-previously-profiled-ise-endpoints/m-p/2954792#M37907</link>
      <description>&lt;P&gt;Hello&lt;/P&gt;
&lt;P&gt;I was having a look at MAC spoofing with ISE 2.1.0.474&lt;/P&gt;
&lt;P&gt;I am using RADIUS/SNMP trap and query and DHCP probes. A Cisco 7911 phone correctly gets profiled as "Cisco-IP-Phone-7911". The endpoint in ISE shows all the correct cdp/lldp/dhcp details&lt;/P&gt;
&lt;P&gt;When I connect my windows laptop (spoofing the phones MAC), the laptop is authenticated as the phone. The endpoint is still profiled as "Cisco-IP-Phone-7911" - the endpoint shows the correct dhcp details for the laptop but retains the cdp/lldp details of the phone previously profiled. I checked the NAD and the device-sensor cache has no cdp/lldp details for the connected laptop and device-sensor accounting sends only the laptop dhcp tlv's to ISE.&lt;/P&gt;
&lt;P&gt;If I delete the endpoint from ISE and connect my laptop (again spoofing the phones MAC), ISE correctly profiles the laptop as "Microsoft-Workstation"&lt;/P&gt;
&lt;P&gt;When I disconnect the laptop and reconnect the phone, ISE re-profiles the endpoint as a "Cisco-IP-Phone-7911" based on the newly learnt cdp/lldp info.&lt;/P&gt;
&lt;P&gt;ISE can learn new endpoint details through the probes and re-profile an endpoint as shown above. Am I right in saying that ISE won't re-profile an endpoint based on the fact that some attributes (e.g. cdp/lldp) have stopped appearing - only when new attributes are learnt?&lt;/P&gt;
&lt;P&gt;Thanks&lt;BR /&gt;Andy&lt;/P&gt;</description>
      <pubDate>Mon, 11 Mar 2019 07:09:48 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/re-validating-previously-profiled-ise-endpoints/m-p/2954792#M37907</guid>
      <dc:creator>andrewswanson</dc:creator>
      <dc:date>2019-03-11T07:09:48Z</dc:date>
    </item>
    <item>
      <title>Hello Andy-</title>
      <link>https://community.cisco.com/t5/network-access-control/re-validating-previously-profiled-ise-endpoints/m-p/2954793#M37909</link>
      <description>&lt;P&gt;Hello Andy-&lt;/P&gt;
&lt;P&gt;What you are experiencing is correct and expected behavior with the current mechanics of ISE. There is an enhancement request that was put in place a while back but it hasn't seen much traction:&lt;/P&gt;
&lt;P&gt;&lt;A href="https://bst.cloudapps.cisco.com/bugsearch/bug/CSCur48184"&gt;https://bst.cloudapps.cisco.com/bugsearch/bug/CSCur48184&lt;/A&gt;&lt;/P&gt;
&lt;P&gt;The only time a device would move from one profile group to another is when a profiling rule with higher Certainty Factor is hit. For instance, if you create a custom rule with CF of 100 and if that rule is hit then a profiled device will never move to another rule that has CF that is &amp;lt;= to 100.&amp;nbsp;&lt;/P&gt;
&lt;P&gt;As you can tell, profiling is not bullet-proof. This is why it is best practice to limit the network access for profiled devices. For instance, IP Phones should only need access to the voice subnets and the PBX, Printers should only need access to print servers on specific ports, etc&lt;/P&gt;
&lt;P&gt;I hope this helps!&lt;/P&gt;
&lt;P&gt;&lt;EM&gt;Thank you for rating helpful posts!&lt;/EM&gt;&lt;/P&gt;</description>
      <pubDate>Fri, 21 Oct 2016 02:09:24 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/re-validating-previously-profiled-ise-endpoints/m-p/2954793#M37909</guid>
      <dc:creator>nspasov</dc:creator>
      <dc:date>2016-10-21T02:09:24Z</dc:date>
    </item>
    <item>
      <title>Thanks Neno - I'll contact</title>
      <link>https://community.cisco.com/t5/network-access-control/re-validating-previously-profiled-ise-endpoints/m-p/2954794#M37910</link>
      <description>&lt;P&gt;Thanks Neno - I'll contact TAC and add some weight to the enhancement request. Once we are out of Monitor mode the key thing will be strict authorization for ISE profiled devices.&lt;/P&gt;
&lt;P&gt;&lt;/P&gt;
&lt;P&gt;Cheers&lt;/P&gt;
&lt;P&gt;Andy&lt;/P&gt;</description>
      <pubDate>Fri, 21 Oct 2016 06:12:55 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/re-validating-previously-profiled-ise-endpoints/m-p/2954794#M37910</guid>
      <dc:creator>andrewswanson</dc:creator>
      <dc:date>2016-10-21T06:12:55Z</dc:date>
    </item>
    <item>
      <title>Great! Thanks Andy! Let us</title>
      <link>https://community.cisco.com/t5/network-access-control/re-validating-previously-profiled-ise-endpoints/m-p/2954795#M37911</link>
      <description>&lt;P&gt;Great! Thanks Andy! Let us know what Cisco/TAC has to say about it &lt;span class="lia-unicode-emoji" title=":slightly_smiling_face:"&gt;🙂&lt;/span&gt;&lt;/P&gt;
&lt;P&gt;Neno&lt;/P&gt;</description>
      <pubDate>Fri, 21 Oct 2016 18:01:10 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/re-validating-previously-profiled-ise-endpoints/m-p/2954795#M37911</guid>
      <dc:creator>nspasov</dc:creator>
      <dc:date>2016-10-21T18:01:10Z</dc:date>
    </item>
  </channel>
</rss>

