ISE HP-Device profiling rules

[ben.posner]

trying to understand how this default ISE profiling policy works:

the first two rules i can find in the profiler conditions list, the last one i cannot.

is this an error? this is ISE 2.3 patch 7. i have several hp-printers that are being profiled as only hp-device. and the snmp scan never gets kicked off because i think this rule is broken.

[howon · Accepted solution]

If you hover your mouse near '+' the last rule you should see the actual content of the condition popup. It should be identical to the HP-DeviceRule2Check1. The policy will not only increase CF by 10, but also will kick off an NMAP scan. If the endpoint is matching the HP-Device profile but not being scanned, I suggest making sure:

1. NMAP profiler is enabled

2. Do a manual NMAP scan to confirm it can be scanned manually

3. If NMAP works manually but does not triggered with profiler policy then may need to contact TAC. However, if manual scan does not work, then there maybe filtering device between ISE and the client subnet.

[ben.posner]

not sure who marked this as an accepted answer because its not accepted by me!

well it may be too late, i already modified the rule to try to create what i believe is the missing scan condition. don't know if there's a reset to default in the profiler policy list or not.

i do have NMAP scan enabled.

i have run a manual NMAP scan.

my test device shows that it was profiled based on SNMP but is still an HP-Device and not something more specific, and there is a matching policy type for the type of printer.

[ben.posner]

tested on my lab running 2.4patch10 and it profiles just fine. 

cleared the endpoint from the lab, plugged it into my lab switch and it profiled exactly like it should.

did the same for the production system. device never gets profiled past HP-Device...

i even exported the HP-Device profiler rule from the lab and re-imported it into the production 2.3 system and i get the same result.

the printer is using public/private snmp keys and both LAB and PRODUCTION ISE are configured to use those keys for SNMP probes initiated by nmap.

[howon]

The SNMPQueryProbe is not related to NMAP. SNMPQueryProbe is where ISE does SNMP read to a network device such as a access switch and grabs CDP and/or LLDP information from the interface or to get ARP table. It probably learned the MAC OUI from the SNMPQueryProbe. I am still suggesting looking into any FW or filtering device between ISE and the client subnet that may impact NMAP scan function if it is working in test environment while not in production.

[ben.posner]

the lab and the local production ISE nodes are one L3 hop away from the printer and are on the same network as the switch management address. no ACLs. are preventing scanning or access to them.

my lab has NONE of the SNMP traps or queries enabled for profiling. it is using RADIUS, NMAP, HTTP and DNS. the snmp probing for profiling is user disabled. 

The printer connected to the lab switch and was profiled properly and below is the the results shown in the profiler report. it shows SNMPQuery Probe as the endpoint static assignment reason. so NMAP and SNMP are related to one another in some way. i believe this is explained in the following document and section: https://community.cisco.com/t5/security-documents/ise-profiling-design-guide/ta-p/3739456#toc-hId-1651437215

Regardless of whether NMAP and SNMP are related, it still working on one setup and not on the other. there are no firewalls or ACLs blocking access to the printer or the NAD from either ISE deployments. i wish ISE has better reporting on what exactly it does during the profiling process to help us administrators see where it is falling down. i guess i will open a case.