Admin Alert: Automatic Ways to Assign Group Authorities to an Object

Authority assignment problems can occur when users create application objects. For some software packages, objects must be owned by a specific user. For other objects, related user group profiles must possess certain object authorities. The result is that administrators sometimes have to tweak object authority after an object is created. Fortunately, i5/OS and OS/400 have a fairly easy way to automatically assign object ownership and authorities to user groups when a user creates an object.

The automatic group ownership and authority features I’ll discuss here were tested in OS/400 V5R3, but they are available in earlier V5 versions, the current i5/OS V5R4, as well as in earlier versions of OS/400 V4R5 and below. These features are configured inside individual user profiles (either by using the green screen or by using iSeries Navigator), and they allow you to automatically assign group profile ownership and object authorities to any object created by the user.

The best way to describe how these techniques work is to provide some practical examples that demonstrate how the techniques can help you administer your shop. To that end, I’ll look at the following scenarios where automatic group profile authorization to objects may benefit you the most.

1. When a user is installing or configuring objects for a particular software package and the package uses i5/OS adopted authority to provide user access to programs. As a result, all newly created, compiled, and copied objects must be owned by a specific user profile.
2. When a user wants to automatically add private group profile authority for one specific user group to any new object he creates.
3. When a user wants to automatically add primary group profile (PGP) authority for one specific user group to any new object he creates. PGP authority differs from private group authority in that PGP authority may result in better system performance when the system checks object authority.

The Players

To activate these features, you use the same user profile parameters for all three scenarios but each parameter is adjusted to a different setting. These parameters are changed by using either the green screen Change User Profile command (CHGUSRPRF), the Create User Profile command (CRTUSRPRF) or by using the target user profile’s Groups panel in iSeries Navigator (OpsNav). To get to OpNav’s Groups panel for a user, open your target user profile under the Users and Groups –> All Users node and click on the Groups button inside the User Properties panel that appears.

The relevant user parameters for enabling automatic group profile authority assignment for new objects are:

• The Group Profile parameter (GRPPRF) in CRTUSRPRF and CHGUSRPRF or the First Group listed on the OpsNav Groups panel in the Selected Groups area. This parameter is considered the primary group profile that the user profile is assigned to.
• The Owner parameter (OWNER) in CRTUSRPRF and CHGUSRPRF. OWNER determines whether any new objects that the user creates will be owned by the user profile or whether new objects will be owned by the group profile specified in the user’s Group Profile parameter (GRPPRF). This parameter is not available in OpsNav.
• The Group Authority (GRPAUT) and Group Authority Type (GRPAUTTYP) parameters in CHGUSRPRF and CRTUSRPRF; or the Access rights to objects created by user dropdown box and the Source of access rights radio buttons on the OpsNav Groups panel. These parameters determine whether the user’s primary group profile should be given private or primary authority to new objects created by the user, as well as what types of authority the group profile should be given.

These parameters are configured in tandem to create the automatic group profile authorization scenarios described above. Here’s how you would use them in our target scenarios.

Scenario #1: Automatically assigning object ownership to a group profile

In this scenario, any new object created by your user will automatically be owned by the primary group profile associated with that user (the user profile’s GRPPRF parameter). Because this configuration requires the OWNER parameter, which is only available on the CHGUSRPRF or CRTUSRPRF commands, you will only be able to configure this setup from the green screen; it is not available in OpsNav.

To set up a new user for this scenario, you can create the user by running the Create User Profile command (CRTUSRPRF) this way:

CRTUSRPRF USRPRF(user_name) GRPPRF(user_group_name) OWNER(*GRPPRF) . . . add other user profile parameters as needed

For existing users, it’s important to note that the default value for the user’s OWNER parameter is *USRPRF, which means that any new objects that the user creates will be owned by the user. To change a user’s OWNER parameter from *USRPRF to *GRPPRF, you can run the Change User Profile command like this:

CHGUSRPRF USRPRF(user_name) GRPPRF(user_group_name) OWNER(*GRPPRF) . . . add other user profile parameters as needed

Once you set up a user for this scenario, all the new objects he creates will be owned by the primary group profile. You can check this by signing on as the user and using the Create Physical File command (CRTPF) to create a simple file in QTEMP, like this:

CRTPF FILE(QTEMP/TESTOBJ) RCDLEN(80)

After the file is created, you can then use the Edit Object Authority command (EDTOBJAUT) to check its object ownership and authority values.

EDTOBJAUT OBJ(QTEMP/TESTOBJ) OBJTYPE(*FILE)

By doing this, you will see that the object owner is the primary group profile associated with the user profile that created the object (the user’s GRPPRF value). You will also notice that i5/OS assigns no private authority to the user profile who created the object. Under this scenario, any default authority to a new object for the creating user is inherited from being a member of the ownership group profile.

I also need to mention here that during my testing, it appeared that these parameter changes did not go into effect until the next time the user signed on to the system. If I changed a user’s group profile parameters, the object creation changes did not occur until the user logged off and logged back on to the system again. So be sure your users start with a fresh sign-on before creating new objects.

In addition to the transfer and termination benefits of assigning new object ownership to primary group profiles, this technique makes it easier if you want to insure that all created, compiled, and copied objects from several users (programmers, administrators, or database specialists) are assigned to the same user profile. If your security settings allow it, you can simply assign each of your target users the same group profile parameters and any objects that the group creates will be owned by your designated group profile.

