cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3337
Views
5
Helpful
5
Replies

Updating endpoint custom attribute using ERS causes ISE to perform reauthentication on ISE 2.2

orp
Level 1
Level 1

Hello,

 

We came across an issue that a profiled endpoint lost its profiling after its custom attributes were updated through ERS.

In the body of the API call I had only included the mac address and a couple of custom attributes.

I don't have full details at the moment as this has happened at a client's site but I'll get everything else necessary to resolve.

 

Thanks

1 Accepted Solution

Accepted Solutions

There is a global setting that controls whether or not you want ISE to issue a Change of Authorization (CoA) when profiling data changes.  Go to Administration->System->Settings->Profiling.  There is an option for CoA behavior whether to do "No CoA", port bounce, or reauthentication.  Within the profiling policies, there are also options there to trigger a CoA for a specific profiling policy.

This behavior is expected/wanted in a lot of environments because if attributes change for a device, it should be profiled again to ensure the profile is accurate.  And if the profile changes, the device should probably be reauthenticated to ensure it has the appropriate access.

View solution in original post

5 Replies 5

orp
Level 1
Level 1

Example data sent to the API endpoint:

data = {'ERSEndPoint': {'mac': '00:11:22:33:44:55',
        'customAttributes': {'customAttributes': {'key1': 'value1'}}}}

We've since discovered that the issue is different than we'd originally thought. It seems that updating the values of the custom attributes causes ISE to perform reauthorization of the endpoint, which might not be the expected behavior.

Is this at least documented somewhere?

There is a global setting that controls whether or not you want ISE to issue a Change of Authorization (CoA) when profiling data changes.  Go to Administration->System->Settings->Profiling.  There is an option for CoA behavior whether to do "No CoA", port bounce, or reauthentication.  Within the profiling policies, there are also options there to trigger a CoA for a specific profiling policy.

This behavior is expected/wanted in a lot of environments because if attributes change for a device, it should be profiled again to ensure the profile is accurate.  And if the profile changes, the device should probably be reauthenticated to ensure it has the appropriate access.

Thinking about what you said, it does make sense. Though the granularity of controling this feature is a bit rough I think. I may want to disable it for updating the custom attributes, or maybe per probe. But maybe this suggestion is not a normal way to operate.

 

In any case, thank you very much for the answer, very helpful.

orp
Level 1
Level 1

Hi, getting back to this. What happened is actually that an endpoint that was statically assigned to an identity group lost the static assignment and became "Unknown" since it had no further attributes.

 

Is this a possible behavior of ISE?

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: