Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!killer!ames!pasteur!ucbvax!CITHEX.CALTECH.EDU!carl
From: carl@CITHEX.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: authorize question
Message-ID: <880707104511.224d@CitHex.Caltech.Edu>
Date: 7 Jul 88 17:51:34 GMT
References: <165*dahls@vax.elab.unit.uninett>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 26


 > I am writing a program that will check if a user have changed his/her password
 > from AAA to BBB and back to AAA. A lot of users do this, and it is not very
 > secure. My idea was to write a program that check if the user have changed the
 > password since last check, and if so, check if the new hashed password value
 > is in a table. The table contain a list of the last 20 (or more) hashed
 > password value, one table for each user on the system. If the new hashed
 > password is in the table, then the user must change the password again - and
 > this is my problem. The only way I found so far, is to set the bit
 > UAI$V_PWD_EXPIRED in the field UAI$_FLAGS. It works, but the result of doing
 > this is that every user that do this nasty thing (using his/her old password)
 > are running in and out of my office, and *that* was not my idea.
 > 
 > Does anyone know how to force the user to change the password next time he/she
 > log on the system? If I got this program to work and if anyone out there
 > would like a copy of it, I will send it to the list.

By comparing the UAF records for an account before and after using AUTHORIZE
to set the account /PWDEXP, I've found that setting it /PWDEXP causes the
longword at offset %x17C in the record to be set to %xFFFFFFFF.  I THINK
this is the high longword of the UAI$_PWD_DATE field.  Note than when an
account is set /PWDEXP this shows up in AUTHORIZE as 
	Pwdchange:  (pre-expired)
(that's why I think this is the high-order longword in UAI$_PWD_DATE).

Hope this helps.