Live Security Related Webcasts and Training for IBM i

March Events

Live Hands-On - IBM i, iSeries System Administration and Control Workshop
with Dan Riehl
Training Workshop - Mar 13-17 - Presented by The 400 School, Inc.
Dan Riehl presents this 5-Day Live Online Hands-on Workshop.
More Information and Register to Attend

Live Hands-On - IBM i, iSeries Concepts and CL Programming Workshop
with Dan Riehl
Training Workshop - Mar 20-24 - Presented by The 400 School, Inc.
Dan Riehl presents this 5-Day Live Online Hands-on Workshop.
More Information and Register to Attend

Live Hands-On - IBM i, iSeries Expanded Security Workshop
with Dan Riehl
Training Workshop - Mar 27-30 - Presented by The 400 School, Inc.
Dan Riehl presents this 5-Day Live Online Hands-on Workshop.
More Information and Register to Attend

April Events

Live Hands-On - IBM i, iSeries System Administration and Control Workshop
with Dan Riehl
Training Workshop - Apr 24-28 - Presented by The 400 School, Inc.
Dan Riehl presents this 5-Day Live Online Hands-on Workshop.
More Information and Register to Attend

May Events

Live Hands-On - IBM i (iSeries, AS/400) Security Audit
                               and Vulnerability Assessment Workshop
with Dan Riehl
Training Workshop - May 9-12 - Presented by The 400 School, Inc.
Dan Riehl presents this 4-Day Live Online Hands-on Workshop.
More Information and Register to Attend

*SECOFR User Class Does Not Make A User Powerful

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 one major thing. It determines what menu options are displayed on IBM supplied menus. You can easily see the result of user class and menus on the 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. 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 user profile attribute that provides *ALLOBJ, and other special abilities is NOT the User Class, it is the attribute Special Authority(SPCAUT).

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). We could have just as easily specified the command as:

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 run most of them. This is because the user was not granted any special authorities.

I know that this is a somewhat goofy example. We would never create a user profile as a *SECOFR class with no special authorities, but I wanted to illustrate the point, that the User Class alone, 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 user class.

(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.)