· Mar 21, 2018

Is there a temporary-password concept in Caché 2016?

I need to offer new users on our system a temporary password that is valid for only 48 hours.  This is different than a 60-day password expiration window for existing users' passwords (where a password needs to be changed every 60 days), and is different than a "user expiration date", where you can set a date where the user's account expires and is disabled on that date, and different than the inactivity expiration date where a user becomes active if his account is not used within, say, 30 days.  

What I need is a password-inactivity expiration date such that if the user does not log  for a first time within the time limit (48 hours), then the user account is disabled - but not expired! - and then must be "reset" to a new password (whereupon the cycle begins again, and the user is disabled withint 48 hours if he doesn't log in and change his password!).  

I'd prefer not to use the user expiration date, as this is not accessible when the user logs in  (being in Security.Users in %SYS namespace), and would have to be removed separately.

This concept is not quite the same as a Time-based-One-Time-Password, and we don't need two-factor authentication.  

Does InterSystems 2016 have this sort of setting, or do I need to put it into a password validation or some kind of login authentication routine?

Thanks for the help,


Discussion (2)0
Log in or sign up to continue

I think it is possible to do, with little coding.

  • Set Inactive limit in system security settings.
  • While Inactive limit is a system-wide setting, you have to check  Account Never Expires  for those users who should not be expired.
  • InterSystems Cache has special task SecurityScan which executes every day, and disable expired users.
  • Create new system task, and schedule it to start after SecurityScan. This task should find disabled users in table Security.Users, and enable them and set flag ChangePassword, which will say to change a password on next login.

A task, of course... I'll have to go through the list of users and check their LastLoginTime/CreateTime, Enabled, etc.  For future users who are looking for this, I'll use the SQL procedure Security.Users_Detail().

I did not know about the Security.Scan, but I'll take a look, and see what else I should tack on to it.  Good idea to run our custom security task after the SecurityScan.

Thanks! Getting there.  And perhaps InterSystems will add this concept in the 2017 (2018?) release.