Tracking System i user profile sign-on activity

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 System i.

• Monitoring QSECOFR


• Controlling access to workstations
• Top 10 System i security Q&As

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 indicati...

Digg This!     StumbleUpon     Del.icio.us

RELATED CONTENT iSeries security tips Security considerations for IBM i backups Developing a security incident response system for System i Tracking remote access users on System i Setting up security for programmers on IBM i Controlling remote access on your IBM i Checking in on your IBM i authorization lists PCI data security standards and the System i Securing the integrated file system on IBM System i Contextual security on IBM i: Limit user profile access Time for a security checkup for your i iSeries system and application security Developing a security incident response system for System i Setting up security for programmers on IBM i Blocking AS/400 DB2 users Trouble accessing IFS path from Win2k3 server Checking in on your IBM i authorization lists Strategies for securing IBM i production files Changing password security levels and upgrading operating systems on the IBM i Determine the value of parameter UPPWEI in the DSPUSRPRF field Define journal code value "K" Modify content within a journal receiver file

RELATED GLOSSARY TERMS Terms from Whatis.com − the technology online dictionary midrange  (Search400.com)

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary

ng 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 in a special library with the same name as the user profile. 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, contact me, I'll send the CL along and try to answer any questions you may have. 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.