Carol takes a look at the proper use and configuration of group profiles.

I realized that it's been awhile since I've discussed group profiles, so this article is a review of when to use group profiles and how they should be configured.

Why Use Group Profiles?

Sometimes when I ask someone if they use group profiles, they sheepishly answer, "No." I have to assure them that that's OK. There's no magic in using group profiles; they don't make your system more secure. But they can make your life as a system or security administrator easier. Group profiles are useful in helping you manage users who all need the same authorities. If you have five programmers and they all need authority to the same debugging commands on your production server, put them in a group and authorize the group rather than authorizing each individual programmer to all of the commands.

Another reason to look at using group profiles is that they allow you to implement roles. You may have several roles—operator, programmer, user profile administrator, etc. Each role requires access to specific commands or libraries, and the tasks they perform may require specific special authorities such as *JOBCTL, *SAVSYS, or *SECADM. Rather than grant access to everything required to perform the tasks, assign the authorities—including the special authorities—to the group. Then, anyone added to the group automatically has the authorities that are assigned to the group. Disciplining yourself to create a group profile for each role—even if there's only one user in the role—will save you time in the long run.

One last reason I like to recommend group profiles is for ownership. Now don't get me wrong. Applications should absolutely, positively not be owned by a group profile because you definitely don't want every member—that is, every user of the application—to have ownership rights to the application data. Having ownership rights means that when users access the application data from outside of the menu, they are doing so with *ALL authority and therefore can not only read data, but also modify and delete it. And if you don't think your users are smart enough to access data from outside of an application menu, you're kidding yourself. Let me get back to the point of this paragraph. Think of roles again. It's likely that everyone in the role will need access to objects other people in the role have created—such as job descriptions, devices, printers when discussing the operator role. Likewise, the profile administration team needs authority to profiles created by other members of the team, and when considering the developer role, they need access to utilities and programs created by other members of the teamConfiguring the members of a role to automatically have their group (role) own their created objects rather than retain ownership themselves will eliminate a lot of security hassles. And it will also be easier to delete the profile when users/members leave the organization, because the group—rather than the individual profile—will own the objects. This approach does have a couple of limitations, so let's look at those:

• Ownership will be changed to the group for objects in libraries only. Objects created into a directory will remain owned by the individual.
• The OWNER parameter applies only to the user's first group profile—in other words, the group defined by the Group profile (GRPPRF) parameter. It cannot be applied to any group in the Supplemental group profile list (SUPGRPPRF).  

Creating a Group Profile

A group profile is meant to represent an entity or a role, not a person; therefore, you want to create it in a way that reflects the intent. Here are my recommended settings when creating a group:

• USRPRF(GRPxxx)—I like to use a naming convention that makes it easy to identify a group profile.
• PASSWORD(*NONE)—Group profiles should not be used for sign on, so the password should be set to *NONE to make sure that cannot occur.
• PWDEXPITV(*SYSVAL)—Because the password is *NONE, the password expiration interval is never examined, so it can be left at *SYSVAL. Some people think it needs to be set to *NOMAX, but that's not the case.
• STATUS(*DISABLED)
• LMTCPB(*YES)—This parameter doesn't really matter since it's never going to be used for sign on, but it's easier to set it to the restrictive value than to explain it to your auditor, don't you think?
• SPCAUT(*NONE)—If possible, grant no special authorities, but this might not be possible in all cases. When you need to grant a special authority, grant only the authorities needed for the group members to perform their tasks, no more.
• TEXT(make this meaningful)—I've seen too many profiles that either have no text description or have one with no meaning. Please, for those administrators coming after you, make this a meaningful description! 

Miscellaneous Facts

A user can be a member of up to 16 group profiles: 1 group profile and 15 supplemental groups.

The order in which you define user profiles is important only from a performance point of view. The system checks the authority in the order the groups are defined in the user's profile. Put the most-used group at the top of the list for the speediest authority check.

Question: Which wins? Authorities at the user or at the group? Answer: Authorities defined at the user take precedence over authorities assigned at the group. In other words, if a user has been granted *USE authority to a file and one of their groups has *CHANGE, the system will use the *USE authority and never check the group list.

Authorities granted at the groups are cumulative. For example, if GROUP1 has *OBJOPR and *READ authorities, GROUP2 has *ADD, *UPD, and *DLT authorities, and GROUP3 has *EXECUTE authority, when the system is done checking the user's groups, the user has *CHANGE authority because of the accumulation of authorities from all three groups. Strange but true.

All groups are examined for sufficient authority before either issuing the "Not authorized" message when finding some but not sufficient authority for the task or going on to examine *PUBLIC authority if no authority is found at the group level. Because of this, you have to be careful with adding multiple groups to a user's profile. If the purpose of one group is to grant the user read-only (that is, *USE authority) to a file but you add that user to a group that has been granted *CHANGE authority to the same file, the user will be able to not just read the data but update it as well.

Set It and Forget It

This should not be your attitude about group profiles. On a regular basis, you should review the authorities granted to a group as well as the member list. You are usually notified when users have changed roles and need to be added to a different group. But often, the user needs to remain in their current role (group) while they train for their transition. As a result, if you don't regularly review the members of a group, users will remain in groups far beyond the transition period. This means they will have the ability to perform tasks not appropriate for their current role and retain authority to objects that they no longer have a business requirement to access. What do I mean by "regularly"? I recommend group membership be reviewed quarterly.

Final Thoughts

While you don't have to use group profiles, I hope that this quick review has either confirmed that you're doing the right thing by using them or made you think about implementing them in the future.