Newsletters   Subscriptions  Forums  Store   Career  Media Kit  About Us  Contact  Search   Home 
fhg
Volume 5, Number 36 -- September 28, 2005

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


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

Sponsored By
PROFOUND LOGIC SOFTWARE

Make Your iSeries Come Alive With
RPG-Alive and RPGsp

RPG-Alive
- Instantly improves developers' productivity
- Real-time Code Analysis & Syntax Highlighting
- Downloads and installs in 1 minute

RPG Smart Pages (RPGsp)
- Effortlessly build any type of Web Application
- Hundreds of Wizards & Templates
- Use Advanced Graphical Environment
- Receive Free RPG to Web Conversion Tool
- Free RPG-Alive Indenter and GUI included!

www.profoundlogic.com


Technical Editors: Howard Arner, Joe Hertvik, Ted Holt,
Shannon O'Donnell, Kevin Vandever
Contributing Technical Editors: Joel Cochran, Wayne O. Evans, Raymond Everhart,
Bruce Guetzkow, Marc Logemann, David Morris
Publisher and Advertising Director: Jenny Thomas
Advertising Sales Representative: Kim Reed
Contact the Editors: To contact anyone on the IT Jungle Team
Go to our contacts page and send us a message.


THIS ISSUE
SPONSORED BY:

T.L. Ashford
WorksRight Software
Profound Logic Software


Four Hundred Guru

BACK ISSUES

TABLE OF
CONTENTS
API Corner: Database APIs

SQL Record Selection with Dynamic Lists

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


The Four Hundred
iSeries Execs Talk Up the Future of the Platform at COMMON

COMMON Sound Off: Frustration Level Is Down a Bit Among the Faithful

Oracle to Support IBM's WebSphere with Project Fusion Apps

Mad Dog 21/21: New Moth

Four Hundred Stuff
Quadrant Unveils IntelliChief for Paperless Process Management

Web-based Document Management Gets the RJS Treatment

Linoma Bolsters Security of iSeries Database Tool

MaxAv's New Wizard Simplifies Remote Journaling Setup

Four Hundred Monitor


Copyright © 1996-2008 Guild Companies, Inc. All Rights Reserved.
Guild Companies, Inc. (formerly Midrange Server), 50 Park Terrace East, Suite 8F, New York, NY 10034
Privacy Statement