|
Feature Article
Misconceptions of the User Profile's User Class (USRCLS)
*SECOFR User Class does NOT make a Powerful User!
By Dan Riehl - SecureMyi.com
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.
Just What Does the User Class Really Do?
The User Class assigned to a user does two major things. 1) It confuses IT Auditors, and 2) it determines what menu options are shown when the user displays an IBM supplied menu. 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).
Why the Confusion?
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)
Read More
|
Live Security Related Webcasts and Training for IBM i
July Events
Live Hands-On - IBM i, iSeries System Operations Workshop
with Dan Riehl
Training Workshop - July 16-18 - Presented by The 400 School, Inc.
Dan Riehl presents this 3-Day Live Online Hands-on Workshop.
More Information and Register to Attend
Live Hands-On - IBM i, iSeries Expanded System Operations Workshop
with Dan Riehl
Training Workshop - July 16-20 - 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 System Administration and Control Workshop
with Dan Riehl
Training Workshop - July 23-27 - 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, AS/400) Security Audit
and Vulnerability Assessment Workshop
with Dan Riehl
Training Workshop - July 31 - Aug 1 - Presented by The 400 School, Inc.
Dan Riehl presents this 4-Day Live Online Hands-on Workshop.
More Information and Register to Attend
August Events
Live Hands-On - IBM i, iSeries Programming Introduction Workshop
with Dan Riehl
Training Workshop - August 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 - Expanded Control Language Programming Workshop
with Dan Riehl
Training Workshop - August 27 - 31 - Presented by The 400 School, Inc.
Dan Riehl presents this 5-Day Live Online Hands-on Workshop.
More Information and Register to Attend
September Events
Live Hands-On - IBM i, iSeries Expanded Security Workshop
with Dan Riehl
Training Workshop - September 11-14 - Presented by The 400 School, Inc.
Dan Riehl presents this 4-Day Live Online Hands-on Workshop.
More Information and Register to Attend
|
|
Security Shorts
Copying Authorities from one User to Another
By Dan Riehl
I always encourage administrators to use or create a special "owner" profile to own all of our production objects/ For example, instead of the Distribution application programs and files being owned by a conglomeration of programmers and other IT people, the objects should be owned by a special owning profile, like DSTOWNER. DSTOWNER is not a group profile, and it has no password, so it cannot be used to sign on.
I also advise that certain system objects that we create, like User Profiles, be owned by QSECOFR. It might requires an extra step to assign the ownership to QSECOFR, but doing so avoids the problem of these objects being owned by IT staff members, who, as we all know, come and go.
Creating a New User
When a new user must be created on your system, it is usually rather straightforward. However, if you have fallen into the trap of assigning object authorities at the user profile level, it becomes much more difficult to create the new user.
Let's say that you have a new system administrator and this new user needs to have the same authorities as an existing system administrator. You can easily copy the existing user profile to the new one. The Copy User profile option is available as Option 3 from the WRKUSRPRF(Work with User Profiles) display.
But, copying a user profile in this way does not copy the private authorities of the original user. For example, if the existing user owns a collection of libraries or files, that existing user has *ALL authority to those objects. How do we grant *ALL authority to the new user.
If the original user has private authorities, or ownership of 50 commands, 10 libraries, 200 files and a few job descriptions, you will need to grant all those same authorities to the new user. IBM has provided the tool to copy these authorities using the command GRTUSRAUT(Grant User Authority).
When using the command GRTUSRAUT, make sure you are signed-on as QSECOFR or as an *ALLOBJ user, otherwise, certain objects or authorities may be skipped.
Copying the Authorities
Here is a command that will copy the private authorities(including those granted through ownership) from OLDUSER to NEWUSER.
GRTUSRAUT USER(NEWUSER) REFUSER(OLDUSER)
When you run this command, it would be best to submit it to batch, since it may take a long time to run. So use the command
SBMJOB CMD(GRTUSRAUT USER(NEWUSER) REFUSER(OLDUSER))
Here is the IBM Documentation on the GRTUSRAUT command.
|
Sponsored Links
IT Security and Compliance Group
- In Depth Security Assessment of IBM i
- Upgrade to QSECURITY level 40
- Forensic Research and Analysis
- Audit Assistance and Remediation
- Security Training for IT and Audit Staff
- Software Selection & Configuration
- Security and Systems Programming
- General Security and System Assistance
Customized IBM i (iSeries, AS/400) Training -
Presented Live at your offices
LIVE Online Hands-On Workshops
- ILE RPG IV Programming
- RPG/400 and RPG III Programming
- ILE COBOL/400 Programming
- Interactive Programming Workshops
- System Operations Workshops
- System Administration and Control
- Security and Auditing Workshops
- Control Language Programming
- IBM i Concepts and Facilities
- Query Workshop
|
