cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.

862
Views
20
Helpful
7
Replies
athan1234
Beginner

Gather devices information on Ise

How I can gather information from the endpoints on a company?

The idea is to collect information on ise without disturbing my client, without cut of theirs computers ,  only  I need to collect information from  the endpoints. maybe only mac oui is enough.

For this way I am able to gather information and be able to detect a strange device for then to do   a good profailing  and for leater  to implementing 8021.x better .So  I avoid to get strange device "unknow " they would not get acces to the networking it is a problem always  .
I have configured on switch basic radius comand information , and on ise the switch for he speaks with the ise but when I  try to see the device of this center  I can not see anything .

 

 
 
2 ACCEPTED SOLUTIONS

Accepted Solutions
Arne Bier
VIP Advisor

I am always weary of "collecting information" from the network in preparation for closed-mode, because the collection phase is just a snapshot in time of what devices you had AT THAT TIME. Chances are that after going into closed-mode, you'll start adding new devices, or RMA an old endpoint client and replace with new etc. That means you need to somehow bootstrap the new devices to be profiled by ISE.

 

With 802.1X profiling is not an option because the first time that device talks to ISE (even if the supplicant is correct) you will only get the MAC address in the initial access request. 802.1X is layer 2. There is no DHCP and no NMAP possible in the initial communications between the client and ISE. Hence, if your Policy Set is so strict that access is granted only if the client also matches a certain profiling criterion, e.g. IF Authentication Success AND (Windows_Workstation or MACOSX), then this new client will never connect (because ISE has not yet had a chance to profile it). Classic chicken and egg scenario.

 

I think the only pragmatic, and automated solution to this is to allow the 802.1X devices to fail into a profiling VLAN to allow ISE to profile the device after a successful 802.1X auth. The VLAN should allow DHCP only, and ISE should be configured to accept DHCP/CDP/LLDP/HTTP profiling data from the switch.  Once ISE has learned something new, then it will re-auth the device (CoA Reauthentication), and then the client should hopefully match the Authorization logic to give the device the appropriate VLAN/ACL/SGT etc.

View solution in original post

@athan1234  - device sensor will require you to enabled MAB or 802.1X on ports to create the RADIUS Accounting updates to ISE - since device sensor data is transported in RADIUS Accounting messages. And Accounting is only done once the switch has a session for an interface.

 

other option could be to not use device sensor, if you only want ISE to learn DHCP data. In that case enable DHCP probe on your PSNs, and then add the PSN IP addresses to your ip helper statements. Very useful for non-Cisco networks.

 

One other thing - you can also use ISE SNMP probe to collect endpoint data (MAC address only) from your switches.

 

DHCP probes and SNMP probes don't require any NAC to be configured on a switch. You could consider this a "discovery" phase

 

View solution in original post

7 REPLIES 7
Marcelo Morais
VIP Advisor

Hi @athan1234 ,

 802.1X deployment has the following Phases:
1st Monitor Mode
 The Endpoint is granted access to the network regardless of whether they pass or fail their Authentication Request. The important thing is that you only return a basic RADIUS Access Accept or RADIUS Access Reject from ISE to the Authenticator (Access SW)

2nd Low-Impact Mode
Works similar to Monitor Mode, but as opposed to allow ALL IP traffic, we will typically limit this to a subset of access such as DHCP, PXE Boot, etc.

3rd Close Mode
Traffic will not be allowed to pass prior to a successful Authentication/Authorization.

 

Note: the Monitor Mode is what you are looking for ... please take a look at Access Control on the Wired Network.

 

Hope this helps !!!

Rob Ingram
VIP Expert

@athan1234 use monitor mode so you don't impact the users sessions as already indicated.

 

You probably want more than the MAC OUI, use device sensor on the switches to gather DHCP, CDP and LLDP information and send to ISE via RADIUS. Potentially look to use NMAP to gather further information. With this information ISE will know exactly what type of device (make/model) is connected to the network.

 

Refer to the ISE profiling guide

https://community.cisco.com/t5/security-documents/ise-profiling-design-guide/ta-p/3739456

 

Hi @Rob Ingram  thanks for your reply

 

Yes I was seeing about device sensor but  If  I Use and configure  device sensor  on the switch , is enough ? I will have to configure 8021.x on the switch ports  .

so thanks

 

Hi @athan1234 yes, I find usually that device sensor sending DHCP, CDP and LLDP information is enough.

 

Check the ISE profile policies for the types of devices on your network, determine what information ISE needs to profile those devices correctly.

@athan1234  - device sensor will require you to enabled MAB or 802.1X on ports to create the RADIUS Accounting updates to ISE - since device sensor data is transported in RADIUS Accounting messages. And Accounting is only done once the switch has a session for an interface.

 

other option could be to not use device sensor, if you only want ISE to learn DHCP data. In that case enable DHCP probe on your PSNs, and then add the PSN IP addresses to your ip helper statements. Very useful for non-Cisco networks.

 

One other thing - you can also use ISE SNMP probe to collect endpoint data (MAC address only) from your switches.

 

DHCP probes and SNMP probes don't require any NAC to be configured on a switch. You could consider this a "discovery" phase

 

Arne Bier
VIP Advisor

I am always weary of "collecting information" from the network in preparation for closed-mode, because the collection phase is just a snapshot in time of what devices you had AT THAT TIME. Chances are that after going into closed-mode, you'll start adding new devices, or RMA an old endpoint client and replace with new etc. That means you need to somehow bootstrap the new devices to be profiled by ISE.

 

With 802.1X profiling is not an option because the first time that device talks to ISE (even if the supplicant is correct) you will only get the MAC address in the initial access request. 802.1X is layer 2. There is no DHCP and no NMAP possible in the initial communications between the client and ISE. Hence, if your Policy Set is so strict that access is granted only if the client also matches a certain profiling criterion, e.g. IF Authentication Success AND (Windows_Workstation or MACOSX), then this new client will never connect (because ISE has not yet had a chance to profile it). Classic chicken and egg scenario.

 

I think the only pragmatic, and automated solution to this is to allow the 802.1X devices to fail into a profiling VLAN to allow ISE to profile the device after a successful 802.1X auth. The VLAN should allow DHCP only, and ISE should be configured to accept DHCP/CDP/LLDP/HTTP profiling data from the switch.  Once ISE has learned something new, then it will re-auth the device (CoA Reauthentication), and then the client should hopefully match the Authorization logic to give the device the appropriate VLAN/ACL/SGT etc.

athan1234
Beginner

Thanks   @Marcelo Morais  is a great information ,  so thanks

Create
Recognize Your Peers
Content for Community-Ad

ISE Webinars


Miss a previous ISE webinar?
Never miss one again!

CiscoISE on YouTube