Automatically set PWD_EXPIRED Flag.

[Kumar_Sanjay]

Username: JAIKUMAR Owner: USER GP
Account: USER UIC: [4110,5] ([ab_home])
CLI: DCL Tables: DCLTABLES
Default: PD_DISK1:[LOGIN]
LGICMD: LOGIN.COM
Flags: DisCtlY DefCLI Restricted Captive
Primary days: Mon Tue Wed Thu Fri
Secondary days: Sat Sun
Primary 000000000011111111112222 Secondary 000000000011111111112222
Day Hours 012345678901234567890123 Day Hours 012345678901234567890123
Network: ##### Full access ###### ##### Full access ######
Batch: ##### Full access ###### ##### Full access ######
Local: ##### Full access ###### ##### Full access ######
Dialup: ----- No access ------ ----- No access ------
Remote: ##### Full access ###### ##### Full access ######
Expiration: (none) Pwdminimum: 6 Login Fails: 0
Pwdlifetime: 30 00:00 Pwdchange: 5-SEP-2007 09:11
Last Login: 23-SEP-2007 17:45 (interactive), 27-SEP-2007 07:27 (non-interactive)
Maxjobs: 0 Fillm: 1500 Bytlm: 3000000
Maxacctjobs: 0 Shrfillm: 1000 Pbytlm: 0
Maxdetach: 0 BIOlm: 4500 JTquota: 8000
Prclm: 240 DIOlm: 4500 WSdef: 8192
Prio: 4 ASTlm: 1024 WSquo: 16284
Queprio: 0 TQElm: 400 WSextent: 30000
CPU: (none) Enqlm: 5000 Pgflquo: 7000000
Authorized Privileges:
GROUP GRPNAM NETMBX TMPMBX
Default Privileges:
GROUP GRPNAM NETMBX TMPMBX
Identifier Value Attributes
Identifiers held by JAIKUMAR:

Identifiers1 %X80010061 RESOURCE
Identifiers2 %X80010062
Identifiers3 %X80010063
Identifiers4 %X80010064

This is User Captive account of one of our application user how use to login as interactive also some of batch job running As non-interactive using the same ID.

After the Last Paswword Expired User complained me he is not able to login also none of batch job is running using this account. all got failed. I found that this account got automatically got PWD_EXPIRED Flag. I didn't understand how and why the flag has come to this account.


As I know...

1) If the "pwd_expired" flag has been manually set in the UAF record for an account, then subsequent interactive login attempts using this account will fail. The batch jobs that are submitted using this account will also fail.

2) If "pwdlifetime" for the account has reached and "pwd_expired" flag has not been manually set for the account, then subsequent interactive login attempts will prompt for new password. If you refuse to change the password when prompted for new password, login will not be successful, however pwd_expired flag will not be set for this account. Interactive login will be successful only after the password has been successfully changed. The batch jobs that are submitted using this account will still go through.

3) If pwdlifetime has been reached and the flag "disforce_pwd_change" has been set for that account, then the first interactive login attempt will still be successful with a warning to change the password using the "set password" command. If the password is not changed during this login session, then subsequent attempts to login to this account will result in "pwd_expired" flag to be set for that account and the login attempt will not be successful. The batch jobs that are submitted using this account will fail.


But all 3 scenario is not match with this Problem, Can anyone please help me to know.

1). How and why PWD_EXPIRED Flag had come to account.
2). What could be the possible Reason to set “PWD_Expired” flag automatically.

Thanks and Regards
Sanjay

[#2]

Hi Sanjay,

You can set the password as a permanent one using the following command:

i) RUN SYS$SYSTEM:AUTHORIZE
ii) MODIFY /PWDLIFETIME=NONE /FLAG=NODISPWDHIS /PASSWORD=
iii) EXIT

Regards,
ajaydec

[Jess Goodman]

Sanjay,

Most likey this password was changed directly using AUTHORIZE. The PWD_EXPIRED is automatically set when this is done.

$ MCR AUTHORIZE MODIFY name/PASSWORD=password

I believe the reasoning is that when this happens since the password was apparently not set by the user, then the user should pick his own password when they next login.

Personally I find it annoying, but the easy work-around is just to add /NOPWDEXPIRE to the end of the above command.

[Jess Goodman]

I should have added that if you have Auditing enabled for the Authorization class you can check what was done to his account with:

$ ANALYZE/AUDIT/EVENT=SYSUAF

ANALYZE used to have /SELECT=UAF_MODIFY=user as an option but I see it is no longer documented, at least in HELP, which is just as well because IIRC correctly it didn't work very reliably.

[DSM_1]

I would like to mention a trap for the inexperienced (which I class myself as). I once went to set a password in Authorize and used the qualifier /NOPASSWORDEXPIRE. To my subconscious, this was no different to /NOPWDEXP. However to Authorize it meant "no password required". Whoops!

[Jan van den Ende]

@ DSM:

>>>
and used the qualifier /NOPASSWORDEXPIRE. To my subconscious, this was no different to /NOPWDEXP
<<<

