One can run
CHGUSRPRF USRPRF(...) PASSWORD(different)
CHGUSRPRF USRPRF(...) PASSWORD(original)
And the date password last changed will change. And a new date that the password will expire will display.
My problem was that when I thought I was running
CHGUSRPRF USRPRF(...) PASSWORD(different)
It wasn't a different password. Therefore, even while CHGUSRPRF reported that it ran successfully the password was unchanged and still listed as expired.
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Musselman, Paul
Sent: Friday, January 25, 2019 1:47 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: RE: 7.3: CHGUSRPRF PASSWORD(...)
Wouldn't the unchanged 'last changed' date still trip the 'password expired,' based on the password expiration interval?
I'm pretty sure that once the 'password expired' (or nearly expired) flag is set, you MUST change your password, and even CHGUSRPRF won't fix it. ):
Paul E Musselman
PaulMmn@xxxxxxxxxxxxx
.
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Rob Berendt
Sent: Friday, January 25, 2019 10:59 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: RE: 7.3: CHGUSRPRF PASSWORD(...)
DSPUSRPRF ROB
Date password last changed . . . . . . . . : 11/13/18 11:25:28
CHGUSRPRF USRPRF(ROB) PASSWORD()
User profile ROB changed.
I used my current password
DSPUSRPRF ROB
Date password last changed . . . . . . . . : 11/13/18 11:25:28
Time sent . . . . . . : 10:46:14
DSPJRN JRN(QAUDJRN) RCVRNG(*CURCHAIN)
FROMTIME(012519 104600) TOTIME(012519 104700) No CP entry.
I guess that answers my question right there. CHGUSRPRF checks the before/after and doesn't update the password last changed date if you don't really change the password
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Charles Wilt
Sent: Friday, January 25, 2019 10:40 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: 7.3: CHGUSRPRF PASSWORD(...)
My understanding is that CHGUSRPRF doesn't go through any of the password checks..
CHGPWD is what the application should be using
Charles
On Fri, Jan 25, 2019 at 8:35 AM Rob Berendt <rob@xxxxxxxxx> wrote:
Let's say you have a user. You know the password. You know it's expired.
If you do a CHGUSRPRF USER(...) PASSWORD(...same password...) Will you
get the CPC2205 - User profile &1 changed.
And still see the old "Date password last changed"?
Because we have an application which reported that it worked fine. It
uses CHGUSRPRF.
I even did a DSPJRN and could see all the entries EXCEPT the actual CP
entry. CP = Change Profile.
My hypothesis is that CHGUSRPRF checks before/after and doesn't really
do the change.
Once we changed his password to something else and then changed his
password it did update his password changed date.
Not that we're in the habit of gaming the system - I think we just got
hoodwinked by someone into keeping his old password.
I think I'm right.
CHGUSRPRF USRPRF(<redacted>) PASSWORD(<redacted>)
User profile <redacted> changed.
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com
midrange.com
