Tracking User Profile Sign-on

By Rich Loeber

I recently received email from a reader asking me how they could track sign-on activity for their security officer user profiles. The objective was to have a record of every time someone started a terminal session from one of these very powerful user profiles. Since these profiles have so much power to update and change your system, having a record of when and where these sessions are started is a good idea. Fortunately, there is a fairly easy way to do this within the operation system on your IBM i.

With each user profile on your system, there is an "Initial program to call" (INLPGM) parameter. Whenever someone signs onto your system, the operating system checks this parameter and, if there is a valid program present, calls it. You can take this feature and use it to create your log of user profile sign-on activity for selected user profiles.

The first step is to create a simple CL program. When the operating system calls the initial program, no parameters are passed, making your task quite easy. In your CL program, you will need to retrieve the user profile using the Retrieve Job Attributes (RTVJOBA) command. Armed with the current user profile, then just send a message using the Send Program Message (SNDPGMMSG) command to a pre-defined message queue indicating that the user profile has performed a sign-on operation. When I was testing this, I used the QSYSMSG message queue since it gets used by the operating system for security related events. But, you can use any message queue that works for you.

Problems may arise, however, in a couple of areas that you need to be prepared for. I have created this CL program on my system and have accommodated these issues. See the end of this tip if you'd like a copy of my source.

For starters, your system may already have an initial program set up for the user profile. If that's the case, then you will need to create a data area and store those values before you change the initial program setting. In my sample program, I've created a data area with the same name as the user profile in a special library. The data area is 20 characters long and contains the initial program and library associated with the user profile before my tracking program is set up for the profile. Since you want this to work for any user profile, the CL should check for the data area and, if it is not there, just assume that no initial program processing will be needed. After you have logged your activity message, just end your CL program by calling the program stored in the data area.

You will have to remember that every user profile will have to be able to run your program. To make sure this is not an issue, you should have the profile adopt the permissions of a security officer profile. This is done when you compile the CL program by setting the USRPRF parameter to *OWNER and running the compile under the profile of a security officer.

When everything is set but before you actually change the initial program setting on any profile, test your CL program to make sure it doesn't fail. This is one of those areas where it would be very easy to shoot yourself in the foot by implementing without testing. In the worst case, you might get locked out of your system. So test, test, test before you run with it.

Once implemented, then all you need to do is monitor the message queue. As users that you are tracking sign on, a message will show up in the message queue. Using the HELP or F1 key will also give you a date and time stamp of when the activity happened. If you want, you can also expand the information captured and reported by including other information from the Retrieve Job Attributes command such as job name, job number, etc.

If you have any questions about this topic, or if you would like a copy of my sample CL program, you can reach me at (rich at kisco.com), I'll send the CL along and try to answer any questions you may have. All email messages will be answered.

In this day and age, security officers can also access your system by means other than using a terminal session. To capture this activity, you will have to implement exit point solutions. This can be a daunting exercise, but our SafeNet/i software in it's Lite version, is a very affordable solution to this problem. It is available for a free 30 day trial if you're interested.