Re: password reset required after migration to power 10 (v7r3 to v7r5)

Great response from IBM (below).

Meanwhile.....

For now we will set profiles to *NOMAX for tomorrow.

After that we will reset 5 profiles every few days to 90 days to force them to change their passwords so after awhile, without overwhelming our support desk, we will get to the place where we are on the 90 day rotation.

After we get to where we want to be we can change the system value to 90 and align all the profiles to 90.

Jerry

alie

Natalie Campbell (IBM)

Natalie Campbell (IBM)
Mar 16, 2025, 17:42

Hi Jerry,

I am from the Security team and was asked to look at your case.

Looking at the old system, the user profile you sent in shows 'Password expiration interval' set to *SYSVAL and then you say the QPWDEXPITV is set to *NOMAX. So, on the old system, passwords never expired. That is why you do not have a 'Days before password expires' when looking at the profiles, because profiles do not have a password expiration.

So looking at what you last sent in, you showed this:

Old system:

*Date password last changed . . . . . . . . : 02/12/11 09:29:08 *

Password is *NONE . . . . . . . . . . . . : *NO

*Password expiration interval . . . . . . . : *SYSVAL *

New system:

*Date password last changed . . . . . . . . : 03/15/25 12:29:02 *

Password is *NONE . . . . . . . . . . . . : *NO

*Password expiration interval . . . . . . . : 90 *

Date password expires . . . . . . . . . : 06/13/25

So, again, on the old system, the profiles passwords never expired. But, on the new system, it appears someone has set password expiration interval in the user profile to 90. So for the profile on the old system, the last time their password was changed was in 2011, so on the new system, if someone went in to the user profile and set the password expiration to 90, that profile will immediate expire because the last time that password was changed was in 2011!

I can't tell you who went and set the password expiration interval to 90 on every profile without checking to see if you have auditing set up. But, the only way to fix it so that no profiles don't expire is to go to each user profile and change that 'Password expiration interval' to either *NOMAX or point it to *SYSVAL which is *NOMAX. Then the users won't have expired passwords tomorrow.

But you also say the client wants the passwords to expire every 90 days. If that is the case, as soon as you change the profile back to 90, their passwords are all going to expire as it appears these users have never changed their password in many years. There is no way around this. The 90 days is calculated from the 'Date password last changed' field. So, every profile that is set to 90, if the 'Date password last changed' is 90 days in the past, then that profile will expire immediately. So, if the client wants the users to change their passwords every 90 days, they will all have to change their passwords when they sign on tomorrow if you keep the 90 set for 'Password expiration interval' in each user profile.

For a user that hasn't signed on yet, if you do a DSPUSRPRF for that user, is the 'Password expiration interval' set to 90? If you look at the 'Date password last changed', my guess is that date is way more than 90 days ago. So that profile will have to change their password tomorrow when it signs on. So the client needs to decide whether they want users to change their passwords every 90 days or not. Right now, it sounds like they do, and if that is the case, then every user will be changing their password tomorrow. But then you say they don't want the users to have to change their password tomorrow. So I'm not sure which you want.

So, if they have decided they don't want their users to have to change their passwords tomorrow, you will need to go to each user profile and change the 'Password expiration interval' from 90 to either *NOMAX or *SYSVAL, as it is set to *NOMAX. Then the users will not have to change their password tomorrow. But, if they want them to have to change their passwords every 90 days, the minute you set the 90 days in the profiles, those profiles will all immediately expire as most likely the 'Date password last changed' is many years ago.

I hope that makes sense.

Regards,

Natalie



On 3/16/2025 12:16 PM, Jim Franz wrote:

could be most users created  when value was 90... changing that sysval does not affect existing profiles unless value in profile is *SYSVAL.
I was expecting the set expired by command to be *YES which would give  you the behavior . of at signon, being prompted to change.

Jim


On Sun, Mar 16, 2025 at 2:57 PM Jerry Draper <genbox@xxxxxxxxxxxxx> wrote:

most users are set like this:

Password             Password Set  Password
Expiration Interval  Expired       is *NONE

            90            *NO         *NO

However sys val QPWDEXPITV is set on both systems to

Interval in days . . . :   *NOMAX     *NOMAX, 1-366

Seems like old system was 90; but now *NOMAX?




On 3/16/2025 11:43 AM, Jim Franz wrote:
> Jerry,
>
> Check one of the normal users DSPUSRPRF or run cmd to an outfile
*basic
>
> Password is *NONE  . . . . . . . . . . . . :   *NO
> Password expiration interval . . . . . . . :   *SYSVAL
>   Password set expired by command  . . . . . :   *NO  ****** IS
THIS *YES
> ???
>
> if it is - you can create a clle to read the outfile and change
that value
> back to *NO   Just be carefull there may be some that should be
*YES , and
> do not mess with "Q" profiles . Will have to run clle with a
profile with
> auth to update profiles. Any service accounts for products - are
these also
> *YES?
> You can then, if you want profiles to be reset, can set it back in a
> controlled, prepared time.
>
> Jim Franz
>
>
> On Sun, Mar 16, 2025 at 2:30 PM Jim Oberholtzer
<midrangel@xxxxxxxxxxxxxxxxx>
> wrote:
>
>> Likely since 7.5 has different defaults.
>>
>> That will force the PW change.
>>
>>
>> Jim Oberholtzer
>> Agile Technology Architects
>>
>>> On Mar 16, 2025, at 12:53 PM, Steve McKay <samckay1@xxxxxxxxx>
wrote:
>>>
>>> Is say al QPWDCHGITV different bettthe 2 systems?
>>>
>>> Is system date correct?
>>>
>>>
>>> Thanks,
>>>
>>> Steve McKay
>>> 205-585-8424
>>> samckay1@xxxxxxxxx
>>>
>>>
>>>> On Sun, Mar 16, 2025 at 12:39 PM Jerry Draper
<midrangel@xxxxxxxxxxxxx>
>>>> wrote:
>>>>
>>>> We migrated from a power 7 to a power 10 and from V7R3 to V7R5.
>>>>
>>>> We did a savsecdta on the Pwr7 and a rstusrprf to the Pwr10
>>>>
>>>> When users sign on they are requested to change their passwords.
>>>>
>>>> This will cause huge logistical issues for our support desk.
>>>>
>>>> What changed and how can we reset it so that no password reset is
>> required?
>>>> Thx,
>>>>
>>>> Jerry
>>>>
>>>> --
>>>> 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@xxxxxxxxxxxxxxxxxxxx for any subscription
>> related
>>>> questions.
>>>>
>>>>
>>> --
>>> 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@xxxxxxxxxxxxxxxxxxxx for any subscription
>> related questions.
>> --
>> 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@xxxxxxxxxxxxxxxxxxxx for any
subscription related
>> questions.
>>
>>