IBM i security configuration is usually pretty straightforward, but there are a few things that, misconfigured, can produce results you don’t expect. Carol explores some of those areas of the system.

In most areas, IBM has done a decent job of making it obvious what the outcome of a particular setting will be, but some outcomes aren’t so obvious. In addition, I’ve seen administrators turn a straightforward configuration upside down and make it very difficult to understand the actual result of their configuration choice. In this article, I explain these scenarios in hopes that you will take a look at your own configurations and make sure you’re getting the outcome you think you are.

QAUDLVL and QAUDLVL2 System Values

When auditing was first added to the system back in V1R3, the number of values one could specify in the action auditing system value QAUDLVL was more than enough. But through the years, additional values were defined for action auditing and some of the original values were subsetted, allowing you to be more granular in the actions audited. With the ability to specify more values for QAUDLVL, the system value could be “filled up.” So IBM created an overflow system value called QAUDLVL2. The “bite” here is that you can’t simply start to specify values in QAUDLVL2 and expect the system to recognize them. Unless you specify *AUDLVL2 in QAUDLVL, the system will never look in QAUDLVL2. I’ve seen clients think they’re using QAUDLVL2, but they haven’t specified *AUDLVL2 in QAUDLVL. If you’re using QAUDLVL2, check QAUDLVL to make sure you’ve included *AUDLVL2.

QPWDRULES System Values

For years, I’ve been advocating the use of the QPWDRULES system value. It provides many more options for specifying password composition rules than the individual system values that define the password rules (e.g., QPWDMINLEN, QPWDMAXLEN, QPWDRQDGT, etc.) The bite with this system value is that, once you start using it, you must specify all of your rules because the system stops looking at the individual system values. I’ve seen clients specify the values *LMTPRFNAME and *ALLCRTCHG but not specify the minimum and maximum lengths. The net effect is that the next time a user changes their password, while their profile name can’t be part of the password, they can specify a password of any length, including a length of 1!

Authorization Lists

As you know, I’m a big fan of using authorization lists. They’re an easy way to specify the same authority for many objects, including the *PUBLIC authority of those objects. What I’ve seen happen is that many people fail to specify that the public authority should come from the authorization list and just assume that it does. The bite is that just because an object is secured with an authorization list doesn’t mean the *PUBLIC authority is coming from the list. To have an object’s public authority come from an authorization list, one must specify *PUBLIC(*AUTL). I’ve seen administrators get confused because they’ve set the public authority of an authorization list to *EXCLUDE but fail to point the objects’ public authority to the list and wonder why users can access the files. In most cases, it’s because the objects’ *PUBLIC authority defaulted to *CHANGE (the default value of the QCRTAUT system value) when the objects were created, providing users with the ability to both read and update the files.

QPWDEXPITV System Value and the PWDEXPITV User Profile Attribute

I have to admit that this is one of the strangest configurations I’ve ever seen, but, unfortunately, I have seen it more than once. With this configuration, the system value that determines how often a password must be changed (QPWDEXPITV) is set to *NOMAX, meaning that users’ passwords never expire (that is, never have to be changed.) Unfortunately, I see this system value set to *NOMAX way more often than one would think. But what makes this configuration so strange is that the user profile setting for password expiration is set to a reasonable value such as 90. Since the user profile attribute overrides the system value, for the profiles configured in this manner, the passwords must be changed every 90 days. While this configuration seems to accomplish the intended goal of having profiles’ passwords changed every 90 days, I find this configuration problematic on multiple levels. First, auditors are going to look at the setting for QPWDEXPITV, see it set to *NOMAX, and flag it as an issue. Then, you’re going to have to spend time convincing them that users actually do have to change their passwords. Why do you want to waste your time on that? Second, while I agree that service accounts are typically set to have a non-expiring password, why risk forgetting to override this value for all other profiles just to make sure that the next time you create a service account, it’s created with a non-expiring password? Unless you create more service accounts than traditional user profiles (which I’ve never seen happen), this makes no sense. To me, the risk of forgetting to override this setting for regular accounts is far greater than forgetting to set a service account to have a non-expiring password.

Summary

I hope everyone takes a few moments to ensure you don’t have any of the configurations that I’ve just described. You’ve taken the time to use the security features of IBM i, so I recommend you make sure you’re getting the results you intended.