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.