Yes, command (and qualifier) abbreviation has many advantages, but /NOPASS (with any trailing alphanumerics) just means what it means.
That is why there have to be DIFFERENT (1st 4 char) spellings for passwordfunctionalities: /PASS for requirung a password; and /PWDLength, PWDExpire, PWDHistory etc for ATTRIBURES OF the password.


hth

Proost.

Have one on me.

jpe

[Jon Pinkley]

UAF> modify /flag=PWD_EXPIRED

and

UAF> modify /pwdexpired

are two very different things that happen to have similar names.

Sanjay is explicitly talking about the first one.

The only ways I am aware of the PWD_EXPIRED flag being set (with programs that are part of stock VMS) is via the first UAF command above, or if the DISFORCE_PWD_CHANGE flag is set; the pwdlifetime has expired and the user logs in interactively (I only tested with BATCH and telnet, I didn't try SSH, FTP, etc.). The flag is set by LOGINOUT before the user gains control and even has a chance to change the password.

And as Sanjay says in point #1, once the flag is set, all logins will fail until the flag is cleared, either by the user changing the password via

$ set password

or a privileged user using the AUTHORIZE command

UAF> modify /flag=NOPWD_EXPIRED

In my opinion, the DISFORCE_PWD_CHANGE flag should never be set, as it can lead to intermittent batch job failures, just as a result of an interactive user login.

The default behavior is to not allow the user to log in interactively without changing the password within the initial LOGINOUT execution, so the PWD_EXPIRED flag never gets set, and there is no possibility of affecting non-interactive logins.

In Sanjay's case he shows that the DISFORCE_PWD_CHANGE flag was not set.

If that is true, then it leaves only two possibilities in my opinion:

1. It was manually set by a privileged user using the AUTHORIZE (UAF) program.

2. Some third party application is setting the flag, perhaps to meet an auditor's interpretation of SOX or other security requirements.

As mentioned in Jess's note dated Sep 27, 2007 15:30:04 GMT, the answer about what changed the flag is available if AUDITING is properly set up. Any site that would have software to automatically disable user accounts basked on lack of changing the password, should also have AUDITING enabled for security related events.

Jon

[Hoff]

>>>How and why PWD_EXPIRED Flag had come to account.<<<

Check your system auditing logs for the history of any modifications made to the username.

If system auditing is not enabled, you'll want to enable it.

Assuming authorization auditing data is available, this might or will entail re-loading auditing data from the backup archives; you'll be able to tell for certain what happened here. (Some sites keep an online or nearline archive just for this data.)

This restoration and search is a task I'd tend to assume is not going to happen here, as there can be months or years of data to search. Yes, the question here is certainly interesting, but probably not :that: interesting. (Why to I assume this? Consider the outcome once you know the answer to the "how did this happen?" question. Is knowing that answer going to result in any change or any difference, or is the outcome of the research project here still going to be the same. Is the effort involved in reloading and analyzing the security logs going to be worth the resulting knowledge? Or is the result going to be: "Yep. Fix it. Set the proper flags on server accounts, and/or set up a default account used as a copy source for server account(s). Move on.)

Cost-benefit-value, after all... You probably :have: the answer in your logs here. Is figuring it out worth it?

Regardless, do consider enabling authorization security auditing, if it is not already enabled.

[kumarasamy]

Sanjay!

Can you check system Date in that particular account or any time assignment in login.com file in that particular user?

When the user login the time is compared with system time,and if system time is older than login time naturally accounts password gets locked..
This is one of the reasons somtimes misguide us.
bye
kumar

[Thomas Ritter]

Default attributes for any userid are determined by the VMS account DEFAULT.

Perform a
$ mcr authorize show default

These are the default values in the absence of any other value.
Our our test system we have

Username: DEFAULT Owner:
Account: UIC: [200,200] ([200,200])
CLI: DCL Tables: DCLTABLES
Default: [USER]
LGICMD:
Flags: DisUser
Primary days: Mon Tue Wed Thu Fri
Secondary days: Sat Sun
Primary 000000000011111111112222 Secondary 000000000011111111112222
Day Hours 012345678901234567890123 Day Hours 012345678901234567890123
Network: ----- No access ------ ----- No access ------
Batch: ##### Full access ###### ##### Full access ######
Local: ##### Full access ###### ##### Full access ######
Dialup: ----- No access ------ ----- No access ------
Remote: ##### Full access ###### ##### Full access ######
Expiration: (none) Pwdminimum: 8 Login Fails: 0
Pwdlifetime: 30 00:00 Pwdchange: (pre-expired)
Last Login: (none) (interactive), (none) (non-interactive)
Maxjobs: 20 Fillm: 500 Bytlm: 100000
Maxacctjobs: 0 Shrfillm: 0 Pbytlm: 0
Maxdetach: 0 BIOlm: 150 JTquota: 4096
Prclm: 20 DIOlm: 150 WSdef: 40960
Prio: 4 ASTlm: 250 WSquo: 61440
Queprio: 4 TQElm: 10 WSextent: 81920
CPU: (none) Enqlm: 7000 Pgflquo: 250000
Authorized Privileges:
NETMBX TMPMBX
Default Privileges:
NETMBX TMPMBX

Our default pwdlifetime is 30 days.