Admin Alert: Reader Feedback on Limiting Users with *ALLOBJ Authority

October 12, 2005 Joe Hertvik

In a recent column about limiting access to i5/OS job commands, I stated that there is no way to restrict users with all object authority (*ALLOBJ) from accessing any object on an i5/OS (OS/400) system. It turns out that statement is wrong and that there is a technique you can use to limit a user with *ALLOBJ authority from accessing a specific object.

Reader Peter Kemp got the ball rolling on this one by sending me the following email:

“It’s a good idea to grant *ALLOBJ authority to user profiles by inheriting it from a group profile, rather than by explicitly granting it to individual profiles. If you do this, you can then put an *EXCLUDE entry onto an object authority list to keep a user profile with *ALLOBJ authority from accessing the object. The end result is that OS/400 will check the *EXCLUDE entry for the individual user profile first before it checks the user’s group profile *ALLOBJ authority, and the user will be denied access. Try it.”

I did try his technique and it works. The key here is that the group profile that the user belongs to–not his individual user profile–must contain *ALLOBJ authority, causing the user to inherit *ALLOBJ authority from the group rather than by explicitly owning it himself. This is important because i5/OS and OS/400 perform object authority checking for a user by running through seven sequential steps. Once the system finds an authority match in any one of the steps, it stops authority checking and either denies or grants access to the object based on that first object authority match that was found.

These are the seven steps that i5/OS runs through when checking object authority for a user.

1. Does the user profile have *ALLOBJ authority explicitly specified in his user profile? If so, authority is granted to use the object.
2. Does the user profile have individual private authority to the object? The user will then be granted or denied access based on whatever object authorities he possesses in the object’s authorization list.
3. Can the user be granted or denied access through an entry in an external authorization list that has private authority to the object? If present, the user adopts the object authorities specified for the authorization list, and is granted or denied access based on those authorities.
4. Is the user a member of a group profile that has *ALLOBJ authority? If yes, the user is granted access to the object because *ALLOBJ authority allows you to access any object on the system.
5. Can the user be granted authority to the object based on whether it belongs to a group profile that has private authority to the object? The user would be granted or denied object access based on the group profile’s explicit object authority for that object.
6. Is the user a member of a group profile that inherits object access rights through membership in an external authorization list that has private authority to the object? While more convoluted than the other tests, this check can grant or deny access based on whether the group profile that the user belongs to can access the object through an authorization list.
7. Does the object have *PUBLIC authority sufficient enough to allow the user to access the object? The user is granted or denied access based on the public user’s authority to the object.

For more information on how i5/OS and OS/400 check object authorities, see Admin Alert: The Seven Levels of OS/400 Authority Checking.

By using Peter’s technique–where the user inherits *ALLOBJ authority from a group profile and his user profile is explicitly denied access to specific objects through an *EXCLUDE entry in each object’s authority list–you can deny an *ALLOBJ user access to any object. With this technique, i5/OS will block access based on the individual user profile’s object access authority of *EXCLUDE (step 2 above) before it finds the associated group profile’s *ALLOBJ access (step 4). This technique takes advantage of the fact that, in the hierarchy of i5/OS authority checking, individual object access authorities trump object access authorities inherited from a group profile. All in all, it’s a good technique for locking almost any user out of an object.

There are three keys for using this technique to limit *ALLOBJ access to individual objects.

First, the user profile should not explicitly contain *ALLOBJ authority. Make sure that the user does not have *ALLOBJ listed under the Special Authority parameter (SPCAUT) of his user profile. You should also ensure that the user class parameter (USRCLS) of his user profile is not equal to Security Officer (*SECOFR) in combination with having his SPCAUT parameter set to assume the special authorities that are assigned to the *SECOFR user class (*USRCLS in the SPCAUT parameter). Either of these situations will invalidate this technique.

Next, to grant *ALLOBJ authority to your user, make that user profile a member of an i5/OS group profile that explicitly contains *ALLOBJ authority. You do this by listing the group profile name in either the Group Profile (GRPPRF) or Supplemental Groups (SUPGRPPRF) parameter of his user profile. This provides the user with *ALLOBJ authority without explicitly listing it in his user profile.

Finally, for any objects that you want to deny the *ALLOBJ user access to, change the object’s authority list to specifically exclude (*EXCLUDE) the user from accessing the object. After doing this, the object’s authority list might look something like this:

On the green screen, object authorities are changed by using the Edit Object Authority command (EDTOBJAUT).

And this will effectively kill individual object access for a user with *ALLOBJ authority.

An alternate way to deny object access for a larger number of *ALLOBJ users might be to have each user inherit *ALLOBJ authority from a group profile as shown above, and then make all those users a member of an external authorization list that is excluded from using the object you want to block access to (you can do this by adding a private authority of *EXCLUDE for the authorization list to the object you want to block). This would block access based on the user’s membership in the excluded authorization list (step 3 of i5/OS authority checking) before the operating system can find the user’s group profile right to *ALLOBJ access (step 4). I have not tested this technique yet but it should also work in limiting *ALLOBJ user access to an object.

RELATED STORY

Shutting Down WRKSBMJOB Options