Carol discusses things that are a bit puzzling when it comes to IBM i security settings.

I wish I could link to a video of my 20-month-old niece putting her chubby little index finger on her chin, cocking her head slightly, and saying “Hmm.” So cute but so darn accurate for this article. Here are some configuration settings examples that have seriously made me say, “Hmm…what was the administrator thinking when they did this? This makes no sense.”

Misconfiguration occurs, I believe, due to ignorance or lack of understanding about how things really work. So I thought I’d share some of these settings incidents that puzzled me in hopes that, if you’ve also made these mistakes, you can gain understanding and correct the misconfiguration.

Password Expiration Interval

The password expiration interval is controlled first at the system-value level and second at the user profile. Whatever is specified in the user profile overrides the value specified in the QPWDEXPITV system value. What I find puzzling is when the system value is set to *NOMAX, meaning that the password never expires, and then overridden in all user profiles with the actual expiration interval—typically, 90 (days).

While, in theory, this works, there are risks associated when creating a profile regularly used for sign-on (versus a service account) with a non-expiring password. In addition, any auditor who knows anything about IBM i knows to examine the system-value settings. They will quickly identify that the setting for the QPWDEXPITV system value means that no profiles have to change their password. Now you’re forced to take time to explain to your auditor that no, in reality, profiles do have to change their password. Why put yourself into this position? I recommend that the system value be set to the organization’s password expiration interval and then the exceptions set in the user profile. And while I was already planning on including this example anyway, this exact scenario was described to me by one of the clients I worked with this past week!

Modifying User Profile Authorities

When a profile is created, the *PUBLIC authority is set to *EXCLUDE and the profile is granted authority to itself—*CHANGE and *OBJMGT to be exact. In addition, if the profile is a member of a group, the member is granted *OBJOPR, *OBJMGT, *READ, *ADD, *UPD, *DLT to the group profile. These authorities should be left as is and not modified. Each is required for normal operations. Several scenarios surrounding these settings make me say “Hmm.”

First, I’ve seen organizations remove the profile’s authority to itself. Now I said that these authorities are required for normal operations. If you remove a profile’s authority to itself, the profile cannot be used for signon. So how is their configuration working? The profile is owned by the profile’s group; therefore, it has sufficient authority through itself (through its group.) But why? Why change the authority? I’ve never been able to come up with a legitimate reason for doing this, and it can definitely be problematic. For example, when the user’s group changes but the ownership of the profile doesn’t, the profile—suddenly—can’t be used for signon.

Another profile authority modification I see is granting a member *EXECUTE authority to the user’s group profile in addition to the authority already granted. Granting *EXECUTE means that the member has *USE authority to their group and therefore can submit jobs and run as their group rather than themselves. This practice makes you lose accountability. That is, you cannot determine who is actually performing a task. Again, it’s not required by the system and is obviously problematic; therefore, it should be avoided.

Granting Profiles with *ALLOBJ Private Authorities

Two scenarios under this category make me say “Hmm.”

The first scenario is caused, I believe, because people don’t understand the order in which IBM i checks authority. What I often see is a private authority of *EXCLUDE granted to a profile that has *ALLOBJ. This is a waste of time because, when the system checks authority, the first thing that’s checked is to see if the user has *ALLOBJ. If they do, access is granted and the algorithm ends. Any private authorities the user or their group(s) has is never checked.

The other scenario that really makes me go “Hmm” is when a profile with *ALLOBJ is granted a private authority of *ALL, especially when the profile is QSECOFR. Why anyone would ever think that QSECOFR needs any additional authority is truly beyond me. Again, it’s a waste of time to grant these authorities! Also, these private authorities only slow down your Save Security Data (SAVSECDTA) process unnecessarily.

Authorities to Authorization Lists

Two scenarios with authorization lists also make me say “Hmm.”

The first authorization list scenario is when an object is secured with an authorization list, but the *PUBLIC authority of that object has not been pointed to the list. In other words, the *PUBLIC authority of the object has not been set to *AUTL. It’s not as confusing if the *PUBLIC authority of the object and the list is the same. But when it’s different, I have to wonder which one the administrator meant to be in effect. In this case, the setting on the object will be the *PUBLIC authority used. To avoid confusion, I recommend that, when securing an object with an authorization list, you set the *PUBLIC authority of the object to be *AUTL so that the *PUBLIC authority comes from the authorization list.

The second scenario when working with authorization lists is when the *PUBLIC authority of the list is something other than *EXCLUDE—say, *USE or *CHANGE—and individuals or groups are granted *EXCLUDE to the list. If there are users who shouldn’t have access to the objects secured by the list, why isn’t the list set to *PUBLIC *EXCLUDE and users or groups granted access? When I see this scenario, the authorities always seem backward to me. Why would you want to put yourself in the position of having to remember to exclude certain users/groups if not all profiles on the system should have access to these objects?

Profiles Set to PASSWORD(*NONE)

What makes me say “Hmm” when a profile doesn’t have a password (that is, the password is set to *NONE) is when the password expiration interval is set to *NOMAX. What you do by using this configuration is unnecessarily cause the profile to show up on the list of profiles with non-expiring passwords. And now you have to explain to your auditors that there’s actually no danger because the profile doesn’t have a password. Since the profile doesn’t have a password, the expiration interval is never examined; therefore, you should leave the password expiration interval at *SYSVAL.

Private Authorities Granted to Commands and APIs

One of the services the Professional Security Services team at HelpSystems does is perform Risk Assessments. Our Risk Assessor product is used to help us gather data reports on the authorities of several commands and APIs for which you may want to restrict access. Periodically, I’ll see an operator or developer group or an individual that’s been granted authority to every command and API that we list in this report. When I see this, it’s quite likely that they’ve been granted authority to every command and API in the library QSYS. The puzzling aspects of this scenario is why was this done and how it’s accomplished each upgrade. Why would an administrator think that operators need authority to all commands? Did a developer slyly add granting themselves authority to all commands when writing a program to run after each upgrade, perhaps to set command default that the organization changes to meet their needs? I’ve never heard a legitimate reason for this, and when it’s brought to the security administrator’s attention, the authorities are typically removed.

Summary

I hope you’ve enjoyed this discussion on these security configuration settings that are puzzling to me. If there’s a setting I mentioned that you recognize—that is, it’s configured that way on your system—I encourage you to take the time to re-work the misconfiguration.