Common Misconcepts on IBM i User Class - *SECOFR

By Dan Riehl

When we create user accounts on the IBM i, we use the command CRTUSRPRF(Create User Profile). One of the attributes of a user profile is the User Class. The choices are *SECOFR, *SECADM, *SYSOPR, *PGMR or *USER. The Security Officer(*SECOFR) user class does not make the user powerful, just as the user class of System Operator(*SYSOPR) does not convey any power to the user to manage the operations of the system.

The User Class assigned to a user does two major things. 1) It confuses IT auditors, and 2) it determines what menu options are displayed on IBM supplied menus. You can easily see the result of User Class and Menus on the IBM supplied MAIN menu. If a user runs the command GO MAIN, some menu options will be shown, others may not be shown, all based upon the user's assigned User Class.

In another example, consider the IBM supplied menu named SECURITY. To access the menu the user runs the command GO SECURITY. If the user has a User Class of *USER, only one menu option is shown, "Change your Password". On the other hand, if the user has a User Class of *SECOFR, all options on the SECURITY menu are displayed. But, just because a menu option is shown, does not mean the user has the authority to exercise the menu option. For example, option 8 from the SECURITY menu runs the command, GO SECTOOLS. Unless the user has *ALLOBJ special authority, or is specifically granted a private authority to the SECTOOLS menu, selecting option 8 from the menu will result in an error message "Not Authorized to object SECTOOLS". The SECTOOLS Menu ships from IBM with an authority of *PUBLIC AUT(*EXCLUDE).

The user profile attribute that provides *ALLOBJ, and other powerful operational capabilities is NOT the User Class, it is the User Profile attribute named Special Authority(SPCAUT).

The main reason for confusion on the pupose of the User Class attribute is that when we create user profiles we typically specify the command as follows:

CRTUSRPRF USRPRF(MYUSER) USRCLS(*SECOFR) SPCAUT(*USRCLS)

Here we create a powerful user by specifying that the user has all of the special authorities(SPCAUT) of the *SECOFR User Class(USRCLS). When we specify *USRCLS for the special authority attribute, the User Class is used to determine which special authorities as User receives. However, we could have created the user profile with no special authorities at all by setting the special authorities to *NONE, as in the following command.

CRTUSRPRF USRPRF(MYUSER) USRCLS(*SECOFR) SPCAUT(*NONE)

In this example, the user would be able to see all of the menu options on the SECURITY menu, but would not be able to Use most of them. This is because the user was not granted the special authorities required to run most SECURITY menu options.

I know that this may seem like a goofy example. But I actually like to assign *NONE as the special authority attribute to users, and allow them to inherit any special authorities from their Group Profiles. So I put operators into a group profile of G_OPER, and assign *JOBCTL special authority to the Group. If *SAVSYS is needed by some operators(or other users) to allow them to do backups, I give them a Supplimental Group Profile of G_SAVSYS. In this case the G_SAVSYS Group Profile has only *SAVSYS special authority which is then inherited by the members of the Group.

The User Class does not provide any capabilities to the user, except the ability to see menu options on IBM supplied Menus.

When we consider the command again,

CRTUSRPRF USRPRF(MYUSER) USRCLS(*SECOFR) SPCAUT(*USRCLS)

The default value for the SPCAUT parameter is *USRCLS. So, unless we override the SPCAUT value *USRCLS, the user will have special authorities assigned according to the user's User Class.

Assuming you are running QSECURITY level 30 or higher, here are the default Special Authorities assigned by the different User Classes.

(Note: The User Class can also be specified in the CRITMSGUSR parameter of the CHGSRVA(Change Service Attributes) command, to cause users of a particular User Class to receive critical system break messages.)

     

About the Author

Dan Riehl is the Editor of the SecureMyi Security Newsletter and a Security Specialist for
the IT Security and Compliance Group

Dan performs IBM i security assessments and provides security consulting, remediation, forensic evaluations, and other customized security services for his clients. He also provides training in all aspects of IBM i security and other technical areas through The 400 School, Inc.

Dan Riehl on LinkedIn