topic Re: ISE 2.7 Incorrect Profiling Device-Sensor in Network Access Control

ISE 2.7 Incorrect Profiling Device-Sensor

ShaunGreen — Mon, 02 Nov 2020 11:57:58 GMT

Dear All,

Dot1x with certs is working, the issues are with MAB.

I have an issue where devices (Cisco Phone 7841 and other cisco devices) are being profiled as a Cisco Device and not an IP Phone and hence failing authentication.

Switch is:

WS-C2960CX-8PC-L 15.2(6)E1 C2960CX-UNIVERSALK9-M

ISE VM:

2.7.0.356

I saw from this page that device-sensor is required to send the CDP/LLDP information. I'll post the commands afterwards, but from the Debug, I don't believe this is happening.

https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/200292-Configure-Device-Sensor-for-ISE-Profilin.html

Debug should look like this:

Mar 30 05:34:58.716: RADIUS(00000000): Send Accounting-Request to 1.1.1.1:1813 id 1646/85, len 378
Mar 30 05:34:58.716: RADIUS:  authenticator 17 DA 12 8B 17 96 E2 0F - 5D 3D EC 79 3C ED 69 20
Mar 30 05:34:58.716: RADIUS:  Vendor, Cisco       [26]  40
Mar 30 05:34:58.716: RADIUS:   Cisco AVpair       [1]   34  "cdp-tlv=                        "
Mar 30 05:34:58.716: RADIUS:  Vendor, Cisco       [26]  23
Mar 30 05:34:58.716: RADIUS:   Cisco AVpair       [1]   17  "cdp-tlv=       "
Mar 30 05:34:58.721: RADIUS:  Vendor, Cisco       [26]  59
Mar 30 05:34:58.721: RADIUS:   Cisco AVpair       [1]   53  "lldp-tlv=         


With the setup we have we never see these AVpairs being sent (debug from the test environment)

