Improve Expiration date utilization

[rodrigopcrj]

As per my testing, in order to have any device expiration we will not be able to have devices with no expiration when using a single Authorization Profile. If we want to have device with expiration, we would need to have one Authorization profile setting the maximum access term, and another one setting up "No expiration". And that requires to have two Endpoint groups, one to each authorization profile. And if the user wants to put expiration to a device previously created with no expiration, he would need to delete and create again on the group with expiration, only admins are able to change the grouping, the users should be able to change the grouping based on the the grouping they have access.

Suggestion #1 - remove "Extend". It doesn't make much sense when you are, for instance, changing the expiration to a closer date...

Suggestion #2 - Add "Set expiration". And be able to choose "Never" as well as any other period, if "Never" is allowed in the authorization Profile.

Suggestion #3 - add "Edit Endpoint Grouping" to user portal, so they can change to another group also associated with his portal.

[ciesinsn]

This is a interesting request and when I get some time I'll look into it more.

[rodrigopcrj]

I just figured out that "Suspending" or changing expiration is not actually changing anything in the database.
I suppose that suspending the endpoint should change "accountEnabled" to 0, but nothing happens. The same when changing the expiration data, the value doesn't change.

Supposing that the behavior is fixed, does the stored procedure also check for "accountEnabled"?

[rodrigopcrj]

I receive this error when trying to change the attribute value using ipsk-db-user.

It complains about TRIGGER command being denied to ipsk-ise-user.

[ciesinsn]

The ISE DB user is one that is used for the ISE ODBC connection. ISE shouldn't be executing updates like that. Do you have your DB accounts swapped? The error is showing its using the ISE user not db user for the call.

[ciesinsn]

Is this a upgrade?

[rodrigopcrj]

yes sir

[ciesinsn]

Did you notice in the schema update that you needed to use two different usernames for the procedure and trigger change items which is different from past schema updates?

[rodrigopcrj]

Thanks, that was the problem... I re-ran the update with the right username in the script.

does the stored procedure also check for "accountEnabled"? or would I need to create an exception rule in ISE to look for this attribute?

[ciesinsn]

some of the stored procedures look for accountEnabled being 1 when it does the select against the table for a match.