Profiling policies (30. jan 2024) creates matching Identity Group

[jyla]

Have anyone else noticed that all the new profiling policies provided by Cisco are configured to create matching Identity Group ?

The explanation from Cisco TAC is that this is how it is supposed to be, I just find it odd that suddenly all these devices should have a separate endpoint identity group.

Is it just me being "grumpy" and a bit annoyed by the sudden grow in number of endpoint identity groups ?

[Aref Alsouqi]

That's interesting! Which ISE version are you running?

[jyla]

I have seen this on 2 deployments

3.1 patch 8
3.2 patch 4

FYI. this is seen in the configuration audit logs at the time.

[Arne Bier · Accepted solution]

@jyla - that's a great pickup. I would say this is a mistake on Cisco's part, because this method of creating an Identity Group for profiled endpoints is a legacy ISE 1.x thing, and Cisco even advised against this in later versions.

You can point them to this Cisco Profiling Document where this advice is given.

I don't like modifying Cisco Provided Profiling Policies (their status changes to "Admin Modified") because I have found that the Profiler update then refuses to update properly. 

But looking at an ISE 3.2 system, I don't see hundreds of these Groups - it's around a dozen or so. I would simply ignore it - but you can have a good discussion with Cisco to remind them this is a bad practice

[martin42martin]

---

@Arne Bier wrote:
...

But looking at an ISE 3.2 system, I don't see hundreds of these Groups - it's around a dozen or so. I would simply ignore it - but you can have a good discussion with Cisco to remind them this is a bad practice

---

This is something I was trying to understand for couple of days - I mean the logic behind the fact that some Profiling Policies do have the ID Group created but others don't. For example Windows11-Workstadion does, but any other Windows version doesn't.

If I wanted to have a condition in my AuthZ policies that checks if the endpoint is a Workstation then Win11 machines would fail to match this condition.

This is obviously easy to remediate even though you say it's discouraged because of the potentian policy update failure.

In general, I don't understand why some endpoints only become part of the default "Profiled" ID Group (making it easy to check if the endpoint is successfully profiled) but others become part of more specific ID sub-group. It'd be great if I could create a condition to match the groups in the ID group parent chain.

[Arne Bier]

I see it as follows: The automatic creation of Endpoint Identity Groups via the Profiling mechanism is only useful if you're interested in neatly placing endpoints in an Endpoint Group for some obscure reason (that I can't even think of). If you're using Profiling, then you don't need to check an Endpoint Identity Group to see if the endpoint is in there. Profiling allows you to check the Endpoint Profile of an endpoint, and then use the power of the Logical Profiles concept to group many profiles into one. At no point do I care about looking up those endpoints in any Endpoint Identity Group.

Endpoint Identity Groups are useful for implementing Guest Portal solutions, and for situations where you don't have Profiling, or where Profiling cannot be used (tricky IOT devices).

Why Cisco did what it did in its Cisco Provided Policies?  You should send some feedback via the ISE GUI - there is a link somewhere for that. They do read that  

[davidgfriedman]

I don't use the AI feature but when I create a manual profile, I have always checked the box for it to create identity groups automatically for me. I also use Logical Profiling policies to group similar profiles into "families", such as Cisco IP Phones, Intercoms, desktops, etc. This allowed me to add new models to a policy as they are onboarded, plus easily remove certain models as they age out, get replaced, and disappear from our ISE clusters.  I have also started using the Logical Profiling Policies description field to include and e-mail list for the department who "owns" those devices, ensuring my team and I always have an easily document (read: inside ISE) way to find out and contact that team if we come up with any issues or concerns.

TLDR; - I do that with all of my manual profiles, and group them with logical profiling policies, plus leave owner contact data for that "family" of devices inside the LPP description field as self-documentation.