I regularly hear from shops where users, especially programmers, claim that they absolutely must have access to all objects to get through a normal work day. There are also many shops where certain users claim that they also need to be defined to the system as security officers to get their jobs done. Now, we all know that this is just not true, but some shops cave in and provide these authority levels as a form of appeasement. So, if you're the security officer in one of these shops, it is really incumbent on you to know two things:
a) What profiles have these special authorities
b) What those profiles are up to on your system
Fortunately, in the System i world, you can give someone the keys to the kingdom, but also have the system watch over their shoulder.
The first step is to identify the users that need watching. To do this, run a Display User Profile (DSPUSRPRF) command for all profiles using the *OUTFILE option to create a database that you can analyze. The basic information option is sufficient for your purposes. Using the new file just created, write a Query/400 report (or any similar database reporting tool you may have) to select all profiles with the user class field set to *SECOFR or that have the values *ALLOBJ and *SECADM in the list of special authorities. This will give you your list of profiles that need watching.
The rest of this tip assumes that you have security auditing active on your system. If you don't, drop me a line and I'll let you know how to get this active on your system.
Your next step is to check the system value QAUDLVL and make a note of the specific audit values that are already being logged on your system. For those profiles that you specifically now want to track all security activity, you will then need to use the Change User Auditing (CHGUSRAUD) command to add all of the audit values that are not currently listed in the QAUDLVL system value. This will ensure that all actions by these users will be included in the security journal.
Now, for those users that are particularly savvy, you will want to remove their ability to change the system auditing that you have just imposed on their profiles. You can do this by removing the *AUDIT special authority on their profile. Chances are excellent that they will never notice that this is gone, and by removing it, they will not be able to undo what you've just set up. A note of caution, you will not be able to remove this from the QSECOFR profile. Make sure that the password for this profile is not generally known as that could also defeat your objectives.
Lastly, check the system value QAUDCTL and make sure that it is set to the special value *AUDLVL. If it is not already set to this value, check around before making the change to make sure that you will not end up shooting yourself in the foot by making this change.
Now that you have all the pieces in place, you will find all of the information you need to do to track these users in the system security journal. Use the Display Journal (DSPJRN) command to display the information or move it into a database file on a regular basis for reporting and analysis purposes. You will find information in the iSeries Security Manual on how to process information from the security journal and how to interpret the codes and other information available there.
---------------------------
About the author: Rich Loeber is president of Kisco Information Systems Inc. in Saranac Lake, N.Y. The company is a provider of various security products for the iSeries market.
