Carol describes the basics of IBM i security and explains how to manage IBM i security using Navigator for i.

If you need a refresher on IBM i security, are just starting out on this adventure, or need a tutorial on using Navigator for i to manage your security settings, this article’s for you! I realized that with new administrators and/or auditors being introduced to the system all the time, I needed to step back from my deeply technical articles and provide guidance on getting started. So here we go.

IBM i security consists of three areas that you’ll want to understand and manage: global settings (called system values), identities or users (called user profiles), and access controls (called object-level security). I liken these areas to legs of a three-legged stool. If one is shorter than the others, you’ll topple over when you sit on the stool. Likewise with IBM i security. If one area is left wide open, it doesn’t matter that the other two have been set to the most restrictive settings; your security objectives cannot be met. These three areas must be in balance for you to achieve your security objectives. Let’s start this discussion with the global settings.

System Values

Many system values exist to control IBM i. There are date/time, storage, language, job, and network configuration-related settings to name a few of the categories in addition to security-related settings. The easiest way to examine the security-related system values is to launch Navigator for i

via the URL http://your-system-name:2002/Navigator/login, click the padlock icon, and choose Security Configuration Info. This view provides a list of all global security-related values, the current value, all possible values, and a description as shown in Figure 1.

Figure 1: Click on the padlock icon and choose Security Configuration Info.

If you ever need to modify one of these global values, go to the clipboard icon and click on System Values. A list of system value categories is displayed. Beware that this is a list of all system value categories, not just those that are security-related. In Figure 2, I clicked on the Auditing category. From this window, I can manage all of the system values related to logging (called auditing on IBM i.) This interface shows a more readable version of the settings as well as the name of the setting used by the green-screen environment. You might find this handy if you’re moving between the two interfaces.

Figure 2: Click on the clipboard icon and choose the category of System Value to display or modify.

User and Group Profiles

The second “leg” of IBM i security to address are users and the sub-category of group profiles. Float down to the people icon and you can choose to create a new user or group or work with a list of user profiles or group profiles (see Figure 3).

Figure 3: Click on the people icon to work with user or group profiles.

When creating a new user or group, you can create it from scratch or base it on a model profile. I prefer to create a model profile that represents each role in the organization and base new profiles on the appropriate role. That way, I have all of the details of the profile’s configuration already defined and I don’t have to think about them when creating a new profile. As you’ll see when you go to create a user profile, there are many configuration options, but I’m going to focus on four:

• Prior to IBM i 7.5, the password defaults to be the same as the user profile name. Make sure you change the password to a strong password and check the box that will cause the user to change the password upon first use. (At IBM i 7.5, the profile defaults to not have a password, which means the profile cannot be used for signon until assigned a password.)
• Special authorities should only be assigned if the user needs the capability provided by the special authority. Of special concern is the special authority called All object access (or *ALLOBJ in the green-screen environment). Users assigned this value have all authority to all objects on the system (files, libraries, directories…everything!). Obviously, this authority should be granted only to administrators. Developers will claim they need this authority, but don’t be fooled! They do not! And obviously, end users have no business being assigned this capability.
• Group and supplemental group profiles are the means IBM i provides for placing users in a role. I create a group profile that represents a role (much like the model profile described previously) and assign all special authorities to that role. Then, when a new profile is assigned, they will automatically inherit the special authorities of the role. Profiles can be a member of up to 16 group profiles.
• The limited capability setting determines whether the profile has the ability to run commands should they get access to a command line. It only has meaning in the green-screen environment but should be applied to end users because they should not be able to run all commands.

To work with existing users and groups, click on the appropriate category to see the list. You can filter to see a specific user/group or profiles with a specific setting, such as those assigned All Object. If you need to display or investigate an attribute that’s not displayed, simply click on the three vertical dots in the upper right of the display. From there you can add or remove columns to display only the attributes you want in the order you want. If you have the correct attributes but don’t like the order, simply drag and drop the columns to achieve the view that suits your analysis. If you prefer working with SQL, click on “SQL” in the upper right and the SQL will be displayed so you can copy and paste it into a Run SQL Scripts window. See Figure 4.

Figure 4: Many options are available to customize the list of profiles displayed.

Object-Level Security

The final leg of our IBM i security three-legged stool is access control, or object-level security. For a process to run successfully, the user currently running the process must have sufficient authority to perform the action on the object being accessed. The actual authority required has been architected at the microcode (Machine Instruction) level. Objects can be contained in a library or a directory. Libraries are the original “containers” and hold most of the object types on the system. Directories were added back in the Version 3 days, when there was an effort to migrate UNIX applications to the system. Because libraries are single level (that is, you can’t have a library in a library), a true directory structure needed to be added; thus the Integrated File System (IFS) was born. Regardless of where an object resides, the authority requirements are the same. What’s different and what confuses many is that the permission terminology for objects in libraries is different than that of directories. You’ll see that reflected in the Navigator for i displays.

To manage the permissions of an object in a directory, click on the file folder icon and choose Integrated File System. Navigate to the directory containing the object, right-click, and choose Permissions, as shown in Figure 5.

Figure 5: Right-click on the object and choose Permissions to set who has authority to access the object.

To manage permissions for objects in libraries, I’ve found that the fastest way to manage authorities is by using either the Schema or Integrated File System feature in Access Client Solutions (ACS). (Let me be totally honest. The Integrated File System section of Navigator for i is still a bit of a work in progress. It will be my preferred method once a few kinks are worked out.) Using the Integrated File System feature, I can specify the library using a pathname, such as /QSYS.lib/prod_lib.lib. This lists the objects in the library. I can then right-click, choose Permissions, and get to the display as shown in Figure 6.

Figure 6: Use the Integrated File System feature of ACS to manage permissions on the objects in a library.

For examples of using SQL to manage object permissions, see my previous article “Using IBM i Services to Manage Object Authority Settings.”

Summary

I hope you’ve found this tutorial useful. You’ll find that the security concepts for IBM i are the same as for any other platform, but the terms and implementation are definitely different. For a complete discussion of IBM i security, see my book IBM i Security: Administration and Compliance, Third Edition. And to manage IBM i security using modern interfaces such as SQL and Navigator for i, see my just-released companion book, Mastering IBM i Security.