disuser if password unused

[KENDALL MCCARTHY_1]

Is there a mechinism to disuser an account if the account is not logged in after 24 hour of a password reset?

[Hoff · Accepted solution]

Assuming standard authentication mechanisms and tools, AFAIK no; not without some coordination with and processing performed within some sort of daily processing job running.

You can set the password as pre-expired and set the account expiration date for 24 hours, and have an hourly or daily job detect a login and reset the expiration.

Various sites I know well use a batch job that runs some number of times a day or a week and that watch the last login, and use that to advance the account expiration. This requirement would be a slight variant on that basic approach.

I'd also expect that most any external authentication scheme around -- token-card-based logins or other such -- could either provide this, or be extended to provide this.

The batch job can simply run an image that calls $getuai and other such accouterments. (It's ever so slightly undocumented territory here, as you'll be using a direct RMS access into SYSUAF on the username key to get the usernames to feed into $getuai.)

There are other approaches.

[Hein van den Heuvel]

No supported mechanisme, but a quick scan of sysuaf will readily get you there.

See brute force sample code below.

Mind you, I believe it would be better / nicer / cleaner if the procedure which changes the password adds a record with username and date to a 'todo' list.
Next a simple program with $GETUAI or DCL script with MCR AUTHORIZE SHOW can check daily / weekly whether specific users need action. Much more targetted, less brute force.

Hope this helps some,
Hein van den Heuvel (at gmail dot com)
HvdH Performance Consulting



$! uaf_pwd_reset_age.com [] Hein van den Heuvel,August 2007.
$! List records from SYSUAF for which the Last Interactive Login is more
$! than a day before the last Password Change.
$
$!libr/extr=$uafdef/out=uafdef.tmp sys$library:lib.mlb
$!sea uafdef.tmp flag...
$!EQU UAF$Q_PWD_DATE 380
$!EQU UAF$Q_LASTLOGIN_I 396
$!EQU UAF$L_FLAGS 468
$!EQU UAF$V_DISACNT 4
$
$define sysuaf sys$disk:[]sysuaf.dat ! Local copy for testting
$close /nolog auf
$open /write/read/share=write uaf 'f$parse("SYSUAF","SYS$SYSTEM:.DAT",,,"SYNTAX_ONLY")
$ found = 0
$ records = 0
$loop:
$ records = records + 1
$ read/end=done uaf rec
$ if p1.nes."" then read/end=done/key=&p1 uaf rec
$
$! Just pick up the top 32 bits from the date fields
$! This get 1 click per 00:07:09.49, or about 202 clicks/day
$ pwd_date = f$cvsi(384*8,32,rec)
$ lastlogin = f$cvsi(400*8,32,rec)
$ disuser = f$cvsi(468*8+4,1,rec)
$ approximate_age = ( pwd_date - lastlogin) / 202
$ username=f$extr(4,12,rec)
$
$ IF approximate_age .GE.1 .AND. .NOT. disuser
$ THEN
$ found = found + 1
$ WRITE sys$output "MODIFY ''username' /FLAG=DISUSEER ! ~''approximate_age' days."
$ ENDIF
$ if p1.eqs."" then goto loop
$done:
$WRITE sys$output found, " targets found. Total records: ", records
$close uaf

[KENDALL MCCARTHY_1]

That .com loks like the correct direction though I am having trouble getting it to work. Im on V7.1 of vms.

[Hein van den Heuvel]

Various versions of VMS have had various maximum symbol sizes.
Your SYSUAF might have records longer than DCL V7.1 can handle

We can try replacing the direct open of sysuaf by a temprary copy with truncated records, long enouigh to hold interesting fields. For example by replacing the OPEN/READ/SHARE=WRITE above with:

$sysuaf_tmp = "sys$login:sysuaf.tmp"
$sysuaf = f$parse("SYSUAF","SYS$SYSTEM:.DAT",,,"SYNTAX_ONLY")
$conver/share/fdl=sys$input/truncate/pad 'sysuaf' 'sysuaf_tmp'
file; organization indexed;
record; format fixed; size 480
area 0; bucket 63;
key 0; seg0_l 32; seg0_p 4;
$
$open /read uaf 'sysuaf_tmp'

hth,
Hein.

[KENDALL MCCARTHY_1]

Exactly what I needed Thanks!

[KENDALL MCCARTHY_1]

I just noticed something. I went into authorize and reset my password:

Before -

Expiration: (none) Pwdminimum: 6 Login Fails: 0
Pwdlifetime: 60 00:00 Pwdchange: 23-JUL-2007 11:50
Last Login: 23-AUG-2007 09:35 (interactive), 23-AUG-2007 00:05 (non-interactive)

UAF> modify mccarthyk /password=********
%UAF-I-MDFYMSG, user record(s) updated
UAF> exit
%UAF-I-DONEMSG, system authorization file modified
%UAF-I-NAFNOMODS, no modifications made to network proxy database
%UAF-I-RDBNOMODS, no modifications made to rights database

Then -

LOTTOA: mcr authorize
UAF> show mccarthyk
Expiration: (none) Pwdminimum: 6 Login Fails: 0
Pwdlifetime: 60 00:00 Pwdchange: (pre-expired)
Last Login: 22-AUG-2007 13:13 (interactive), 21-AUG-2007 18:00 (non-interactive)

log out and in -

No access restrictions
Expiration: (none) Pwdminimum: 6 Login Fails: 0
Pwdlifetime: 60 00:00 Pwdchange: 23-AUG-2007 09:45
Last Login: 23-AUG-2007 09:44 (interactive), 23-AUG-2007 00:05 (non-interactive)


What this is telling me is that if a system manager modifies a password , a password date is not set ? (it get set to expired) and when the user loggs in , the password change time is later than the last login time. correct?

[Jan van den Ende]

Kendall,

Correct!

The pre-expired flag is set to indicate that the user did not do the change him/herself; and the user MUST change it.

Timing?
Well, the password was changed.. BY YOU, (forced by LOGINOUT) and AFTER you logged in.
( The difference is at most LGI_PWD_TMO, plus LGI_RETRY_LIM * LGI_RETRY_TMO )

Proost.

Have one on me.

jpe

[Hein van den Heuvel]

In my testing I got confused between my test version of SYSUAF and the real one.

As Jan hints to, Autohorize has thise notion of pre-expired. This is implemented by setting the pwd_date field to -1.

So best I can tell there is NO field in the sysuaf record which records the time when a password change was initiated, and therefor the original problem can not be solved using standard sysuaf alone. Sorry.

The procedure which does the pasword reset will have to do something extra. Creating its own 'todo' list with username + date woule appear to be the easiest. Conceivably it could also exploit an other SYSUAF field like USRDAT or the EXPIRATION date, but that gets hokey quickly. I supposed that the audit records could also be reviewed to find the actual reset time.

Alternatively the prodecure doing the checking can do something extra.
It could 'see' a pre-expired password one day, and record that. Then on the next day, if that record is still pre-expired, then it could assume the reset password for the account was not used in a timely fashion.

Regards,
Hein.

[Anton van Ruitenbeek]

Kendall,

There is also a programm (I think its on the freeware CD) GETUAI.EXE. Using this you can get information out of the AUTHORIZE file without having privilege (for your own account). If you want info of another user you need (of course) privilege.
You run the procedure with /=.


MC GETUAI.EXE -
/PWDATE= -
/LAST_LOGIN= -
/DISUSER=

Almost all options are available. If you install this (freeware) you get the whole help with it.

The rest of the calculations are up to you how to implement this in a com procedure.

AvR

[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