× 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.



Dave, there seems to be allot of information on how to go abou t doing
this, did you move from 0 to 2 then??

Considerations for changing QPWDLVL from 0 or 1 to 2

Password level 2 introduces the use of case-sensitive passwords up to 128
characters in length (also called passphrases) and provides the maximum
ability to revert back to QPWDLVL 0 or 1.

Regardless of the password level of the system, password level 2 and 3
passwords are created whenever a password is changed or a user signs on to
the system. Having a level 2 and 3 password created while the system is
still at password level 0 or 1 helps prepare for the change to password
level 2 or 3.
Before changing QPWDLVL to 2, the system administrator should use the
PRTUSRPRF TYPE(*PWDLVL) command to locate all of the user profiles that do
not have a password that is usable at password level 2. Depending on the
profiles located, the administrator can use one of the following mechanisms
to have a password level 2 and 3 password added to the profiles.
Change the password for the user profile using the CHGUSRPRF or CHGPWD CL
command or the QSYCHGPW API. This will cause the system to change the
password that is usable at password levels 0 and 1; and the system also
creates two equivalent case-sensitive passwords that are usable at password
levels 2 and 3. An all-uppercase and all-lowercase version of the password
is created for use at password level 2 or 3.

For example, changing the password to C4D2RB4Y results in the system
generating C4D2RB4Y and c4d2rb4y password level 2 passwords.
Sign on to the system through a mechanism that presents the password in
clear text (does not use password substitution). If the password is valid
and the user profile does not have a password that is usable at password
levels 2 and 3, the system creates two equivalent case-sensitive passwords
that are usable at password levels 2 and 3. An all-uppercase and
all-lowercase version of the password is created for use at password level
2 or 3.

The absence of a password that is usable at password level 2 or 3 can be a
problem whenever the user profile also does not have a password that is
usable at password levels 0 and 1 or when the user tries to sign on through
a product that uses password substitution. In these cases, the user will
not be able to sign on when the password level is changed to 2.
If a user profile meets the following description, the system validates the
user against the password level 0 password and creates two password level 2
passwords (as described above) for the user profile.
The user profile does not have a password that is usable at password levels
2 and 3.
The user profile does have a password that is usable at password levels 0
and 1.
The user signs on through a product that sends clear text passwords.
Subsequent signons will be validated against the password level 2 passwords.

Any client that uses password substitution will not work correctly at
QPWDLVL 2 if the client hasn't been updated to use the new password
(passphrase) substitution scheme. The administrator should check whether a
client which hasn't been updated to the new password substitution scheme is
required.
The clients that use password substitution include:
TELNET
System i® Access
System i Host Servers
QFileSrv.400
System i NetServer Print support
DDM
DRDA®
SNA LU6.2

It is highly recommended that the security data be saved before changing to
QPWDLVL 2. This can help make the transition back to QPWDLVL 0 or 1 easier
if that becomes necessary.

Avoid changing password system values, such as QPWDMINLEN, QPWDMAXLEN, and
QPWDRULES, until after you have tested QPWDLVL 2. This makes it easier to
transition back to QPWDLVL 1 or 0 if necessary. However, the QPWDVLDPGM
system value must specify either *REGFAC or *NONE before the system allows
QPWDLVL to be changed to 2. Therefore, if you use a password validation
program, you might want to write a new one that can be registered for the
QIBM_QSY_VLD_PASSWRD exit point by using the ADDEXITPGM command.

NetServer passwords are still supported at QPWDLVL 2, so any
function/service that requires a NetServer password should still function
correctly.
After you are comfortable with running the system at QPWDLVL 2, you can
change the password system values to use longer passwords. However, you
need to be aware that longer passwords have these effects:
If passwords greater than 10 characters are specified, the password level 0
and 1 password is cleared. This user profile will not be able to sign on if
the system is returned to password level 0 or 1.
If passwords contain special characters or do not follow the composition
rules for simple object names (excluding case sensitivity), the password
level 0 and 1 password is cleared.
If passwords greater than 14 characters are specified, the NetServer
password for the user profile is cleared.
The password system values only apply to the new password level 2 value and
do not apply to the system-generated password level 0 and 1 password or
NetServer password values (if generated).

On Fri, Mar 30, 2012 at 12:19 PM, Boling, David E. <
David.Boling@xxxxxxxxxxxxxxxxx> wrote:

I've been having a weird error for some users calling CHKPWD from a CLP
after we changed to LVL 2 for PWDLVL. Some users work fine for example
with all lower case and #'s (didn't try mixed case with them). Another
user fails unless the pwd is set to all caps. The user that fails
unless all caps was *YES for lvl 0 or 1 and lvl 2 or 3 before the change
just like most of the other users.



I'm wondering could it be because of the CHKPWD cmd needing a ptf (the
system and I assume the cmd is at 5.4) or something of that nature. I
don't have access to the CL code, but I know from the job log that it
getting hung on the CHKPWD cmd. I think the way that the cmd works is
that it encrypts the supplied pwd and checks it against the already
encrypted as400 pwd and then just returns a 0 or 1 so I can't see that
the CLP could be affecting it.



Any clues? Thanks





David Boling, MBA, CGCIO

Rowan County Information Systems Department

130 W Innes Street

Salisbury, NC 28144

704-216-8114 (Voice)

704-216-8126 (Fax)



--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.