Admin Alert: Limiting the Long Reach of OS/400 Security Officers

September 28, 2005 Joe Hertvik

It almost goes without saying that i5/OS and OS/400 administrators should limit the number of users who have security officer authority (SECOFR). In the wrong hands, SECOFR users can delete files, manipulate information for ill-gotten gains, corrupt system configurations, and compromise organizational and customer secrets. So as a general operational principle, the fewer people who possess security officer access, the better.

But in some organizations, it isn’t enough just to limit the number of people who are security officers. You may also be required to limit where and when the few security officers you do have can sign on. This is particular true in high-security environments where unauthorized access can cause true disasters and higher security standards must be adhered to. At the very least, you may want to prevent security officer users from logging in from multiple locations, logging in from remote locations, or restrict where they can change security and control settings. To that end, here are two techniques for limiting when, where, and how often a security officer can sign on.

• Limit the number of devices a security officer can sign on to at one time. In OS/400, user profiles contain a parameter called Limit Device Sessions (LMTDEVSSN). When LMTDEVSSN is set to *NO, a user can start multiple and simultaneous OS/400 device sessions on your machine from literally any device in the world, or at least those devices that are accessible to your machine via cabling, a network to the Internet, or a wireless connection. But LMTDEVSSN can also be set to *YES, which tells OS/400 that this particular user can only log on to one session at a time on your target partition. By turning LMTDEVSSN on for SECOFR users, you can eliminate the possibility that two people can sign on at the same time from different locations with the same SECOFR user profile.
• Limit the actual devices that a security officer can sign on to. OS/400 also contains a system value called Limit Security Officer device access (QLMTSECOFR). When set to ‘1’ (Limit), QLMTSECOFR limits which devices a security officer user profile can sign on to, forcing SECOFR users to only log on to the system console or to another device for which they are explicitly authorized.

Here’s a couple of different ways to make it work.

1. You can turn on QLMTSECOFR by using iSeries Operations Navigator or by using the green-screen Change System Value command (CHGSYSVAL) as follows:

CHGSYSVAL SYSVAL(QLMTSECOFR) VALUE(‘1’)

Once activated, QLMTSECOFR takes effect immediately for all users who have security officer access, which IBM defines as any user who has All Object (*ALLOBJ) and Security Administrator (*SECADM) authority. It does not affect any sessions where a SECOFR user had already signed on before the system value was changed.

2. Without explicitly authorizing SECOFR users to any other devices, these users can only sign on to your partition’s system console. This is a very practical default consideration that prevents your SECOFR users from being cut-off from the system entirely when this feature is activated. QLMTSECOFR protects your SECOFR passwords from falling into the hands of a malicious user who might hack, overhear, or guess those passwords. By forcing you to explicitly authorize SECOFR users to specific devices, you are locking down the SECOFR user profile use so that it is less likely to be abused by the wrong people.

3. To explicitly authorize a SECOFR user to use a specific device, you have to use the Work with Objects (WRKOBJ) command because there is no option to change object authorities from the Work with Device command (WRKDEVD). In my experience, you need to do the following steps to authorize a user to a specific device from the green-screen.

• Bring up the device and all its associated devices by using the WRKOBJ command, as follows:
  WRKOBJ OBJ(*ALL/device_name*) OBJTYPE(*DEVD)

• Where device_name is equal to the name of your device. In this example, I placed a wildcard asterisk (*) behind the device name so that–in addition to bringing up the core device name you are trying to authorize the user to–it would also show any variation device names that the SECOFR user may also need to sign on to. For example, if you were trying to authorize the user to sign on to a Client Access or iSeries Access PC5250 session named ‘JOE’, you might need to authorize the user to other devices named ‘JOEA1’, ‘JOEB1’, ‘JOEC1’, etc. This is because IBM‘s Client Access PC5250 program contains settings to automatically create and use new device names when requested or when a conflict occurs.
• Once the WRKOBJ command shows you all the devices you requested, place a ‘2’ in front of each device that you want to authorize your SECOFR user to. This brings up the Edit Object Authority command (EDTOBJ) for that device, showing you which users are already explicitly authorized to the device and what authority they have. What you’ll see on the authorization list for most devices is that *PUBLIC has *CHANGE authority while a few other users, such as QTCP (the TCP/IP user) and QSYSOPR (the system operator), have *ALL authority to that device.
• Assigning explicit authority to your SECOFR users is important because QLMTSECOFR tells OS/400 to ignore the device’s *PUBLIC authority for security officers and to only let a SECOFR user sign on to that device if they have explicit authority to do so. Otherwise, QLMTSECOFR prevents them from signing on. To add a SECOFR user (or users) to a device’s authority list from the EDTOBJ screen, press F6 (add new users) on that screen and add any SECOFR user that you want to the list of authorities for that device, giving each SECOFR user you add an object authority of *ALL.

Once you follow these steps, your SECOFR users will only be authorized to the system console and to those devices for which you have explicitly given them authority to.

So if your shop requirements call for enhanced restrictions on where and how you can use a security officer user profile, these two techniques can help you fill the bill.