We would like to get up to at least a level-30 security and get rid of the *ALLOBJ. What are some considerations...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
we should keep in mind to make sure we don't shoot ourselves in the foot?
When moving to a higher security level, i5/OS will strip *ALLOBJ from all profiles except those in the *SECOFR user class. Therefore, you're going to have to decide how users are going to get enough authority to access and, where appropriate, modify the application data since it will no longer come from users having *ALLOBJ. Although several options exist, my preferred method is to have sufficient authority come from adopted authority. This allows you to set the appropriate authority on the database files – either *PUBLIC authority of *USE or *EXCLUDE. Yet, because the application adopts authority, users will still be able to perform their job functions when they come through the application menu. Accommodations will have to be made for any interface that accesses the data through something other than the application menus. To accommodate these database accesses, I usually secure the database files with an authorization list and grant authority to these "outside" processes so they can access the application files.
The interesting thing about security level 20 is that you can test changing the application's security scheme even before you change security levels. This is helpful because changing the security level requires an IPL before it takes effect. While it may appear that there is no security checking at security level 20, in reality, the same algorithm is run regardless of the security level. It just looks like there is no security checking because every profile has *ALLOBJ, so no profile is ever denied access. But you can remove a user's *ALLOBJ, even at security level 20. So you can test your new security scheme by creating a profile, removing its *ALLOBJ special authority and verifying that the application still works properly by running as this newly-configured profile.
I encourage you not to stop at security level 30, however. You really want your system running at security level 40 or 50. The steps to move to security level 40 are clearly explained in Chapter 2 of the iSeries Security Reference manual, available from the IBM Information Center.
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.