The AS/400 shines in its ability to connect to other computers and computer networks; and now, it can even connect to the Internet. With the connectivity talents of the AS/400, however, comes a liability to protect its resources. The more users who can gain entry into your AS/400, the greater the need to properly secure its resources. Fortunately, OS/400 provides the security functions you need; all you need to do is implement them.

OS/400 security provides many ways for you to protect your system from unauthorized access. One part of your security implementation will involve setting up user profiles for the people who need access to your AS/400. One of the best ways to organize these user profiles is to assign them to a special type of profile?the group profile. With group profiles, you can designate authority for certain users and prevent unauthorized users from gaining access to sensitive documents and important files. Read on to find out how you can simplify security implementation by taking advantage of group profiles.

Personality Profile

Group profiles were designed to categorize user profiles and to define the level of authority those users have. For instance, your programmers don't need the files the accounting department uses?so why not block their access to them?

Those programmers may never even think about going into those files, but that's no reason to give them the opportunity. In fact, it's a bit like not bothering to close the gate to the farm just because the cows are on the other side of the field! It makes sense, then, to restrict employees to only the information required for their positions in the company.

Assigning authority levels to individual users is an arduous process at best. Group profiles make it easier because entire segments of employees can be grouped under one heading. All members of the group then obtain the same level of access. This means the members of the accounting department can all gain entry to the same accounting files, and you won't have to worry about them accessing another department's files (either intentionally or accidentally).

In most environments, employees who perform the same jobs or work in the same department would have the same, or at least similar, authorization. There would of course be variance, but most employees' authorizations could be defined by their job titles.

As an example, let's set up a group profile for the customer service department (we'll call it GRP_CSR). To do that, we'll use the following command:

 CRTUSRPRF USRPRF(GRP_CSR) + PASSWORD(*NONE) + SPCAUT(*NONE) + USRCLS(*USER) + GRPPRF(*NONE) + TEXT('Customer Service + group profile') 

After doing this, we will need to modify the user profiles so they become members of their respective group profiles. For example, let's say there is an employee named Sheila Nelson (user profile NELSON) in the customer service department. To join her to the GRP_CSR group profile, execute the following code:

 CHGUSRPRF USRPRF(NELSON) + GRPPRF(GRP_CSR) + OWNER(*GRPPRF) 

We need to grant the customer service group profile authority to the objects it needs, while denying access to those not in the group profile. In other words, each object in the system will have a public authority of *EXCLUDE; it will then be modified to grant authority to the proper group profiles. To do that, use the following commands:

 RVKOBJAUT OBJ(xxx/obj_name) + OBJTYPE(*FILE) + USER(*PUBLIC) + AUT(*ALL) GRTOBJAUT OBJ(xxx/obj_name) + OBJTYPE(*FILE) + USER(GRP_CSR) + AUT(*CHANGE) 

You might think that this is a time-consuming task. However, you can save time by specifying a generic object name or *ALL for the OBJ parameter of each command. You can also specify multiple profile names on each command.

Not All Group Members Are Created Equal

Unless you are at V3R1, each user on your system can belong to only one group profile. To grant or deny individual authority to an object, the object's authority must be modified to include or exclude that user. This allows users within a group profile to possess varying levels of authority, but it also requires extra work.

If, for example, an accountant on your system also processes some orders for the sales department, you had three options before V3R1: change the authority of each of the sales department's objects; constantly change the group profile that user belongs to (from the accounting group profile to the sales group profile and back again); or allow the user to sign on with two different user profiles (one for accounting and one for sales).

With V3R1, that drawback has been eliminated. Each user can now be a member of up to 16 group profiles.

The first group profile a user belongs to is known as the primary group profile. Each successive group profile that user belongs to is known as a supplemental group profile. One primary group profile and up to 15 supplemental group profiles can be assigned to a user profile. With supplemental group profiles, an employee in the marketing department can utilize, say, the sales department's resources?without losing the marketing department's resources, compromising your AS/400's security, or requiring additional authorizations at the object level.

To make the most of your system's performance, utilize supplemental profiles sparingly. This will minimize the number of groups that will have to be searched to grant object access. Also, list the supplemental group profiles in order from most authority to least authority so fewer checks are needed. This will place the least drain on your system's resources.

Group Membership Has Its Benefits

You'll find many other benefits to implementing group profiles on your AS/400. For example, when users create objects, the system can automatically transfer ownership of those objects to a group profile if a user profile is set to OWNER(*GRPPRF). This provides access to the objects for all the members of that group profile and simplifies object security implementation.

OS/400 has several commands to help you manage group profiles. For instance, you can list the members of a group profile with the Display User Profile (DSPUSRPRF) command.

 DSPUSRPRF USRPRF(GRP_CSR) + TYPE(*GRPMBR) 

You can display the primary and supplementary group profiles a user belongs to by entering the following command:

 DSPUSRPRF USRPRF(NELSON) + TYPE(*BASIC) 

You can also see a listing of all user profiles in existence on your system, sorted alphabetically according to group profile, with the Display Authorized Users (DSPAUTUSR) command.

 DSPAUTUSR SEQ(*GRPPRF) 

Running the Display Object Authority (DSPOBJAUT) command will show what authority a group profile has to an object. To run this command for a program called CSR1, execute the following command:

 DSPOBJAUT OBJ(CSR1) + OBJTYPE(*PGM) 

This command will list the names of all the group profiles and specific users authorized to use the designated object. It will provide you with an idea of what levels of authority have been granted for a particular object.

Should I Join the Group?

Group profiles won't necessarily benefit everyone. Small AS/400 shops probably won't need to use them.

Bigger shops will find group profiles most beneficial. They are a relatively easy way to improve your AS/400's security and streamline your user profiles.

More importantly, your system administrator won't be bogged down by treating each user profile individually, except in rare instances. The time investment required may seem daunting at first, but it will quickly become evident just how much time was actually saved by implementing group profiles.

John M. Hogan is a staff writer for Midrange Computing.

References

OS/400 Security?Basic V3R1 (SC41-3301, CD-ROM QBKALB00).

OS/400 Security?Reference V3R1 (SC41-3302, CD-ROM QBKALC00).

Also Read

IBM i Security Essentials: 4 Components for an Effective Strategy

New IBM i Security Features and a Farewell

Securing IBM i: A Dual Responsibility