cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
367
Views
4
Helpful
6
Replies

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

jyla
Level 1
Level 1

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

create-matching-identity-group.png

 

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.

Endpoint-identity-groups.png

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

1 Accepted Solution

Accepted Solutions

@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.

ArneBier_0-1708719580229.png

 

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

 

View solution in original post

6 Replies 6

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

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.

auditlog.png

@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.

ArneBier_0-1708719580229.png

 

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

 


@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.

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
Level 1
Level 1

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.