A reader contacted me recently after reading a tip I wrote that urged System i shops to implement object level security using authorization lists. This user had been doing just this for years, but was concerned because, "in the heat of the moment," objects might get created without making sure the necessary authorization list is attached. I could not give the reader a quick answer, but I've been mulling it over since. This tip will give you one way to check to see if all of the objects in a library are secured by your authorization list.
There are two commands in the IBM i operating system that you can use to create database lists of objects for the audit check. The "display authorization list object" (DSPAUTLOBJ) command can be used to create a database list of all objects secured by your authorization list. This will include all objects currently on your system, regardless of library used, that are secured by the list. For this audit check, the following command format would work well:
DSPAUTLOBJ AUTL(myautl) OUTPUT(*OUTFILE)
OUTFILE(QTEMP/AUTLOBJS)
Just substitute the name of your authorization list where you see "myautl."
The second command you will need is the "display object description" (DSPOBJD) command, which can be used to create a database of all objects in a library. The command can be used for all objects in the library or a subset of objects in the library. You can also run it several times to add objects from other libraries to your database. To create the database for all objects in a given library, the following command format can be used:
DSPOBJD OBJ(mylibrary/*ALL) OBJTYPE(*ALL) OUTPUT(*OUTFILE)
OUTFILE(QTEMP/LIBOBJS)
If you want to add more objects from another library, use the following command format:
DSPOBJD OBJ(mylibrary2/*ALL) OBJTYPE(*ALL) OUTPUT(*OUTFILE)
OUTFILE(QTEMP/LIBOBJS) OUTMBR(*FIRST *ADD)
Once you have both databases created (note, these examples create the databases in the QTEMP library, but any library can be used), then all you need is your favorite ad-hoc query reporting tool, match the two databases and generate a control report.
My favorite tool is Query/400. On my system, I created a report to just list the library name, object name, object type and object text description. The primary file in the query is the list of objects in the library. I then used the list of objects from the authorization list as a secondary file. For the key matching, I selected the library name, object name and object type as that should be unique. For the type of match, I selected the third option that shows as "Unmatched records with primary file." This will end up printing only those objects that are in the library that are not secured by the authorization list.
This task took me about 15 minutes and, in the end, I created a report that surprised me a little with the number of objects that were not properly secured the way I thought they should be. To be able to recreate the process easily, I went ahead and created a CL program with a command -- another 10 minutes. I now have this available and if you'd like to get a copy of the library that contains this utility, just drop me an email message and I'll send it out to you.
If you find a lot of exceptions or surprises, like I did, you will also want to review your procedures to find out how this is happening and tighten things up.
If you have any questions about this topic or you would like a copy of the matching utility I created, you can reach me at rich@kisco.com, and I'll give it my best shot. All email messages will be answered.
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.
