Purge endpoints based on blank status?

[Josh Morris]

As you can see by the image below (just a subset), I am getting a lot of endpoints show up that appear to never actually hit one of my rules. It will sit like this until it hits the inactiveDays endpoint purge or I purge manually. Does anyone know a way to either purge these more quickly, or deny them from getting into the database altogether?

[hslai]

@Josh Morris Please drill into a few of such client endpoints and see how they are learned (i.e. which probe(s) used as the source(s)).

[Josh Morris]

Most are Radius. I did have the pxGrid profiler enabled and was getting a lot of blank endpoints from that but have since disabled the profiler. 

[Rodrigo Diaz]

The information you are displaying is from the context visibility, this information is purged regularly depending upon the rules you have configured in Administration>Identity Management> Settings> Endpoint Purge , see example below , when an endpoint attempts to log in your network with base on attributes this is going to be classified accordingly , if you have identified a group of endpoints what you can do is to set a rule that make the purge quicker, for your reference https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/215931-ise-guest-account-management.html 

Let me know if that helped you . 

[Josh Morris]

Thanks. I am using quite a few Endpoint Purge rules. The problem here is that there aren't enough attributes to do much with these. I can't get them profiled to a group in order to use in a purge rule. I also am unwilling to create a default purge rule based on Elapsed or Inactive Days because there are many endpoints that would hit that rule that I don't want to purge. 

What I'm really hoping is that ISE has a mechanism to purge endpoints when the attributes are blank.

[Rodrigo Diaz]

In addition to what it has been said here, once you checked the livelogs of such endpoints you can elaborate a rule based on the characteristics of those using the attributes option that is available in the endpoint purge page. 

[hslai]

@Josh Morris We are trying understanding how these endpoints got in as Internal Endpoints. Many of them seem gone through authentication only but not authorization. Please check the auth detail reports for some of such endpoints.

[Josh Morris]

@hslai  I think there are two cases here. The first is that an endpoint connects to a switch, and does just enough to get an endpoint created in the context visibility but doesn't go through the full AAA process, as seen with the endpoint details below. This is my main concern. These are the types of situations I'm trying to prevent.

Then, there is the following situation, where the endpoint seems to go through the AAA process, and get matched to an authorization rule.