Thank you. That code change worked and seems much cleaner than my previous workaround of using a SQL trigger to update the expiration date. I would like to see this configurable through the GUI as well as allowing the user expiration time to be longer. The field for it only accepts 4 digits limiting it a maximum of 9999 minutes or about 6.9 days. If there is an appropriate method for me to submit this request I will be glad to do so. You mentioned Jira but I don't see any way of submitting anything there. maybe I am missing something

So I'm sorry to ask a stupid question here but I honestly have never edited a ascx.cs file.

Should I be able to edit this in notepad ++? Or do I need to open the file in visual studio?

Also I did attempt to open it in notepad ++ and searched for 1440 and other strings to try to find it. I did not. Am I missing something?

Thanks Cathal for the info. This should help once I figure out what I am doing.

I've run into the same issue, and though this thread has been very helpful, I have one additional question: is there an expiration difference between the token that is created as part of the Add New User process and the token created when clicking Send Password Reset Link as part of editing an existing user? As far as I can tell, resetting the password on an existing user adheres to the 24 hour expiration. However, the reset token created when Creating/Adding a New User does not. Does it ever expire?

And, related to this, it seems the same email (EMAIL_PASSWORD_REMINDER_BODY.Text) gets sent to the User for both User-requested and Admin-initiated password resets. So, language that tells the user how long they have to reset their password won't work as it could be either 60 minutes or 24 hours depending on how the request was initiated, correct? Is there some way around that problem; isn't it important to let people know how long they have so the token doesn't expire without them acting on it?

Thanks.