Use case: Password expiration is set to 100 days in APS.cfg file. Per design, if the user try to login after 100 days then the user will be redirected to the password change page and there is no way to escape changing the password. The requirement is to allow the user to extend the password expiration date and not force the password change.
What you are looking for is , Password Expiration Grace Period.
You can achieve this by setting property "Expiration Grace" in APS.cfg file.
Details about this property below (copied from APS.cfg file )
// Once password expiration is reached, we no longer treat password
// change as optional (it becomes required). How many days AFTER the
// password expires do we actually disable the user.
// The PASSWORD SOFT EXPIRATION DATE, plus this number of days, is the
// PASSWORD HARD EXPIRATION DATE.
// Prior to version 2.0, APS did not support this feature.
// If you do not wish users to ever be disabled because of password
// expiration, set this to a very high number. Then, when the password
// expires, the user will be in a force password change state every
// time the user logs in.
// If this value is zero, then passwords will immediately expire when
// the password soft expiratsion date occurs (subject to Grace Logins,
// This setting supports overrides.
Hope this helps.
Good find but doesn't help for my use case. The "Expiration Grace" forces the user to change the password and it doesn't allow the user to access the application without changing the password. As I said in my use case, the requirement is to allow the user to extend the password expiration date and not force the password change.
If I set the "Expiration Grace" in this use case then the user will be allowed to login, after 100 days, but will be redirected to the password change page. The user will not be allowed to access the application. The "Grace Login" also does the same. The smapsNextAction parameter in user directory for the user will have PASSWORD HARD EXPIRE after the login (after the 100 days). This makes the APS to force the password change.
Okay, so If I get this you would want the password to expire but have APS not force the password change ? Then what would be the significance of the password expiration date ?
If that is the case, then will it not be sufficient to set the password expiration date to very high value such that password will never expire ?
The requirement is to enforce an optional password change after password expiration date. So after that date user will get an option to change (not forcing) but the user can cancel the password change and continue to use the same password. The idea is to allow the user to change the password at their own option.
In APS.cfg password expiration date is added to force the password change and allow exception for one group.
Thanks for clarifying your usecase.
So, what you want is an optional password change prompt after the password soft expiration date (after PASSWORD EXPIRATION days) but before password hard expiry (PASSWORD EXPIRATION+Expiration Grace )
Then, my first answer still hold valid.
Here is what you will need to do with an example :
PASSWORD EXPIRATION = 100
Expiration Grace = 1000 (set to high number as we don't want the user to be disabled/password hard expire)
;;Grace Logins (Disable this feature)
Now, when the user logs in after 100 days, the user will be successfully authenticated and will be redirected to the Force password change HOWEVER AZRedirect will NOT enforce force password change, meaning to say if the user attempts to access the protected resource he will be allowed to do so ...
I just tested this in my setup and it worked wihout any issue ..
Attaching , fiddler (where you can see user redirected to force password change and then subsequently also able to access the protected page ) ..and the corresponding smaccess.log which confirm user is AzAccept.
Please let me know if you have any further questions/concerns.
Thanks for testing this Ujwol. I looked at the fiddler trace and it looks like after you are on the password change page you are accessing the application again on the same browser (not doing anything on the password change screen). I appreciate your help but it looks like a work around/trick/shortcut for the use case. We need an option for the application users to select either go ahead with password change or cancel the request. We cant ask them to just drop that page and access the application again on the same browser session.
I am not sure the use case is working in your setup. The configuration shouldn't allow the user without changing the password but if it does allow then it may be a defect . I don't see AzAccept for the target in the smaccess log but the fiddler does show the target. So it may be somewhere from cache??
I tested this and I keep getting the password change page and the APS is not allowing me to access the application (if I try to access the application on the same browser where the password change page is). The only option I found so far is: when the user is on password expiration warning stage, the APS redirects to the password change page and also gives an option to cancel the password change and return to the application. We can add some custom script or something and then make web services call to user directory and modify APS parameters.
We can configure the CancelTo parameter to hold the location for the custom application that can modify the APS parameter at the user directory side.
Thanks for your help Ujwol; let me know if you have any other suggestions.
Can you please confirm if you have configured APS "AZRedirect" function for OnAccessAccept event (as below ) ..Based on what you have described..it seems like you have configured this..
Event : OnAccessAccept
Library : smaps
Function : AZRedirect
The behavior could be totally different if you have configured this.
In my setup I DON'T have this configured as I am not getting is working as designed.
For the second part, I agree that we will need some customization on the OOTB Password change page to be able to redirect to the protected page.
How did you go with this Saravanan?
Still working on; will post the result once tested. Thanks for checking in
It looks like it is not possible to extend the expiration date; need to file a Idea request.
I don't think that is the case. As discussed above, with a little bit of customization on the password service page (UI part) , your use case is fairly easily achievable.
I have done extensive testing on this use case and I couldn't find a way to extend the password expiration date. Can you validate if you have any suggestions?