03-17-2022 09:42 AM - edited 03-17-2022 09:43 AM
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 .
Solved! Go to Solution.
03-17-2022 07:45 PM
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.
03-23-2022 03:44 PM
@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
03-17-2022 10:30 AM - edited 03-17-2022 10:31 AM
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 !!!
03-17-2022 10:55 AM
@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
03-23-2022 04:50 AM - edited 03-23-2022 04:52 AM
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
03-23-2022 05:06 AM
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.
03-23-2022 03:44 PM
@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
03-17-2022 07:45 PM
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.
03-23-2022 04:46 AM
Thanks @Marcelo Morais is a great information , so thanks
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide