× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi Rob

We just went through this project on all of our IBMi LPARS. We switch to a
password level of 3 (from 0).
In general it went pretty smoothly.

We did the following:
(1) Ran the PRTUSRPRF Report (on all lpars) and did not find any users
with password issues at level 2/3.
(2) We changed it on the development system first and tested.
(3) Coordinated all the changes to all the remaining LPARs over a
scheduled maintenance week-end
(this is important as if you change some systems, one at a time then
the communication
between systems can be hindered if one system is at level 0 and
others systems are at level 2/3)
(4) We decided it would be best if users changed their passwords all at
once to get used to upper/lower case
passwords. We changed all the passwords (except the q* passwords) to
expire and force a password change.
We did not want death by a 1000 tickets to our help desk over the
next 4 weeks as user passwords normally expire
Help desk tickets skyrocketed for 2-3 days with password issues but
settled down quickly after that.

While not a requirement for changing password levels we rewrote the
password composition
rules to use the QPWDRULES system value. We set them as follows:
*MAXLEN10
*MINLEN8
*CHRLMTAJC
*MIXCASE1
*DGTMIN1
*DGTMAX6
*LMTPRFNAME
*REQANY3

We ran in to one major system issue when chaing to a level of 3. We had an
old imaging application (Content manger for IBMi)
that needed a ini setting on the client to support mixed case passwords.

Other than that it was pretty straight forward.

If you have any older client PC applications that authenticate with the
IBMi that would be the first place I would check/test.

Jim


Jim W Grant
Senior VP, Chief Information Officer
Web: www.pdpgroupinc.com




From: Rob Berendt <rob@xxxxxxxxx>
To: midrange-l@xxxxxxxxxxxx
Date: 04/27/2016 10:27 AM
Subject: Considerations for changing QPWDLVL from 0 or 1 to 2
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



I've read this
Considerations for changing QPWDLVL from 0 or 1 to 2
http://www.ibm.com/support/knowledgecenter/ssw_ibm_i_73/rzarl/rzarlconsdchg2.htm?lang=en


They list some applications that work well with level 2.
I'd like to see some known gotchas and workarounds (if any).

Reasons why I'm thinking of going to level 2:
- Allow passwords longer than 10 characters. We still may limit them to
something reasonable.
- Allow mixed case and upper case passwords in NetServer without that
disabling their NetServer access.

If you change this you have to IPL before it takes effect.
Is it possible to modify the signon screen to just make the password field

our chosen maximum instead of the full 128 characters?
I've modified sign on screens in the past to put things like "our next
scheduled downtime is..." but I was wondering if chopping of field entry
size throws a wrinkle into process.

I ran the
PRTUSRPRF TYPE(*PWDLVL)
and only found two "user" profiles that was ok at 0 or 1 but not at 2.
There were two Q* "ibm" profiles which it has issues with.
A bunch that weren't ok across the board but I assume these are the people

with password = *NONE. Spot checking agrees.


Rob Berendt

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.