cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1140
Views
6
Helpful
8
Replies

Cisco ISE sponsorportal wrong mail/print notification variable

ahaemmerle
Level 1
Level 1

At Cisco ISE sponsorportal page customazation -> Print Notification / Email Notification one of the default printout = "If unused, this account will expire on: $ui_guest_account_purge_date$"

the variable $ui_guest_account_purge_date$ is equivalent to the account-creation-date + account duration
example: when I create the account on 5th of January 2023 with a duration of 10 days (duration is starting with first login) then my printout will show "If unused, this account will expire on: 15th of January 2023"

In my opinion the variable $ui_guest_account_purge_date$ should be equivalent to the date until account expires as defined in "guest account purge policy" which is in my case 90 days (If a user doesn't login to his guest account within 90 days, his account will automatically deleted)
example: when I create the account on 5th of January 2023 with a duration of 10 days (duration is starting with first login) they my printout should show "If unused, this account will expire on: 5th of April 2023"

The exact same problem was mentioned in CSCvs25680 but unfortunatelly the public access to this bugID was restricted.

Can somebody please tell me if I am wrong with my opinion or if this is a bug or something else?
If this is a known bug, can somebody tell me when this will be resolved?

As additional information, I am using the default templates for email and printing notification as below:

Hello $ui_first_name$,
Your guest account details:
Username: $ui_user_name$
Password: $ui_password$
First Name: $ui_first_name$
Last Name: $ui_last_name$
Phone Number:$ui_phone_number$
Valid From: $ui_start_date_time$
Valid To: $ui_end_date_time$
Duration: $ui_guest_access_duration$
Person being visited: $ui_person_visited$
Reason for visit: $ui_reason_visit$
If unused, this account will expire on: $ui_guest_account_purge_date$

Thanks

Andreas

1 Accepted Solution

Accepted Solutions

TAC gave me information that in 3.2p2 the problem is fixed.

I can confirm that the problem is fixed with 3.2p2.

The $ui_guest_account_purge_date$ variable is now calculated in my case with 90 days, thats correct now.

 

View solution in original post

8 Replies 8

Arne Bier
VIP
VIP

Hi Andreas,

I don't know the authoritative answer, but I always separated the "validity period" of a guest account and the "purge policy". The current calculation of 15 days (using your nice example) seems correct to me, since that is following the intent of the configuration (validity = 10 days) - if you calculated it based on purge date, then the guest would be confused when they tried to login after 15th January - and start arguing with you why this is not working, as outlined in their guest welcome email.

Do you have a need to re-enable disabled accounts? Why not make the validity period longer?

Hi Arne,

thank you for your answer. I think we have a different understanding of that variable.

I will try to explain my understanding of the calculation of $ui_guest_account_purge_date$ with a little bit more detail.
- account-creation date = 5th of January 2023
- first use of the account = 10th of January 2023
- guest acount duration = 10 days (account expiry starts at first login)
- guest account purge policy = 90 days (this does only affect unused or expired accounts. accounts which has a duration of 365 days for example are not affected of this policy)

At account creation date at 5th of January, the guest was never logged in.
purge date = 5th of January + 90 days = 5th of April
"If unused, this account will expire on: 5th of April 2023"
-> this information is helpful for the guest to know until when he has to login first before his account will be automatically deleted.

At first login of the Guest at 10th of January, the purge date is changing to another date. This is because the account is no longer in "unused" state.
purge date = 10th of January + 10 days of duration + 90 days = 20th of April
"If unused, this account will expire on: 20th of April 2023"
-> this information for the guest is not very important to be honest. In most cases this information will never be given to the guest because the printout is handed out to the guest right after the creation-time of the account and not after first login-date. Maybe this information is helpful for the sponsor to know when the account will be deleted and the sponsor is not able to re-enable this account..
Attention:
20th of April is the date when the account will be deleted from the system.
20th of April is not the date until when the guest account can actually be used (this would be 20th of January in my example)

The guest will know his account expire date with the other fields like.
Valid From: $ui_start_date_time$
Valid To: $ui_end_date_time$
Duration: $ui_guest_access_duration$
It does not make sense that the $ui_end_date_time$ has the same value as $ui_guest_account_purge_date$

Now to your questions:
Do you have a need to re-enable disabled accounts? -> yes, the sponsors sometimes re-enable the accounts for guests.
Why not make the validity period longer? -> the period is defenid by the sponsor
(I only administrated the guest-portal "backend". The sponsors are responsible to create the guest accounts.)

Please correct me if you think I am wrong with my understanding.

Thanks
Andreas

Arne Bier
VIP
VIP

Hi Andreas,

Oh right - I get it now - thanks for your very clear and detailed explanation. I have never looked into this dilemma in as much detail as you have ! Nice one.  

I reckon this might be a question for the BU (e.g. @hslai ) ?

hslai
Cisco Employee
Cisco Employee

@ahaemmerle 

Which ISE release and patch level is the ISE deployment on when the issue is seen?

CSCvs25680 is not visible because it's in Junked state. It was reported as seen in ISE 2.4 Patch 4 ~ 10 and ISE 2.6 Patch 3 but got junked when a customer reported it went away after the latest ISE patch applied to the customer setup in ISE 2.6 with the issue.

If the setup has a newer ISE release and on the latest patch and if you have a TAC case, please ask TAC to recreate it and reach out to our BE teams.

Regards.

I am currently using version 3.1 Patch 5.

As you suggested - I  have opened a TAC case 694877826

Did you ever get this resolved? I'm having the same problem and I have a very specific usecase for which this information is actualy pertinent.

The case is till under investigation by Cisco TAC.

TAC gave me information that in 3.2p2 the problem is fixed.

I can confirm that the problem is fixed with 3.2p2.

The $ui_guest_account_purge_date$ variable is now calculated in my case with 90 days, thats correct now.

 

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: