- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: disuser if password unused
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-22-2007 02:50 AM
08-22-2007 02:50 AM
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-22-2007 03:06 AM
08-22-2007 03:06 AM
SolutionYou 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-22-2007 04:24 AM
08-22-2007 04:24 AM
Re: disuser if password unused
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
Hope this helps some,
Hein van den Heuvel (at gmail dot com)
HvdH Performance Consulting
$! uaf_pwd_reset_age.com [
$! 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-22-2007 04:57 AM
08-22-2007 04:57 AM
Re: disuser if password unused
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-22-2007 08:25 AM
08-22-2007 08:25 AM
Re: disuser if password unused
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-23-2007 12:48 AM
08-23-2007 12:48 AM
Re: disuser if password unused
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-23-2007 01:48 AM
08-23-2007 01:48 AM
Re: disuser if password unused
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-23-2007 02:07 AM
08-23-2007 02:07 AM
Re: disuser if password unused
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-23-2007 04:29 AM
08-23-2007 04:29 AM
Re: disuser if password unused
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-23-2007 07:59 PM
08-23-2007 07:59 PM
Re: disuser if password unused
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-24-2007 12:34 AM
08-24-2007 12:34 AM
Re: disuser if password unused
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-24-2007 12:42 AM
08-24-2007 12:42 AM
Re: disuser if password unused
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-24-2007 01:04 AM
08-24-2007 01:04 AM
Re: disuser if password unused
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-24-2007 02:26 PM
08-24-2007 02:26 PM
Re: disuser if password unused
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-29-2007 02:26 AM
08-29-2007 02:26 AM
Re: disuser if password unused
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