This article will go over the ins and outs of Cisco ISE Profiling. Profiling is the process used by ISE to determine what type of endpoints are authenticating. The configuration is not overly difficult but can get confusing when you have multiple similar endpoint types and want to ensure your database is accurate. This is even more important when you use profiling to help create authorization policy. For example, if you want to apply a specific policy to an iPhone, you have a problem if ISE does not know it is an iPhone authenticating.
Profiling Probes
A profiling probe is the method ISE uses to learn information from the connecting endpoint. As of this writing, there are eleven probes.
Administration --> System --> Deployment --> PSN --> Profiling --> Configuration
Netflow Probe
As you guessed, you can send Netflow to ISE. ISE will consume the data and attempt to determine the endpoint profile of each received IP.
DHCP
In most deployments, this is likely the most important probe. On the switch/router side, you can create an IP-Helper address which instructs the switch to unicast all received DHCP packets to ISE. There is quite a bit of information in simple DHCP packets.
DHCPSPAN
A DHCP SPAN can be used in situations where the regular DHCP probe cannot. It is effectively the same probe, but instead of obtaining the information from an IP-Helper (preferred), the information is obtained via a SPAN.
HTTP
ISE will look at HTTP headers and gather information such as the User-Agent and OS information being sent.
RADIUS
The RADIUS probe always collects at least some information. Optimally, it would gather information from the switches running an IOS Sensor. Attributes from CDP, LLDP, DHCP, HTTP, and MDM can be sent with RADIUS packets.
Network Scan (NMAP)
Frequently NMAP is used only for certain device types that are not easy to identify. A good example is something like an HP endpoint. HP makes a million different endpoints and there does not appear to be much of a rhyme or reason to their MAC Address assignments. From the OUI, ISE will know it is an HP endpoint and ISE can automatically trigger an NMAP scan to gather more information.
DNS
This is a simple reverse lookup against DNS on the IP to see if DNS has any additional information.
SNMPQUERY
Queries SNMP for attributes such as CDP, LLDP, and ARP.
SNMPTRAP
Monitors Link up/down and MAC moves.
Active Directory
The AD probe will query Active Directory for more information about domain joined endpoints. This comes in handy when ISE is not 100% certain on the exact Windows OS flavor it is seeing.
pxGrid
Finally, ISE can look at the pxGrid queue for additional attributes.
What does ISE know?
Why is ISE profiling an endpoint one way or another? You can see everything ISE knows about an endpoint by going to Work Centers --> Network Access --> Identities and then clicking on the endpoint you are interested in. Here is an endpoint that is attaching via VPN:
As you can see, that is an enormous amount of data and we do not even have very many probes turned on.
Profiling Database
The profiling policies are a large hierarchical database of the endpoints ISE is capable of profiling. It works on a series of rules and a point system. For example, let’s look at rules for an Android endpoint.
Top-Level Policy = Android
For this first one, we’ll go through it all:
Name: Just the name of the profile.
Policy Enabled: Obvious
Minimum Certainty Factor: The minimum certainty factor dictates how many “points” have to be accumulated for this policy to be true. In this example, you can see towards the bottom under “Rules” that each of those conditions adds 30 points to the profile. In other words, if any of the condition are true, the endpoint is an “Android”.
Exception Action: An exception action is a custom or built-in action to take when a profile match is made. For this one, we have to take a little detour. So, you plug in your PC for the very first time – At this point ISE may not know what the endpoint is yet. Moments later, ISE begins receiving profiling data and then realizes exactly what the endpoint is. Here is the issue. You are already logged into the network with an “unknown” profile. However, you may have policy specific to the endpoint type you are logged in with. If you log out and log back in, you will get the right policy. However, what if you don’t? The answer is, ISE can send a CoA to tell the switch or WLC to force a port bounce or reauthentication. The reauthentication is generally preferred as it takes place quicker.
The CoA based on profiling can be a little scary, especially with PoE VOIP desk phones. If ISE decides your Cisco Phone is now a Cisco xyz Phone, all phones in your entire company will reboot. Bad Times. The fix for this unlikely scenario is to not use a Global CoA action when a profile changes. There are several exception actions to determine how CoA should take place and when. This is somewhat duplicative as there are other options to do very similar functionality.
NMAP Scan Action: When an endpoint hits a generic or aka top-level policy, you can automatically trigger an NMAP Scan to get more information. This will make more sense shortly.
Create an Identity Group for the policy: An Identity Group is a collection of identical endpoint types and can be used in authorization policy. This can work well for endpoints such as printers. We can write our rule to say if you are in Identity Group HP Laser Jet XYZ, you are allowed on the network and can only communicate with these specific ports.
Associated CoA: Another CoA override.
Rules
Here we have 3 rules that are all worth 30 “points”. For each true condition, 30 points are added to the total. If the total meets or exceeds the minimum certainty factor, the overall profile is a match. The Conditions live at Policy Policy Elements Conditions Profiling
The first condition is called Android-Rule2-Check1
ACIDEX is an attribute that comes via VPN when using the Anyconnect client. This is basically saying that if the device-platform attribute EXACTLY equals “android”, add 30 points. Easy enough. If the condition is true, 30 points are added to the total. Let’s look at one more:
The next one is AndroidRule1Check2.
This uses the DHCP Probe to glean the host-name attribute. Simply, if the host-name contains the value “android”, 30 points to the total. Notice the “contains” operator – This means the host-name could be xyzandroidabc or android. Both would match.
That’s all there is to it! However, keep in mind the profiling process is hierarchical and this is a top-level policy.
Let’s look at the first “sub” policy, Android-Amazon. First notice, that this policy also has additional sub policies.
Note the minimum certainty factor of 40 and keep in mind this profile will never match unless its parent also matches. In other words, you cannot be an “Android-Amazon” unless you were already a “Android”.
Finally, we have one more layer – Android-Amazon-Phone
This one also has a certainty factor of 40. To be an “Android-Amazon-Phone”, the endpoint must match “Android” and “Android-Amazon” first.
You can also create your own profiles with custom conditions. For the most part, the best practice is to use very high certainty factors to ensure your custom profiles never interfere with the built-in ones. If you would like assistance with your Cisco ISE environment, contact us today!