I’ve received a handful of support cases from engineers and customers around Cisco Identity Services Engine ISE Profiling. Questions range from “why are my devices showing up as UNKNOWN” to “How does ISE Profiling work?” Here is a breakdown of how ISE Profiling works for version 1.0.
NOTE: There are some VERY cool things coming from Cisco in the near future on this topic so stay tuned.
Cisco ISE Profiling is an advance subscription license feature used to identify what endpoints are based on network data obtained from a number of enabled probes. Use cases range from managing access rights for devices that don’t authenticate (IE Printers, Card Readers, etc.) to developing policies around device types (IE handling iPads differently from Laptops). Accuracy about device types increases as more probes are enabled. Cisco ISE probe options are NetFlow, DHCP, DHCP SPAN, HTTP, Radius, DNS and a few SNMP TRAP/Query options. Probes view network traffic seen by designated sensors (IE a ISE enabled switch). If you quickly plug and unplug a laptop into a switch, most likely ISE Profiling will only see the SNMP link up trap and know very little about the device. If the device is plugged in and attempts to access the Web, ISE Profiling will see more data and be able to make a more accurate determination of the device’s identity.
Cisco ISE profiling has categories for devices obtained from the cloud or through customization. Each category has specific “weights” assigned that are measured against the device data. As Cisco ISE profiling captures data, different specifications trigger categories as assign weight values are met. For example, a iPad will move from UNKNOWN to APPLE DEVICE based on MAC, network card manufacture type and other info. As more data is collected about the iPad, Cisco ISE profiling will use other attributes to match it from APPLE DEVICE to iPad. Custom categories can be created from UNKNOWN or existing profiles however the majority of device profiles are obtained through the cloud. Profiling is continuous meaning if a device is spoofed, its behavior will give away it’s true identity to provide continuous monitoring of device types on your network.
NOTE: If certain probes or data is not available, you may need to tune a category’s weight. I had a customer who did not use DHCP on their network, which is weighted very high for the AVAYA PHONE category. I had to adjust DHCP to a lower weight in the default AVAYA category before all phones were profiled properly.
Some common issues I have seen in the field are:
1) Profiling is not working:
- Check to see ISE Profiling Services is enabled under General Settings
- Verify which probes are enabled under the Probe Config Tab
- Verify the switch you are testing is supporting the probe. For example, if you use SNMP RO, you need to have the switch use the SNMP-SERVER commands to send data to Cisco ISE Profiling. The switch also needs to be managed by ISE via network devices tab.
- You may need an ip helper address of the ISE device when using the DHCP probe so ISE sees the data.
2) Devices remain as UNKNOWN
- Verify which catalog/profile you are attempting to hit. Click the UNKNOWN device and review the characteristics. Make sure the probes that are enabled are used by the category you are looking to achieve. See AVAYA PHONE example above. You may need to adjust category weights if specific data is not used or not seen by ISE.
- Click the UNKNOWN device and verify which probes are actually working. ISE Profiling will show what it knows. Go to the monitoring section and click the device details. ISE shows the communication in detail.
- Make sure you have updated your ISE system. If you haven’t updated ISE, it won’t have any categories. There are Air-gap steps for customers who don’t want ISE to touch the internet.
3) Devices remain in a generic category.
- This problem is similar to remaining UNKNOWN. Verify the desired category weight attributes and match it to what ISE is seeing for the device under monitoring. You may either have to tune weights or not have enough data due to lack of probe information. Options are enable more probes or use MAC address based (MAB) authentication to recognize devices.
Hope this helps with your Cisco ISE Profiling adventures.
Related posts:
Are you 802.1x ready? What it takes to enable 802.1x using Cisco ISE
Cisco Identity Services Engine ISE 1.1 Profiling – Identify And Monitor What Is On Your Network
Cisco Identity Services Engine ISE 1.1.1 (Maintenance Release) ISE 1.1MR Out Now – Update Reviewed
Cisco Identity Services Engine ISE 1.0.4 Released
Hi,
I have a problem with devices hitting ISE for the first time ( I have deny authorization by the end if none of the rules match)
They get denied and they stay denied until I manually reconnect and once they are profiled everything is ok for the rest of their lifes 😛
here is a screenshot
https://dl.dropbox.com/u/75261564/Selection_019.png
Hi Ed,
There are a few things you can do to resolve this. Basically the goal is to do something with UNKNOWN systems and/or provide a way to give profiler enough info or time to figure out what the device is. This also depends on how you build the policy checks meaning you could do a combination of USER in AD with Device Time = certain access. You could also just look at people and hidden certificates on devices to verify the device is a company owned assest used by a trusted user. You could go under MAB auth policy, click action and change change REJECT to continue then have a webauth policy for anything that isn’t meeting your 802.1x and MAB policies. You could build a policy for UNKNOWN devices and give them very limited access that can give profiler additional time to profile it. Make sure to have the COA set so the device can be moved once its profiled (my guess is you have this set to deny rather than re-auth). Other suggestions would be to focus on your profiling settings. Its possible you could use other means to speed up the profile depending on how you are identifying the systems. For example, you may be seeing the layer 2 information however waiting for DHCP before having enough weight to change from the UNKNOWN state. You could adjust the weights of other values that you capture quicker to help move devices from UNKOWN to WORKSTATION. You could use checks higher in the stack such as DHCP for moving WORKSTATIONS to WINDOWS7 devices.
Hope this helps.
Hi!
Sorry for my Bad english, but i am from Germany and was looking for ISE Infos…
The Question in use with ISE for me is how the Profiling ist working?
Take a Look:
With the Profiling a Brother MFC Device was indentfied correctly in the Network.
The Unified Indentfier is the MAC as i know from the CISCO Referenz.
Ok what we got is a Endpoint that Authenticatet per MAC and Profile values.
At this Time we are Not use dvlan or dacl.
Ok now Take a pc and Fake the Mac of the Brother device and we will geht Access…
I think beacause the Endpoint with the Mac is Not profield again with all values!
I Hope you know what i want to say…
We tried it with Open and without Open Mode!
Daniel
Hi Daniel,
Let me see if I understand. You have a device that works. A similar device is not. You are using Profiling and MAB (MAC Address) rather than 802.1x and profiling. You do not have any authorization policies setup to enforce Dynamic ACLs or VLANs. You are cloning a MAC address of a working device and it gets you access. So what is your goal? To test profiling so if a MAC address is cloned, the device will be profiled different and denied?
There are a few things to understand. ISE works based on a few steps. The first is authentication meaning how are people connecting. Are they using 80.2x, MAB or Guest access? Are they using wireless, LAN and VPN? The next step is authorization meaning what do you do once they connect. Do you put them in a VLAN? Do you apply an ACL? Profiling works during these steps by monitoring the behavior of the device. You can create authorization policies based on a combination of a profiled category and how somebody authenticated (IE using AD, MAB, etc).
So let me know what you are trying to accomplish. If you are looking to test profiling to distinguish one device from another similar device, thats not its purpose. Profiling will tell you both devices are the same type however the authentication means will determine how they should be treated (example is two employees one similar laptops may get different access because one is a ADMIN and other is a general user). Usually profiler is key when somebody spoofs a MAC of a authorized device such as a printer and tries to get full access hiding as a printer. Profiler will see the printer acting like a user and flag it as a user even though the MAC looks like a printer.
Hope this helps
Joey
I think about what i wrote yesterday and i think i wrote it Not very well…
My Company want to go away from Port-Security on cisco switches (2960-s) and we buy ISE 1.1.1 with Advanced licence.
We only use wired endpoints at this Time.
The endpoints that Support dot1x are ok and no Problem.
The endpoints that Support only MAB are the Thing that i want to Secure. That are only endpoints Where no webauth are some other logins are possible.
Most of them are old Printers and industry equipment and a lot of old Cisco phones without dot1x option. 7960 without G
No the problem of profiling and authorization of these endpoints.
Till now I think and tested that when a endpoint is profiled for the first time with some data collected , this data stay in the endpointlist.
Sample Cisco ip phone is profiled as Cisco ip phone 7960 and authorized as the same with voice option. CDP value and others are collected correct.
No take a pc and the MAC address of the ip phone and we become access like this phone.
And I think this is because not all values we use are updated every time a endpoint is connected.most of the values that are profiled stay in the endpoint profiling.
In the documentation I read that the MAC address is the identifier!
And the other problem is that my English is very bad… 🙂
Hi Daniel,
No problem I’m following you and trust me, your english is much better than my german. So devices supporting 802.1x are fine however “headless devices” / devices without users that can’t authenticate such as printers are your target for support. Those devices are LAN only and you are using a combination of MAC and profiling. You are testing using a PC and spoofing a IP phone. You would like to see the PC computer be recognized as a PC based on behavior even though it has the iphone’s MAC right? This is a common use case.
To make this work, you need to first have a authentication policy for 802.1x devices and MAB devices. My assumption is you already have this. This determines if its a authenticated or MAC address based device. So your PC will authenticate 802.1x while a phone could go 802.1x if supported or default to MAB if not. Lets assume your phone goes MAB. When you spoof the MAC of the phone with the PC and don’t authenticate, your PC would also fall in the MAB category for authentication just like a phone.
The important thing is your authorization policy (second tab under Policy). This is where you determine what happens if a device is a user, phone, etc. So what you can do is build a few conditions. One can be all users in active directory that are windows devices end up in permissions EMPLOYEE. All phones end up in permissions PHONES. You can create others for iphones, androids, MAC laptops, printers, etc. The permissions are built under policy elements and this is where you choose what network or security is applied (IE put them in a VLAN, add ACLs, etc). If you build this correctly and enable profiling, your PC with the MAC of the phone will first end up in the phone permissions based on meeting the condition for phone (via its MAC address) however it should change to user or probably get denied since ISE will recognize its behavior as a PC yet not see it in active directory (IE its not a employee) causing it to fall into the default deny all policy. You could great a generic PC policy that doesn’t check for authentication so devices that are not authenticated by employees could fall into if you think it would help with testing however best practice is to let it fall in the deny all.
Hope this helps
Joey
Hi Joey.
I read your respons to Daniel.
You said that devices not authenticated as employees should go to deny all. But what should I do if I have a wired guest network, like in a conference room?
( I do prefer to have guests connect wireless with a guest login, but some companies have wired guest vlan that goes strait to the internet)
Regards,
Philip
Hi Phillip,
Actually you are right regarding guest users. The typical policy is having all failed devices end up in a guest redirection page or having that as the last policy before deny. So for the previous example, the PC that is spoofing the MAC of a phone would first get phone access however its behavior would change its status to a PC that has not authenticated as a employee. That would land the device in the guest redirection policy (if a guest policy is included) since its a PC that has a guest user. Thanks for pointing that out
Joey
Hello Joey,
Sorry for the late reply…
First of all I thank you for the Help at this good Blog!
At this time we are testing many things with ISE and hope that at the end all thinks works as design…
But I had now 3 questions:
1. In a other blog you describe the Cisco LMS, is this a think that could help to improve your network for dot1x? (more Easy)
At this time we manage all with the command line.
Do you now the Cisco Prime Infrastructure?
2. Is this correct? Without local ACL and dACL the ISE will not work as design to secure a network? (Or VLANs)
3. Have you a good address for example dACL for Printers or Cisco IP-Phones?
Thanks
Daniel
Hi Daniel,
Yes LMS features are migrating to Prime. The key things you should consider are
1) LMS / Prime offer the ability to perform a network assessment for 802.1x capability. The 802.1x report will check both hardware and software. If the software is not correct, you can enter you cisco CCO and download the correct version on the spot.
2) LMS / Prime offer templates to push out the 802.1x AAA commands required to enable ISE. There are templates for monitor only, low impact mode, etc.
3) Its best practice to use templates when enabling switches to avoid mistakes while enabling your environment for ISE.
Regarding your second question, its not completely true. Many people start off using ISE in open / monitor mode as a first phase. The idea is to gain visibility of what is on the network and eventually develop a network security policy. Once you want to enforce policy, the options are vlans, ACLs (both dynamic and regular) and STGs (for only devices supporting TrustSec). Cisco’s NAC appliance technology offers layer 3 in-band only and layer 2 using SNMP. Some of these features may bleed into ISE in the future but not available today. Most people start off by dumping all trusted devices into a vlan and either put other devices in another vlan, add a ACL or just deny them.
What type of example are you looking for? Here is a video on configuring dACLs http://www.youtube.com/watch?v=gEvXcplOZAs. The only thing to know is you can’t apply dynamic ACLs for wireless. You have to call ACLs from ISE that already exist in your wireless controller. Its not a big deal however it does mean you must make sure the ACL you call matches how its named in WLC (very common mistake).
Hope this helps
Joey
Thanks for the post. I have an ISE configured for my environment. I have the following issues
1) Devices that do not match authourization gets the default denyaccess policy but these devices still have full access to the network. I checked if any DACL was downloaded but could not find all. I later found out that the default denyaccess authorization policy does not use dacl as it uses reject access.
Could it be some config on my switch that allowing this access? isnt ISE suppose to overide the switch config since its integrated?
2) How does ISE profile a phone. It recognizes a Dlink Phone as just D’link device, so it does not match the NON-Cisco phone authorization profile.
Hi Elemzy. When things don’t work, its always best to call in TAC support.
Some suggestions you can look at are going under your identified devices and look to see how they are profiled (found under identity management). A lot of times people think ISE is seeing all network attributes however they find devices are being profiled with just radius information. For example, we had a customer that used wireless for DHCP locally at a remote site. So DHCP data wasn’t being seen by ISE located at another office hence endpoints were not being fully profiled. Sometimes a IP helper can give ISE visibility while other fixes could be moving DHCP to a internal resource. Keep in mind Profiling uses many different attributes so the more info it has, the better read it can make on a device time. For example, if I plug in a laptop and quickly unplug it, ISE only sees the NIC card manufacture (maybe) and the link uptrap. This at most can give you a basic idea of what the system is but more data would be needed to determine a “apple device” verse “MAC book”.
Regarding a IP phone, its as explained above. The thing is profiling is based on attribute weights. So for example, if you are not using DHCP and that has a high attribute weight to change a device from “ip phone” to “cisco phone”, then you may not trigger enough attribute weight to profile your phones. So what you need to do is click one of your Dlink devices under identity management and see what attributes are used to profile the device. You may need to adjust the Dlink device or Dlink Phone attribute weights such as ARP, DHCP, etc to make it work. In this very old blog post I explain how one customer didn’t use DHCP so Avaya phones were not being profiled. We had to adjust the Avaya attributes via lower the value for DHCP to make it work. TAC could help with this if you have questions on that process.
I have just walked into an ISE deployment with profiling enabled , ideally the client will like profiling not to apply to Cisco phones ( they want to use an imported Mac- address list from CUCM) . They will like profiling for wireless in the future but the profiling is consuming advanced licensing as it is probing phones . How do I get the ISE to turn of profiling for Cisco phones so as the save on the advanced licences and just use the basic licences with mab authentication.
There’s no way to be selective of what type of devices get profiled but as Craig (and many others) have stated several times on the mailer, a device will only consume an Advanced license if there is an AuthZ rule that uses Profiling or SGT Assignment. If you do not have an AuthZ rule based upon the phone profiling, you should not be consuming an Advanced license.
Thanks guys ,
I am not on this mailer , I just signed up to the blog recently . Thanks for the help . There is a catch all auth rule that allows all access ( fail open ) . This explains why the advanced licenses are being consumed .