Limiting Security Officer Access

By Rich Loeber

A reader recently posed the following question to me:

"How can I limit the places a person can log on as QSECOFR? I don't want someone to be able to log in from any desktop or workstation as QSECOFR other than the main console. Are there system values related to the QSECOFR profile?"

The special user profiles on your system that are set up as security officers really do have the keys to the kingdom when it comes to accessing your system. No files, programs, data objects, files in the IFS, and more are safe from access by someone who is logged onto your system from one of these user profiles. Keeping these profiles limited to certain devices is a good objective so that someone using them will be under direct supervision.

The best way to approach this is through a combination of object security configuration on your terminal device descriptions along with a varied setting for the system value QLMTSECOFR. Your system will come from the factory with this system value set to '0' which lets anyone with *ALLOBJ authority sign on to any terminal session. Changing this to '1' will only let the security officer signon to a terminal session where they have specific authority granted at the device description level.

But --- WARNING WARNING WARNING --- don't go rushing off to make this change! You must first get it set up and test it before adopting it as practice could result in your security officer profile getting permanently locked out of your system, and you don't want that situation on your hands.

So, your first step is to identify the device description object for your system console and make sure that QSECOFR is expressly granted permission to use the object (ie: *ALL authority). The device descriptions on your system are all stored in the QSYS library with object type of *DEVD. You can make changes in the authorities for the object using the Edit Object Authority (EDTOBJAUT) command. When your console device has been updated, find the backup console device description too (on most systems, it is called QCONSOLE) and do the same thing there.

To test this setup, first sign on as QSECOFR on a normal terminal session and leave that active for the duration of your test. That way, if things go south on you, you still have an active security officer session to fall back on to make changes. With this backup session active, make the changes to the system value and the device descriptions. Vary the console device off and then back on too to make sure you're using the updated authorities for the device. Then, make sure that you can sign on from the console using the security officer profile.

Assuming that all is OK, you'll need to scour your system for the other terminal device descriptions to make sure that the security officer profile is not authorized for any of them. Once this is done, then try to sign on as the security officer on another terminal, it will be denied.

Only when you're satisfied that everything is working as planned should you release the security officer session that you've been holding open as your back door.

If you have specific questions about this topic, you can reach me at rich at kisco.com. All email messages will be answered.