Admin Alert: Six Simple Rules for OS/400 Group Profiles

OS/400 and i5/OS group profiles are a boon to system administrators because they allow them to centralize object authority administration for several users in one place. But group profiles also have their downside. Improper administration can lead to unnecessary and dangerous authority authorizations, audit control failures, and possible system compromise if an external user can sign on as a group profile member who has all object (*ALLOBJ) authority.

With the goal of making your system more secure through better group profile techniques, here are six simple rules for making group profile administration an easier and safer system process. These rules apply to group profiles residing on any i5, iSeries, or AS/400 computer.

1.  Group profiles should never be allowed to sign on to the system. A group profile is a template that defines what others can do on the system; it is not intended as a sign-on vehicle for users so they can perform system work.

When a user ID is designated as a group profile member, it automatically assumes all of the authorities assigned to its associated group profile. If the user leaves the organization or changes his duties, he can be removed from the group, at which point he automatically loses all the privileges he assumed from group membership.

But if a group profile user ID is allowed to sign on to the system, there is no easy way to cancel his group membership or to revoke his authorities, since other profiles are dependent on the group profile to define what objects they can access. By definition, group profile object authorities should remain relatively fixed; their authorities should only be removed as circumstances warrant, because changing a group profile can affect hundreds of dependent users in a large system.

So the best policy is to never allow your group profile users to sign on to the system. This is relatively easy to do as it only requires that you set the group profile password to *NONE by using the following Change User Profile command (CHGUSRPRF).

CHGUSRPRF USRPRF(profile_name) PASSWORD(*NONE)

If you have already have a number of group profiles on your system and you want to determine which ones do and do not have passwords, you can run the following Display Authorized Users command (DSPAUTUSR)

DSPAUTUSR SEQ(*GRPPRF) OUTPUT(*)

This will help you determine which users are currently allowed to sign on to the system under which group profiles. It will also provide you with a list for which group profile users may need to be cut off from system access.

2.  Group profiles should not own production objects. Object owners are super-users for every single object that they own. They can modify the object; delete records, members, or the object itself; move or rename the object; and authorize other users to the object.

Object ownership problems are compounded when the owning user profile is also a group profile, because each individual member of a group profile automatically inherits the authorities of the group it belongs to. And for some legacy applications, this problem is compounded when the software package specifies that all authorized users must belong to the group profile that owns all the application objects. (For a good discussion of this legacy application issue, read Vendor-Inflicted Security Exposures, by John Earl). In some cases, you may have limited options for changing group profile ownership. But whenever you can, stay away from allowing group profiles to own production objects because it compromises object authority integrity.

3.  Never allow QSECOFR, a security officer user, or any user with ALLOBJ authority to be a group profile. This should be obvious but these users possess All Object authority (*ALLOBJ), which means that they can modify, delete, or move any object in your i5/OS partition. Group profiles are meant to limit and define what group members can do on the system. Providing a group profile (and by extension, all the user IDs that are associated with it) with unrestricted authority defeats this purpose and it can cause system chaos. When you assign users to a group profile that has *ALLOBJ authority, you are increasing the chance that a malicious or incompetent user could damage your system.

4.  Don’t forget that user profiles can belong to more than one group profile. There are two places in a user profile where group profile membership is designated. The first is in the Group profile parameter (GRPPRF) of the user profile. Here you can enter the name of the group profile that a particular user belongs to. If the user only belongs to one i5/OS group, that group profile name will be entered in this field.

The second place where you can define i5/OS groups for a user is in the Supplemental Groups parameter (SUPGRPPRF) of the user profile. In this field, you can list up to fifteen additional group profiles that the user profile can belong to. Supplemental group profiles are handy when one user can perform work for multiple departments and he must have different authorities depending on which department he is currently performing work for.

If you are running older legacy software packages, be careful when relying on supplemental groups for authorizing a user to run menu items. I have run into a few situations where older packages will only access a user’s GRPPRF value to determine whether their group profile membership qualifies the user to run a software function. Groups listed in the SUPGRPPRF parameter can sometimes be ignored in older packages so be sure to test if multiple group memberships work as advertised when providing authorization to all legacy package options.

5.  Audit group membership on a regular basis and remove users who no longer belong in a group. As I showed you in rule 1, you should occasionally generate a list of valid group users by using the DSPAUTUSR command and you should also prune that list regularly to remove users whose group memberships have expired. DSPAUTUSR information can be output to either the user’s display or to a printout. To print group user information, you can run DSPAUTUSR like this:

DSPAUTUSR SEQ(*GRPPRF) OUTPUT(*PRINT)

This information is important to insure that your users only inherit the group profiles authorities that they are entitled to. You can also use it to avoid conflict of interests where a user can simultaneously be authorized to two competing groups at the same time, such as when a user has accidentally been assigned to different group profiles that authorize and post cash payments. Auditing group membership on a regular basis reduces the risk of an accidental or intentional audit point failure.

6.  Name your group profile user IDs so that they stand out in a crowd. If your i5 partition contains hundreds of user IDs that are assigned to various groups, be sure to use a unique group profile naming convention to make it obvious that this profile represents multiple system users. In my shop, I end all group profiles with the suffix “GRP”, as in OPER_GRP (for the operations group), PUR_GRP (Purchasing group), or AC_GRP (Accounting). By using a naming convention that is diametrically opposed to the naming convention for individual user profile names, it alerts admins at a glance that this profile represents more than just itself. And that is what Admin Alerts are all about, right?

RELATED STORIES

The Seven Levels of OS/400 Authority Checking

Vendor-Inflicted Security Exposures, by John Earl