Tips for Staying Sane

IBM i (OS/400, i5/OS)
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

In this crazy, topsy-turvy world we’re in, we’re finding creative ways to stay sane in our personal lives. How does this translate into our work life, specifically to IBM i security?

I don’t know about you, but during this strange time we find ourselves in, I’m doing some “interesting” things to stay sane. For one thing, I’m doing a lot of cleaning. I’ve raked parts of my yard that have never been raked in the 20 years I’ve lived in my house! And my closets have never been more organized. I’ve also dug out my sewing machine—not just to make masks but to do other projects as well. Finally, I’ve found myself cooking and baking things I’ve never attempted before. What does this have to do with IBM i security? I thought it might be fun to translate the sort of things we’re doing in our personal lives into IBM i security: cleaning, resurrecting old skills, and trying out new ones.

Clean Up! Clean Up!

Have you heard the children’s song that says “Clean up! Clean up! Everybody everywhere. Clean up! Clean up! Everybody do their share.” Now’s the time to apply that to your IBM i. I would assert that most users on the system have something that can be cleaned up: old spooled files, queries that haven’t been used in years, copies of database files made before a database change or used to test a specific change, etc. In addition, there are items administrators should be paying specific attention to:

  • Inactive user profiles: This suggestion should come as no surprise to you if you follow my articles. But now—more than ever—is the time to get rid of unused profiles. Why leave them on your system? Leaving them increases the time of your Save Security Data (SAVSECDTA), increases the time it would take if you have to recover your system, and worst, leaves targets for attackers to gain access to your system.
  • Libraries and directories belonging to users who no longer work for the organization: These are often libraries or directories holding objects created by and often still owned by former administrators or developers. These objects are often the excuse for not deleting those profiles. Now is the time to determine whether the objects are in use, delete them if they’re not, and if they are still in use, transfer the objects to be owned by a more appropriate owner, typically a group profile associated with the role of the user.
  • Old versions of vendor products: Some vendors increase security settings and logging capabilities in newer versions of their products. If the old version remains on the system and continues to be licensed, users (think developers and the utilities they use) could use the old version and potentially bypass the increased logging you’ve implemented in the newer version.
  • Data past its retention schedule: This may fall more into a DBA’s lap to ensure it’s occurring, but someone in your organization needs to ensure that data past its retention schedule is being deleted. GLBA, CCPA, and PCI DSS all require that old data be removed from the system. In addition to complying with these laws and regulations, it’s simply a good security practice to not keep around data that’s no longer required.

If something (data, a product, a user profile) is on the system, you have to consider the security implications. If it’s not in use, back it up and remove it.

Resurrecting an Old Skill

Just like I used to sew a lot of my clothes back in the day, I believe that once upon a time security administrators actually meticulously reviewed user profile attributes and access control settings on a regular basis. Now the only time that happens in some organizations is in the rush to prepare for an audit. I propose that you resurrect this skill and do some much needed review and correction of settings. The first settings I’d recommend are system values. Best practices for system values can be found in a variety of places: IBM i Security Reference chapter 2, my book IBM i Security Administration and Compliance, Third Edition, and the HelpSystems Risk Assessor output to name a few. All of these provide a discussion of the system value itself as well as the recommended (best practice) setting.

User Profiles

I recommend that (at least) the following user profile attributes be reviewed:

  • Group profile membership: This may be the most important setting to review. Often a group profile represents the role of the user. If the user has changed roles, the new role (group profile) is added to the profile, but the original one is often not removed. This leaves the user with access to data, utilities, commands, and menu options that they may no longer need access to. You can list the members of a group by running DSPUSRPRF group_name *GRPMBR.
  • Special authorities: Review the capabilities each special authority provides and then remove any special authority that gives users abilities that are outside of their job position.
  • Limited capability setting: The vast majority of profiles should be set to Limited capability LMTCPB(*YES), including service accounts. Limited capability *NO or *PARTIAL allows users to run commands from a command line as well as some FTP commands.

Access Control Settings

Even if you haven’t implemented a deny-by-default posture across your entire system, it’s likely that you have at least a handful of objects that you want to make sure have been secured. When these objects are first secured, you probably took great care and only authorized users that needed access at that time. Over time, more users have been added, but as with group profiles, it’s rare that user access is removed. Now’s the time to review these settings, making sure that all of the access is still required:

  • Users granted authorities to authorization lists
  • Authorities of *FILE objects containing Personally Identifiable Information (PII) or company confidential information
  • Authorities to directories containing PII or company confidential information

Note: Getting rid of old “stuff” before you do these reviews will probably shorten the list of items to review because some of them will no longer be on the system.

Developing a New Skill

IBM i is packed with so much technology, there are all sorts of new things we all could be learning! But if you’re interested in learning more about IBM i’s security features, here are two that I’d suggest looking into:

  • Authority Collection: New in V7R3 and enhanced in V7R4, this feature takes the guesswork out of securing your system. It does this several ways, including enabling you to find out exactly which objects a user is accessing and the authorities required, understand where a user’s authority is coming from (their group, a private authority, adopted authority, etc.) to understand why a user either can or can’t access an object, and (in V7R4) determine which users are accessing a specific object and what authorities they require.

To learn more about the Authority Collection feature, see chapter 10 in the IBM i Security Reference manual or the Authority Collection chapter in my newly released book IBM i Security and Compliance, Third Edition.

  • Security-related DB2 Views: Starting in V7R1, with new views added to each operating system (OS) release as well as each Technology Refresh (TR), these views provide a much easier way to obtain security information than running the corresponding command. For example, to get information about all or a specific set of user profiles, I use SQL to get information out of the USER_INFO view in the library QSYS2 rather than run the Display User Profile (DSPUSRPRF) command to an outfile. It’s much faster to get to the exact set of profiles I’m looking for and the information is always up-to-date. I don’t have to remember to rerun the DSPUSRPRF to get the most current information. You can also use this view to review user profile attributes as discussed in a previous section. Finally, the Authority Collection information will be displayed properly only if you use one of the five views provided for this feature.

Some views aren’t listed as security-related but are quite useful for security administration. For example, the SYSTOOLS.GROUP_PTF_CURRENCY view does a “phone home” to IBM, gets the current group PTF levels, and compares them to what’s installed on your system, giving you an easy view of what group PTFs need to be updated. Another view, QSYS2.OBJECT_STATISTICS and newly added IFS version QSYS2.IFS_OBJECT_STATISTICS, provides vital last-used information that will help you with those cleanup projects. To get the full list of views along with the OS version or DB2 group PTF in which it was delivered, go to Once there, clicking on the name takes you to the Information Center page containing a detailed description.


We’re all impacted in one way or another by this unprecedented time. I hope you’ve enjoyed my translation of what I’m doing to stay sane in my personal life into suggestions for staying sane as an IBM i security administrator. Be well, everyone!