Scenario #2: Automatically assigning private group profile authorities to objects a user creates

In this scenario, any object that the user creates will automatically assign specific private object authorities to the primary group profile that the user belongs to (the creating user profile will own the object under this scenario). This configuration can be done either through i5/OS green screen commands or through OpsNav. You can set up new user profiles so that specific private authorities are granted to the user’s primary group profile for any objects created by the user. For new users, this is done by creating their user profile with the following CRTUSRPRF command:

CRTUSRPRF USRPRF(user_name) GRPPRF(user_group_name) OWNER(*USRPRF) GRPAUT(*USE) GRPAUTTYP(*PRIVATE) . . . add other user profile parameters as needed

For existing users, you can change their group profile object authority parameters by running the CHGUSRPRF command this way:

CHGUSRPRF USRPRF(user_name) GRPPRF(user_group_name) OWNER(*USRPRF) GRPAUT(*USE) GRPAUTTYP(*PRIVATE) . . . add other user profile parameters as needed

Once changed, new objects created by this user will be owned by the user (because the OWNER parameter is equal to *USRPRF) but the user’s primary user group profile (as specified in the GRPPRF parameter) will also have a private authority setting of *USE for the new objects (because the group authority type, GRPAUTTYP is equal to *PRIVATE and the Group Authority parameter, GRPAUT, is equal to *USE ). Providing *USE access for private group authority is only one of several options you can use for specifying what private authority the creating user’s primary group profile has to new objects. You can automatically assign any one of the following four object authorities to the user’s primary group profile for any new objects he creates.

*ALL — The user group will possess authorities to access, change, and delete the object or any records in the object.

*USE — The user group will be able to access the object and its data but group members will not be able to update the object.

*CHANGE — The user group will be able to change the object but not delete it.

*EXCLUDE — The user group will not be able to access the object.

As I did in the first scenario, you can easily check the effects of this change by using the CRTPF command to create a new object in the QTEMP library, and then checking the new object’s private authorities by using the EDTOBJAUT command.

To perform this configuration in OpsNav, go into the user profile’s Groups panel under his user profile (again, this is accessed by opening the target user profile under Users and Groups->All Users and clicking on the Groups button). Inside the Groups panel, highlight the user’s primary group profile that he belongs to–which will be the first profile listed under the Selected Groups section–and change the value in the Access rights to objects created by user dropdown box from None to any of the following choices: All, Change, Use, or Exclude. Once you have changed the Access rights value, the Source of access rights radio buttons on that screen become active. Select the Private radio button to change the Group Authority Type for this user. By doing this, you will provide the corresponding private authority specified in the Access rights to objects created by user parameter to the user’s primary user group for any new objects that the user creates.

Scenario #3: Automatically assigning primary group profile authorities to objects a user creates

This scenario uses the same process as scenario #2, with one major difference. In scenario #2, when you assign private authorities to an object during object creation, private object authorities are always stored with the user group profile that they are assigned to. When a user accesses an object, the system references his user profile, as well as the user profile of any group profile he belongs to, to determine whether he is authorized to use the object and what object authorities he should have.

In scenario #3, when you assign object authorities to a user group profile during object creation, the system sets the creating user’s primary group profile as the primary group profile of the object being created. Each object contains one primary group profile, and you can find the primary group profile name by running the Edit Object Authority command (EDTOBJAUT)–as I did for our test object in scenario #1–and look at the field named ‘Primary Group’ in the upper right-hand corner of the screen.

Assigning a group profile as an object’s primary group profile means that for whatever object authorities that are assigned to the new object for its primary group profile, those authorities will be stored with the object, not with the group profile (as happens in scenario #2). So when the user accesses the object, the system will reference his user profile authorities and, if he belongs to the accessed object’s primary group profile, the system will take his object authorities from the object’s authority list rather than from the group profile’s authority list. This can result in a small performance increase because the system will not have to go to the user group profile for authority checking.

As I mentioned, there is very little difference in configuring a user profile to assign primary group profiles authorities to a newly created object as opposed to assigning private group profile authorities when that object is created. You would simply modify the CRTUSRPRF and CHGUSRPRF commands shown in scenario two to use the following parameters.

CRTUSRPRF USRPRF(user_name) GRPPRF(user_group_name) OWNER(*USRPRF) GRPAUT(*USE) GRPAUTTYP(*PGP) . . . add other user profile parameters as needed

CHGUSRPRF USRPRF(user_name) GRPPRF(user_group_name) OWNER(*USRPRF) GRPAUT(*USE) GRPAUTTYP(*PGP) . . . add other user profile parameters as needed

By specifying *PGP in the user’s Group Authority Type parameter (GRPAUTTYP), i5/OS will automatically make the primary group profile associated with the user profile the primary group profile of any new objects the user creates.

If you want to configure your user profile to use *PGP in OpsNav, perform the same configuration as in scenario #2 but, this time, select the Primary radio button in the Source of access rights area.

It’s Easy, But . . .

As you can see, configuring user profiles to automatically assign group profile authority when creating new objects is a fairly easy task. However, some care should be taken to understand how these configurations could affect your system security scheme. The key to using these techniques is to have a specific use in mind for configuring select user profiles–such as allowing all users in a specific user group to access consolidated files created by another user in that group–and then only using these techniques for that specific use. These automatic group profile authorization techniques should be used as a targeted configuration tool for accomplishing specific goals. They should not be used as general configuration parameters for all users.