000052: Nov 2 12:39:41.280 CET: RADIUS/ENCODE(00000000):Orig. component type = Invalid
000053: Nov 2 12:39:41.280 CET: RADIUS(00000000): Config NAS IP: 10.90.163.13
000054: Nov 2 12:39:41.280 CET: RADIUS(00000000): Config NAS IPv6: ::
000055: Nov 2 12:39:41.280 CET: RADIUS(00000000): sending
000056: Nov 2 12:39:41.280 CET: RADIUS: Message Authenticator encoded
000057: Nov 2 12:39:41.280 CET: RADIUS(00000000): Send Access-Request to 10.4.40.153:1812 onvrf(0) id 1645/17, len 285
000058: Nov 2 12:39:41.280 CET: RADIUS: authenticator 45 F5 72 80 93 DB 3A EF - CD 44 16 2A 0C 75 CA 72
000059: Nov 2 12:39:41.280 CET: RADIUS: User-Name [1] 25 "CP-7841-SEPC4B9CD802351"
000060: Nov 2 12:39:41.280 CET: RADIUS: Service-Type [6] 6 Framed [2]
000061: Nov 2 12:39:41.280 CET: RADIUS: Vendor, Cisco [26] 27
000062: Nov 2 12:39:41.280 CET: RADIUS: Cisco AVpair [1] 21 "service-type=Framed"
000063: Nov 2 12:39:41.283 CET: RADIUS: Framed-MTU [12] 6 1500
000064: Nov 2 12:39:41.283 CET: RADIUS: Called-Station-Id [30] 19 "00-B0-E1-67-E9-02"
000065: Nov 2 12:39:41.283 CET: RADIUS: Calling-Station-Id [31] 19 "C4-B9-CD-80-23-51"
000066: Nov 2 12:39:41.283 CET: RADIUS: EAP-Message [79] 30
000067: Nov 2 12:39:41.283 CET: RADIUS: 02 01 00 1C 01 43 50 2D 37 38 34 31 2D 53 45 50 43 34 42 39 43 [CP-7841-SEPC4B9C]
000068: Nov 2 12:39:41.283 CET: RADIUS: 44 38 30 32 33 35 31 [ D802351]
000069: Nov 2 12:39:41.283 CET: RADIUS: Message-Authenticato[80] 18
000070: Nov 2 12:39:41.283 CET: RADIUS: 23 11 8A E2 6B E3 A7 78 86 00 82 D0 AC 0E F5 27 [ #kx']
000071: Nov 2 12:39:41.283 CET: RADIUS: EAP-Key-Name [102] 2 *
000072: Nov 2 12:39:41.283 CET: RADIUS: Vendor, Cisco [26] 49
000073: Nov 2 12:39:41.283 CET: RADIUS: Cisco AVpair [1] 43 "audit-session-id=0A0110040000000E00065B84"
000074: Nov 2 12:39:41.283 CET: RADIUS: Vendor, Cisco [26] 20
000075: Nov 2 12:39:41.283 CET: RADIUS: Cisco AVpair [1] 14 "method=dot1x"
000076: Nov 2 12:39:41.283 CET: RADIUS: Framed-IP-Address [8] 6 10.4.77.15
000077: Nov 2 12:39:41.283 CET: RADIUS: NAS-IP-Address [4] 6 10.90.163.13
000078: Nov 2 12:39:41.283 CET: RADIUS: NAS-Port-Id [87] 20 "GigabitEthernet0/2"
000079: Nov 2 12:39:41.283 CET: RADIUS: NAS-Port-Type [61] 6 Ethernet [15]
000080: Nov 2 12:39:41.283 CET: RADIUS: NAS-Port [5] 6 50102
000081: Nov 2 12:39:41.283 CET: RADIUS(00000000): Sending a IPv4 Radius Packet
000082: Nov 2 12:39:41.283 CET: RADIUS(00000000): Started 5000 sec timeout
000083: Nov 2 12:39:41.290 CET: RADIUS: Received from id 1645/17 10.4.40.153:1812, Access-Reject, len 38
000084: Nov 2 12:39:41.290 CET: RADIUS: authenticator 21 E5 B0 81 22 9F F9 0C - 81 07 F0 6E A4 04 8A 9C
000085: Nov 2 12:39:41.290 CET: RADIUS: Message-Authenticato[80] 18
000086: Nov 2 12:39:41.290 CET: RADIUS: 46 65 10 2E 65 A2 9B 41 9B 3B F7 C4 12 CF 6F 96 [ Fe.eA;o]
000087: Nov 2 12:39:41.290 CET: RADIUS(00000000): Received from id 1645/17
000088: Nov 2 12:39:41.290 CET: %DOT1X-5-FAIL: Authentication failed for client (c4b9.cd80.2351) on Interface Gi0/2 AuditSessionID 0A0110040000000E00065B84
000089: Nov 2 12:39:41.294 CET: RADIUS/ENCODE(00000000):Orig. component type = Invalid
000090: Nov 2 12:39:41.294 CET: RADIUS(00000000): Config NAS IP: 10.90.163.13
000091: Nov 2 12:39:41.294 CET: RADIUS(00000000): Config NAS IPv6: ::
000092: Nov 2 12:39:41.294 CET: RADIUS(00000000): sending
000093: Nov 2 12:39:41.297 CET: RADIUS: Message Authenticator encoded
000094: Nov 2 12:39:41.297 CET: RADIUS(00000000): Send Access-Request to 10.4.40.153:1812 onvrf(0) id 1645/18, len 264
000095: Nov 2 12:39:41.297 CET: RADIUS: authenticator F4 EE 04 C7 C7 A1 85 20 - 60 A6 90 F1 B5 30 35 BB
000096: Nov 2 12:39:41.297 CET: RADIUS: User-Name [1] 14 "c4b9cd802351"
000097: Nov 2 12:39:41.297 CET: RADIUS: User-Password [2] 18 *
000098: Nov 2 12:39:41.297 CET: RADIUS: Service-Type [6] 6 Call Check [10]
000099: Nov 2 12:39:41.297 CET: RADIUS: Vendor, Cisco [26] 31
000100: Nov 2 12:39:41.297 CET: RADIUS: Cisco AVpair [1] 25 "service-type=Call Check"
000101: Nov 2 12:39:41.297 CET: RADIUS: Framed-MTU [12] 6 1500
000102: Nov 2 12:39:41.297 CET: RADIUS: Called-Station-Id [30] 19 "00-B0-E1-67-E9-02"
000103: Nov 2 12:39:41.297 CET: RADIUS: Calling-Station-Id [31] 19 "C4-B9-CD-80-23-51"
000104: Nov 2 12:39:41.297 CET: RADIUS: Message-Authenticato[80] 18
000105: Nov 2 12:39:41.297 CET: RADIUS: 62 23 1C 73 3E D7 84 30 D0 65 3C 98 A0 74 49 31 [ b#s>0e<tI1]
000106: Nov 2 12:39:41.297 CET: RADIUS: EAP-Key-Name [102] 2 *
000107: Nov 2 12:39:41.297 CET: RADIUS: Vendor, Cisco [26] 49
000108: Nov 2 12:39:41.297 CET: RADIUS: Cisco AVpair [1] 43 "audit-session-id=0A0110040000000E00065B84"
000109: Nov 2 12:39:41.297 CET: RADIUS: Vendor, Cisco [26] 18
000110: Nov 2 12:39:41.297 CET: RADIUS: Cisco AVpair [1] 12 "method=mab"
000111: Nov 2 12:39:41.297 CET: RADIUS: Framed-IP-Address [8] 6 10.4.77.15
000112: Nov 2 12:39:41.297 CET: RADIUS: NAS-IP-Address [4] 6 10.90.163.13
000113: Nov 2 12:39:41.297 CET: RADIUS: NAS-Port-Id [87] 20 "GigabitEthernet0/2"
000114: Nov 2 12:39:41.297 CET: RADIUS: NAS-Port-Type [61] 6 Ethernet [15]
000115: Nov 2 12:39:41.297 CET: RADIUS: NAS-Port [5] 6 50102
000116: Nov 2 12:39:41.297 CET: RADIUS(00000000): Sending a IPv4 Radius Packet
000117: Nov 2 12:39:41.297 CET: RADIUS(00000000): Started 5000 sec timeout
000118: Nov 2 12:39:41.304 CET: RADIUS: Received from id 1645/18 10.4.40.153:1812, Access-Reject, len 38
000119: Nov 2 12:39:41.308 CET: RADIUS: authenticator C8 B1 6B 40 4A 08 EE D3 - CD E8 5B 91 AE C0 8E 66
000120: Nov 2 12:39:41.308 CET: RADIUS: Message-Authenticato[80] 18
000121: Nov 2 12:39:41.308 CET: RADIUS: 2D 38 17 9E D1 05 51 27 54 54 48 ED B1 01 94 AD [ -8Q'TTH]
000122: Nov 2 12:39:41.308 CET: RADIUS(00000000): Received from id 1645/18
000123: Nov 2 12:39:41.308 CET: %MAB-5-FAIL: Authentication failed for client (c4b9.cd80.2351) on Interface Gi0/2 AuditSessionID 0A0110040000000E00065B84

#sho access-session int g0/2 det
Interface: GigabitEthernet0/2
MAC Address: c4b9.cd80.2351
IPv6 Address: Unknown
IPv4 Address: 10.4.77.15
User-Name: c4b9cd802351
Status: Unauthorized
Domain: UNKNOWN
Oper host mode: multi-domain
Oper control dir: in
Session timeout: N/A
Restart timeout: N/A
Periodic Acct timeout: N/A
Session Uptime: 20s
Common Session ID: 0A0110040000000E00065B84
Acct Session ID: Unknown
Handle: 0x8C000003
Current Policy: PORT-AUTH-POLICY

Method status list:
Method State

dot1x Stopped
mab Authc Failed

I thought this might be the issue, but I changed the IOS to one which said it was okay (another post on the community), but still the same issue:

RADIUS/ENCODE(00000000):Orig. component type = Invalid

This is the device-sensor configuration and radius:

device-sensor filter-list dhcp list DHCP-LIST
option name host-name
option name requested-address
option name parameter-request-list
option name class-identifier
option name client-identifier
!
device-sensor filter-list lldp list LLDP-LIST
tlv name system-name
tlv name system-description
tlv name system-capabilities
!
device-sensor filter-list cdp list CDP-LIST
tlv name device-name
tlv name address-type
tlv name capabilities-type
tlv name version-type
tlv name platform-type
device-sensor filter-spec dhcp include list DHCP-LIST
device-sensor filter-spec lldp include list LLDP-LIST
device-sensor filter-spec cdp include list CDP-LIST
device-sensor notify all-changes

radius-server attribute 6 on-for-login-auth
radius-server attribute 8 include-in-access-req
radius-server attribute 25 access-request include
radius-server attribute 31 mac format ietf upper-case
radius-server attribute 31 send nas-port-detail mac-only
radius-server dead-criteria time 20 tries 3
radius-server deadtime 15

One thing I've noticed is the documents state the following command is required and my gut feeling tells me this is why the CDP information is not being sent to the ISE:

device-sensor accounting

But all of the versions I've tried, there isn't the option to configure this command, not is on by default.

From the switch:

#sho device-sensor details

Device-Sensor Details
--------------------------------------

Status = Enabled

Protocols:
-----------
CDP registered
LLDP registered
DHCP registered
HTTP registered

Protocol Filter Configuration:
---------------------------------
CDP Include List - CDP-LIST
LLDP Include List - LLDP-LIST
DHCP Include List - DHCP-LIST
HTTP None

Device: c4b9.cd80.2351 on port GigabitEthernet0/2
--------------------------------------------------
Proto Type:Name Len Value
LLDP 7:system-capabilities 6 0E 04 00 24 00 24
LLDP 6:system-description 50 0C 30 43 69 73 63 6F 20 49 50 20 50 68 6F 6E 65
20 37 38 34 31 2C 20 56 31 2C 20 73 69 70 37 38
78 78 2E 31 31 2D 35 2D 31 2D 31 38 2E 6C 6F 61
64 73
LLDP 5:system-name 17 0A 0F 53 45 50 43 34 42 39 43 44 38 30 32 33 35
31
CDP 28:secondport-status-type 7 00 1C 00 07 00 02 00
CDP 6:platform-type 23 00 06 00 17 43 69 73 63 6F 20 49 50 20 50 68 6F
6E 65 20 37 38 34 31
CDP 5:version-type 27 00 05 00 1B 73 69 70 37 38 78 78 2E 31 31 2D 35
2D 31 2D 31 38 2E 6C 6F 61 64 73
CDP 4:capabilities-type 8 00 04 00 08 00 00 04 90
CDP 2:address-type 17 00 02 00 11 00 00 00 01 01 01 CC 00 04 0A 04 4D
0F
CDP 1:device-name 19 00 01 00 13 53 45 50 43 34 42 39 43 44 38 30 32
33 35 31

Does anyone have any other ideas or experience of MAB with 2960CX's?

I've tried various SW's, but keep hitting the same thing. I think the problem is because the CDP information isn't being sent to the ISE, but I don't know how I can configure this to happen.

Thanks,
Simon

Re: ISE 2.7 Incorrect Profiling Device-Sensor

Mike.Cifelli — Mon, 02 Nov 2020 15:06:31 GMT

Have you considered not using the default out-of-box profiles? Essentially you could identify attributes that you could target to create a new profile to profile the devices that have a higher MCF. You would then reference the profiled group in your authz policy. Note that at this point you would require plus licensing in a 1-1 ratio. This would/could help with your issue. TBH when I rely on profiling I typically build out custom profiles. HTH!

Re: ISE 2.7 Incorrect Profiling Device-Sensor

poongarg — Mon, 02 Nov 2020 15:51:02 GMT

Hi Simon,

I would suggest you to take a packet capture on the ISE server receiving the authentication request to verify if the RADIUS AV Pairs are received by ISE in the RADIUS accounting packet or not.

Re: ISE 2.7 Incorrect Profiling Device-Sensor

ShaunGreen — Tue, 03 Nov 2020 12:16:58 GMT

Hi Guys,

Thanks for your assistance, appreciate it.

So, we have another ISE installation where we believe the profiling is working correctly, but to be honest, now I'm diving deeper, I'm not sure 'how' it's working correctly.

I have a ATA converter that I can test using MAB.
We actually have an administered created Profiled Policy to match these devices.

My first question would be, is there a way to see which conditions matched to reach the minimum certainty factor?

I'll be honest, this has stumped me a little. I carried out a Debug on the switch and packet capture on the ISE.

I can see the radius accounting, but I don't see anything regarding CDP.
For instance we match 4 conditions with a minimum certainty of 40. But one of those conditions which is a MAC address contain rule.

But even though the ATA is profililed as an ATA, it doesn't match the condition that matches part of a MAC address, so even if the other 3 conditions are met, we only have a total of 30....but the minimum certainty is 40....so I'm really wondering how the profiling is working??

Regarding the capture, I don't see anything obvious which is forwarding the CDP information, but again, this is another expression that we are trying to match.

It would be really useful if I could actually see what expressions are matched to profile this device as an ATA. Once I can understand that, it should help me to understand where the other profiled sessions on the other ISE setup are going wrong.

I hope that all makes sense?

According to the documentation I should be seeing the following:

But from the capture I ran, this is all I see...and this is actually on a system that I 'believe' is profiling correctly??

Re: ISE 2.7 Incorrect Profiling Device-Sensor

martin.fischer — Thu, 05 Nov 2020 10:31:48 GMT

Hi @ShaunGreen

Keep in mind that the device sensor data is sent only if the MAC address successfully authenticated. The device sensor data is carried in the RADIUS accounting packets and there is no RADIUS accounting for MAC addresses which failed authentication. As far as I know there is no option to carry the information in the RADIUS authentication packet. Therefore, you need to allow some kind of temporary access to get the device sensor data. E.g. RADIUS Access-Accept with an DACL which only allows DHCP and DNS. Also make sure, that your global and/or profile specific configuration triggers a CoA after the profile change, so that device gets the appropriate access after profiling.

Re: ISE 2.7 Incorrect Profiling Device-Sensor

ShaunGreen — Thu, 05 Nov 2020 12:15:55 GMT

@martin.fischer Thanks for the information.

According to the documentation:

Until the client is authenticated, 802.1x access control allows only Extensible Authentication Protocol over LAN (EAPOL), Cisco Discovery Protocol (CDP), and Spanning Tree Protocol (STP) traffic through the port to which the client is connected. After authentication is successful, normal traffic can pass through the port.

I've created a Profile Policy to match the CDP:

And then call on the logical profile in the Policy set:

But because the ISE never receives the CDP information, it just ends up seeing it as a Cisco-Device and ending up in the Default

I could try creating an exception rule, but that does seem the right way to go.

I'm now testing with a 2960x 15.2(7) E3.

Re: ISE 2.7 Incorrect Profiling Device-Sensor

martin.fischer — Thu, 05 Nov 2020 12:43:17 GMT

Yes, CDP is allowed before authentication but its informations are not transported by the device sensor via RADIUS accounting as long as the session is not authenticated. Alternatively, you can enable and configure the SNMP profiler as it is capable to read the CDP MIB of the switch.

Re: ISE 2.7 Incorrect Profiling Device-Sensor

ShaunGreen — Thu, 05 Nov 2020 14:10:51 GMT

Hi Martin,

From this doc:

https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/200292-Configure-Device-Sensor-for-ISE-Profilin.html

I assume the bold command below was responsible for sending the CDP/LLDP information:

device-sensor filter-list cdp list cdp-list
 tlv name device-name
 tlv name platform-type
!
device-sensor filter-list lldp list lldp-list
 tlv name system-description
!
device-sensor filter-spec lldp include list lldp-list
device-sensor filter-spec cdp include list cdp-list
!
device-sensor accounting
device-sensor notify all-changes

But from all of the version of IOS I've used, that command is not available.

Looking through the document, things seem straight forward, but unfortunately that's not been the case.

I've configured things with SNMP and it's looking much better. I delete the device from ISE profile with the port shut down, Bring up the port and it profiles correctly.
Thanks for your help!

Re: ISE 2.7 Incorrect Profiling Device-Sensor

howon — Wed, 20 Jan 2021 22:21:34 GMT

Use following:

SWITCH(config)#access-session attributes filter-list list DS
SWITCH(config-com-filter-list)#cdp 
SWITCH(config-com-filter-list)#lldp
SWITCH(config-com-filter-list)#dhcp
SWITCH(config-com-filter-list)#http
SWITCH(config-com-filter-list)#exit
SWITCH(config)#
SWITCH(config)#access-session accounting attributes filter-spec include list DS
SWITCH(config)#