disuser if password unused

[The Brit]

Hi Kendall,
I know this doesn't answer your question, however it may give you the same result.

1. When you reset the password, set the "Expiration Date" to "f$time() + 24 hours". If they don't login, the account will expire.

2. Place a few lines into SYLOGIN.COM to modify the UAF account of the user logging in. The modification I would suggest would be to set the "Expiration Date" to "f$time() + 30 days" (or whatever you think is reasonable).

Now, every user login resets their own Expiration Date for 30 days, including 1st time logins. The length of the Expiration Period is up to you (it could be as short as you want, however you need to consider intermittent users), however it has the added advantage that if users leave without your knowledge, their accounts will automatically expire "x" days after their last login.

Dave

[KENDALL MCCARTHY_1]

Does the GETUAI.exe just make it easier to work with the system service $GETUAI?

I like the idea of modifing the experation at login time . Ill give that a try.

[Jan van den Ende]

Kendall,

may or may not be applicable at your site.

I _DO_ assume here that you have a personnel system, which _IS_ kept rather up to date by the personnel department.
It would not be that hard to make an export of that, containig at least (and maybe just) the personal ID and the end-of-contract date. The latter of course can be "not-yet-known"
Transfer this extract to VMS, and have a little daily batch by a privileged account update the personnel records.
Of course, this requres "some" known coupling between personnel ID and VMS username, but that can not be too hard.

We also have the /OWNER directly out of the personnel system.

At the introduction we got quite a few requests to correct the spelling of the name, AND ... quite a few reports of suddenly expired accounts by people at work.
Deverting all those reports to the personnel department, we were hit back that "WE caused them sooo much work" (!!!??!! :-)

Luckily, our management was easily convinced of the fundamental correctness of the thing, and after about 2 months the result was a much more fault-free personnel system, amd an automagically maintained SYSUAF.

(for completeness, there is also a monthly job that removes all stuff for people gone for at least a period determined by management policy)

Not what you were asking, but, at least to us, a solution for your kind of problem.

hth

Proost.

Have one on me.

jpe

[Jon Pinkley]

Kendall,

For your original question: How to disable an account that had its password reset (by someone with privs) if the account has not been used and password changed within 24 hours?

For that specific question, go back and read Hein's reply from Aug 23, 2007 16:29:36 GMT. Hoff's original note had a lot of the same ideas, but Hein's goes into a bit more detail about why this isn't as straight forward as if there was simply a bit flag that indicated that the password was pre-expired.

Submitting a batch job at the time the password is reset is one way to accomplish this. However, for this to work, you would need to always use a command procedure to change the users password. This could also submit a batch job to run 24 hours in the future, and that batch job can check if the account still has the pwd change date set to pre-expired, using something like the GETUAI program. When the batch job runs, if the password change time is still pre-expired, then disuser/expire the account and send mail to someone. The standard command procedure for resetting user passwords should keep an audit history of when it changed the password, who changed it, etc.

If it is good enough to expire the account after a minimum of 24 hours and less than 48, using a daily job that remembers the accounts with pre-expired passwords will work (as also suggested by Hoff and Hein). This has the advantage of catching passwords that were reset without using the standard password change procedure.

I also liked Jan's suggestion, and that is certainly a good way to keep the personnel system accurate and synchronized with the system.

The suggestion to change the expiration date of the account with something in the sys$sylogin command procedure as a way of expiring inactive usernames sounds good on the surface, but the "few lines" to add to SYLOGIN.COM were not specified, and I can think of no standard utility that will do that when run by an non-privileged user. I.e. it isn't possible to do something like what set volume/retain=(0,30-0) does for file expiration dates. and I certainly would not want something constantly moving the expiration date, since we use it for short-term contractors, and to enable the field service account for 4 hours. It would certainly be possible to write a program, install it with privileges, and run it from the sys$sylogin command procedure. That's more involved (and in my opinion, higher risk) than having a daily job (perhaps the same one checking for pre-expired passwords) check the last (interactive?) login time and after some specified amount of inactivity, disable the account and notify someone via mail. Be careful with this, as I believe here are some versions of some SSH implementations that do not update the last login field, so you probably would want to start sending messages x days before the account was expired/disusered.

Good luck,

Jon

[Richard W Hunt]

Working with the US Dept of Defense, I see the requirement to expire accounts that are unused in X days. I found that generally speaking, nobody cares if you implement your solution daily, weekly, or monthly. (Longer than monthly? Somebody cares...)

A long time ago I built a little time manipulation utility and a variant of the GETUAI program so that I could write DCL scripts to do this kind of work. Basically, my script scans SYSUAF for each user having interactive rights. (If you have users that do not have interactive rights, they cannot reset passwords anyway.)

For users whose password is older than the PWD_LIFETIME value, I force the PWD_EXPIRED flag and reset the password at the same time. There are various ways to do time comparisons, including CVTTIME calls that subtract two times via some careful substitution and it can give you a DELTA-TIME output. Using string parsing, you can get the DELTA-TIME and see how many days are involved. Just an F$ELEMENT of the time: F$ELEMENT( 0, "-", timestring ). That will be 0 or greater.

This requires our low-use users to call our Help Desk. The Help Desk has a utility I wrote to allow them to reset passwords and the PWD_EXPIRED flag for any non-privileged user.

This scan runs once per month, which seems to make our security guys happy. Another scan finds accounts with expired passwords that have not been reset in x months. I manually disable those accounts. That latter scan ALSO finds disabled accounts that have been disabled at least a month. I manually REMOVE those accounts. This very much makes our security guys happy.

As to why there is not a PWD_DATE: When you use SYSUAF> MOD DUMBCLUCK/PASS=ID10T, by default you get a PWD_DATE of -1. However, if you include /NOPWDEXPIRED in that command, the date is updated to the moment of the password change (at least, I think it is) in OVMS 7.3-2