What is your best practice recommendation on who should own profiles? I have systems where QSECOFR owns all profiles with PUBLIC *EXCLUDE. On one production system, QPGMR owns the profiles (*all authority) with PUBLIC *EXCLUDE. What security risks (if any) are we vulnerable to by having QPGMR own profiles?
I don't believe there is one right answer to who should own user profiles. One method that works is to create a profile that's purpose is to own profiles –- I'll call it PROFOWN. Then create a CL program that administrators run. The program is owned by and adopts PROFOWN. Within the CL program, the profile is created and then the ownership is transferred to PROFOWN. Other tools can then be created that adopt PROFOWN that will reset passwords and enable profiles. This way, no user owns the profiles and tools can be written to allow maintenance.
Another method is to have the user profiles owned by the group profile that the users administering profiles belong to. This is a slightly less secure method, but it still works. What doesn't work (from a security perspective) is to have a profile own the user profiles that are the group profile for users that have nothing to do with user profile administration. For example, if QPGMR owns profiles and all developers are a member of this profile and their role has nothing to do with user administration, QPGMR should not be owning the profiles. That's because, when a group owns an object (in this case a user profile) all of the group's members also own the profile. This provides members of the group with the ability to abuse these profiles -– in other words, use them to submit jobs, change ownership of objects, etc. Also, leaving profiles at *PUBLIC *EXCLUDE is the right thing to do.
MORE INFORMATION ON THIS TOPIC
The Best Web Links: tips, tutorials and more.
Search400's targeted search engine: Get relevant information on security.
Ask your systems management questions--or help out your peers by answering them--in our live discussion forums.
Check out this Search400.com Featured Topic: Top ten security tips
Dig Deeper on iSeries system and application security
Related Q&A from Carol Woodbury
Before changing password levels and upgrading operating systems on the AS/400, ensure the clients connecting to the NetServer do not need the old ... Continue Reading
Look in the audit journal (QAUDJRN) on the AS/400 for an authority failure message with the name of the library as the object name. Use the ... Continue Reading
On AS/400, the journal type AF subtype K, shows that a user profile lacks the special authority required by the function attempting to run. Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.