Changes That Occur with QPWDLVL 2 or 3 – Moving to a Higher Password Level

Setting changes to QPWDLVL requires an IPL. Here are the changes you’ll see after the IPL to level 2 or 3 from 0 or 1.

• The password field on the sign-on screen now accommodates a password of up to 128 characters. See Figure 4.1. If you’ve modified the sign-on display that ships with the system, you’ll now have to modify the DDS (the display specifications) that includes the 128-character password field. See chapter 6 in the IBM i Security Reference manual for instructions.

Figure 4.1: The sign-on display after IPLing to QPWDLVL 2 or 3. Notice the increased length of the Password field.

• Prompts for the CRTUSRPRF and CHGUSRPRF commands are changed to allow input of up to 128 characters for the User password parameter. See Figure 4.2.

Figure 4.2: At QPWDLVL 2 or 3, the User password parameter in both the Create and Change User Profile commands is 128 characters long.

Before I discuss the considerations you’ll want to make prior to moving to password level 2 or 3, I need to explain the passwords that are stored at each password level (again, not literally!). Understanding this will help ensure a successful move to a higher level.

At password levels 0 and 1, passwords are stored encrypted in two formats—one where the password is all uppercase and one where the password is all lowercase. (As I’ve discussed earlier, until IBM i 7.5, password level 0 had an additional format—a weakly encrypted password used to connect to the NetServer via old clients.) When the system moves to 2 or 3 and a password is provided for authentication on either a sign-on display or a connection such as FTP or ODBC, passwords are no longer “folded” to be all uppercase or lowercase. At levels 2 and 3, whatever is provided for the password—mixed case or single case—is what the system is going to use for authentication. See Table 4.1 for more details.

After the system moves to password level 2 or 3 but before the user changes their password, what continues to be stored is the all-lowercase and all-uppercase versions of the password. Either the all-lowercase or the all-uppercase password can be used for authentication. Once the password has been changed, the mixed-case password is stored, and that’s what will be used for authentication. Note that at password level 2, the all-uppercase and all-lowercase passwords continue to be generated if the password adheres to the limits of password level 0 or 1 (maximum length 10, only special characters of #, @, $, and _, etc.).

Why should you care about this or understand how this works? You’ll need to know this to understand how to guide your users after the IPL to the higher password level and to know what to look for to make sure all your connections (such as ODBC and FTP) will work after moving to the higher password level.

Table 4.1: This table shows the formats of passwords stored at each of the password levels prior to IBM i 7.5.

Here are some considerations you’ll want to make along with what has the potential to break:

• End users: By far, the biggest issue you’ll encounter with moving to a higher password level is going to be with your end users. That’s because many users use the same password throughout the network and most networks require mixed-case passwords. So even though IBM i is running at a level that doesn’t recognize mixed-case passwords, the users enter their password in mixed-case, thinking it does. (Can’t blame them really. How would they know that the system is actually taking what they enter and folding it to be all lowercase or all uppercase and using that to determine whether they can sign on? They simply enter their password and it works!)

The key to success with your end users is education. Prior to IPLing, you must educate them—likely with multiple emails, Teams or Slack notifications, or whatever communications vehicles you have—to get through to them that the first time they sign on to the system after this specific system outage, they must use all lowercase or all uppercase (choose one format to avoid even more confusion) when they sign in to IBM i. Then, require the users to change their passwords so that the system recognizes a mixed-case password. By doing that, the point of confusion will be the first sign-on after the IPL. After they change their password, life will go back to normal.

You’ve probably already figured out that this will affect all users at the same time. Unfortunately, there’s no way to roll this out in a staged fashion. And yes, this is going to be one hellish day for you and your help desk (you’ll likely owe them treats after this). But again, the more you can educate/warn your users, the easier the days after this IPL will be.

Note that the system does not require the users’ passwords to be changed when you IPL to a higher password level. Requiring a password change takes a conscious choice (and action) on your part.

• If you have any utilities that reset a user’s password (perhaps used by your help desk, for example), you’ll want to modify those to allow for the longer password. This is especially true if you choose to also change your password composition rules at the same time—for example, switching to use QPWDRULES and adding the rule *ALLCRTCHG. This means that new passwords—even when specified in CHGUSRPRF—must follow all password composition rules.
• Connections: In general, all connections should work when the hard-coded password is not currently mixed case. By this I mean connections that are made from another server to your IBM i using ODBC, JDBC, DDM, FTP, etc. These connections are typically established with a script that contains a hard-coded password for the profile being used to connect to IBM i. These connections will work unless the password currently being used is hard-coded to be in mixed case. As Table 4.1 showed, even after moving to QPWDLVL 2 or 3, the all-lowercase and all-uppercase passwords will be stored until the password is changed. What I recommend you do is find the connections (e.g., FTP, ODBC, SSH, etc.) being made to IBM i and verify that the password used is hard-coded to be either all lowercase or all uppercase. Doing that will ensure the initial connection after IPLing to the higher password level will be successful. Once you’ve IPLed the system, then change the hard-coded password in the script as well as the password on IBM i and take advantage of the ability to specify a more complex (that is, stronger) password for these connections.
• Replication software: If you have replication software in place and you can’t move both systems to a higher password level at the same time, you’ll want to make sure that you move to the higher password level on the target system before you move the source system to eliminate the possibility of creating a password on one system that isn’t valid on the other.
• This same premise also applies to software that specifically replicates passwords around your network. These products are sometimes called single sign-on products, but what they’re actually doing is replicating passwords. Again, you’ll want to make sure to upgrade the target systems first to ensure that the initial password created will be accepted on all target systems. For example, if the originating system requires a password of 14 characters but the target system hasn’t been moved to password level 2 or 3 yet, attempting to replicate the password will fail.

Note that if you have used the QSYRUPWD and QSYSUPWD APIs to securely replicate passwords between systems, the format of what’s returned has changed in IBM i 7.5 and you will have to take additional steps if you need to move the password to a system running a pre-7.5 version. See the IBM i 7.5 API documentation in the IBM Information Center for details.