Admin Alert: The Dangers of User Profiles with Privileges

Handling user profile authorities is one of the more critical i5/OS administrative duties. In particular, there are three crucial user parameters that must be set up correctly to prevent your users from inadvertently accessing objects and functions that they should not be using. Today, I’ll look at how you can work with these values to prevent several avoidable security pitfalls.

The Hierarchy of User Authority

Before you can work with user authorities, you must understand what they do. Here is the basic hierarchy of user profile security settings and how they relate to each other.

1. System privileges–Eight user profile settings that tell i5/OS exactly what a user is allowed to do on the system. These settings control whether the user can perform service functions, how they interface with spooled files and jobs, how they can access system objects, whether they can save and restore system objects, and whether they can control system auditing.
2. Privilege class–Privileged classes are prepackaged roles that can be assigned to new or existing user profiles. When creating a new user profile, the privilege class automatically grants specific system privileges to the user profile.
3. Groups–Allows you to enroll a user profile as a member of an i5/OS group. A user profile can be enrolled in several groups at the same time. In addition to the system privileges a user profile may already have, group members also inherit the system privileges of any user profile groups that they are enrolled in.

These values can be changed by using the green screen user profile commands or by using the Capabilities feature inside the iSeries Access (OpsNav) user properties screen. For this article, I’ll demonstrate how to manipulate these features by using OpsNav.

System Privileges–The Core Element

It’s important to understand that all user profile-based authorities are controlled through a user’s system privileges. Also known as special authorities, eight separate system privileges can be assigned to each user profile. These privileges can be individually assigned or they can be assigned as a group when the user profile is created or modified.

To work with a user’s system privileges, open the Users and Groups→All Users→user profile name node in OpsNav. On the user properties screen, click on the Capabilities button then click on the Privileges tab inside the Capabilities window. Under the settings that appear, you’ll be able to set the following system privileges for the user.

• All object access–This setting gives the user carte blanche to access any system object on the partition. All object access is the most dangerous user profile setting in the system. When a user possesses this authority, there is literally no object that they cannot access or update. That’s why the rule of thumb is to only provide all object access on an as-needed basis, giving it sparingly to system administrators. It’s also wise to keep this privilege away from your applications staff.
• Auditing control–This setting allows a user to perform auditing functions, including turning auditing on and off, as well as the ability to control user and object level auditing.
• Job control–This setting is ideal for operational personnel as it allows users to display, hold, change, release, clear, and cancel any jobs running inside a subsystem. With job control, a user can manipulate jobs sitting in job queues or in output queues. It also allows users to work with printer writers and to start and stop subsystems.
• Save/restore–Allows the user to save, restore, and free storage for system objects. Save/restore authority is in force regardless of whether the user has private authority to the object that is being saved or restored. Save/restore is another setting that is usually reserved for system operations personnel.
• Security administration–This setting allows users to create, change, or delete user profiles. However, security administration does not allow the user to work with every user profile in the system. Security administrators can only manipulate user profiles if they are authorized to run the user profile commands and if they have authority to the user profiles that they want to change. Security administrators also cannot provide user profiles with more system privileges than the administrator possesses. This can be handy for setting up departmental security officers who can handle simple user profile administration for a group of people.
• Spool control–Allows the user to perform any command or function that deals with spooled files. Spool control is the safest system privilege you can provide for a user.
• System configuration–This privilege allows the user to change system I/O configurations. System configuration is best reserved for system operations and administrators who may need to create and modify system devices.
• System service access–Allows the user to perform service functions on the system. Best used for service personnel and system administrators.

Besides using OpsNav’s user capabilities features, system privileges can also be set inside the green screen Create User Profiles (CRTUSRPRF) and Change User Profiles (CHGUSRPRF) commands. System privileges are called “special authorities” within these commands, each privilege has a slightly different name on the green screen commands, and privileges are changed in the command’s Special Authorities (SCPAUT) parameter list. Here’s a quick cheat sheet for how you map each system privilege to a special authority setting in the CRTUSRPRF and CHGUSRPRF special authorities list.