Admin Alert: Making OS/400 User Profiles a Little More Secure

by Joe Hertvik

One of the weakest points in any computer system is how companies secure their user profiles. These are the passports hackers and unauthorized users highjack in order to cause major damage, and they are the system entry points you most need to secure. While you can never lock down every single security vulnerability, here are five OS/400 system value security tips that you can use to create a stronger user security environment.

Note that all of these tips involve changing OS/400 system values. On the green-screen, you can view and change these values by typing in the Work with System Values (WRKSYSVAL) with the Security (*SEC) subset, as follows:

WRKSYSVAL SYSVAL(*SEC)

Inside Operations Navigator, many of these values can be found in the OpsNav Security/Policies/Sign-on Policy dialogue. OpsNav names and descriptions for each system value are noted in these explanations:

• Set the systems values for maximum sign-on attempts allowed (QMAXSIGN) and what action to take for failed sign-on attempts (QMAXSGNACN) correctly. For OpsNav, these values can be found as radio buttons and a drop-down box in the "incorrect sign-on attempts" area of the "sign-on policy" dialogue box. QMAXSIGN specifies the maximum number of invalid sign-on attempts that OS/400 permits for a particular device or user before the system takes action to handle the intrusion. You can set QMAXSIGN to any number between 1 and 25, or it can be set to *NOMAX, which disables invalid sign-on checking. If you set QMAXSIGN between 1 and 25 and an intrusion occurs, the system will take the action specified in the QMAXSGNACN system value. That action will then be taken against the intruding device, the user, or both. If QMAXSGNACN is set to 1 (disable device for OpsNav), any intruding device will be disabled after it violates the QMAXSIGN threshold. When QMAXSGNACN is set to 2 (disable user), the user profile used for the invalid sign-on attempts will be disabled after it breaks the threshold; a value of 3 (disable user and device) will disable both the offending user profile and the offending device. Most security experts generally recommend setting QMAXSIGN to a value less than five and QMAXSGNACN should be set at 2 or 3, with 3 being the best practice. Because of the easy availability of Telnet 5250 sessions and the fact that a hacker can easily create a new session if his existing session is disabled, I don't recommend a QMAXSGNACN value of 1. Shipped values are 3 for QMAXSIGN and 3 for QMAXSGNACN.
• Consider whether you want to set the "limit device Sessions" (QLMTDEVSSN) system value to 1, rather than the default value of 0. For OpsNav, this value is contained in the "limit each user to one device session" checkbox on the "sign-on policy" dialogue. QLMTDEVSSN controls whether the same user profile is allowed to sign on to more than one device at a time. When set to 0, a user can start several Telnet sessions at several different terminals at the same time. Setting it to 1 limits the user to one terminal session at a time, eliminating the chance that two users will share the same user profile. After signing on, the only additional jobs that can be started for that user are group jobs and system requests originating from the same terminal. The shipped value is 0.
• The "limit security officer" (QLMTSECOFR) system value restricts privileged users--any user that has *ALLOBJ or *SERVICE authority--to specific workstations. In OpsNav, QLMTSECOFR can be found in the "restrict privileged users to specific devices" checkbox on the "sign-on policy" dialogue screen. QLMTSECOFR can be set to either 0 or 1. When set to 0, privileged users can sign on to any workstation. Setting QLMTSECOFR to 1 restricts privileged users from signing on to any terminal for which they don't already have specific authorization. QLMTSECOFR has a limited effect when a privileged user is signed on to the system console. The shipped value is 1.
• The "password expiration interval" (QPWDEXPITV) system value tells OS/400 how many days are allowed before a user is forced to change his password. In OpsNav, "password expiration" is found in the "Expiration" tab of the "password policy properties"; password policy properties can be found by following the OpsNav Security/Policies/Password Policy path. You can set QPWDEXPITV to an expiration interval of between one and 366 days, or you can set it to *NOMAX, which specifies that OS/400 passwords will never expire and users will not be forced to change their passwords. The default value is *NOMAX, so unlike some of the other security system values, QPWDEXPITV must be activated with an expiration interval before it can be used. Best practices call for a password expiration interval of less than or equal to 90 days. Be aware, however, that there is also an individual "password expiration interval" parameter (PWDEXPITV) inside each OS/400 user profile that also specifies how many days will pass before that individual user is forced to change his password. If there is no PWDEXPITV value specified for a user profile, the profile will use the QPWDEXPITV system value for its expiration properties. If a user profile has a PWDEXPITV parameter that is different from the QPWDEXPITV system value, the PWDEXPITV parameter will take precedence over QPWDEXXPITV.

In addition to these system values, you may also want to investigate the "remote sign-on control" system value (QRMTSIGN), which controls how the system handles remote sign on requests. (QRMTSIGN can also be found in the OpsNav Sign-On Policy Properties). In addition, there are the interactive job message queue (QINACTMSGQ) and disconnect job time-out interval (QDSCJOBITV) system values for ending or disconnecting inactive OS/400 terminal sessions.

For more information about finding and manipulating QINACTMSGQ and QDSCJOBITV, refer to the three Admin Alert articles about disconnecting interactive jobs:

"Dealing with Inactive Jobs"

"Readers' Insights on Inactive Jobs and QSTRUPJD Job Logs"

"Configuring PC5250 for Inactive Job Disconnection"

Sponsored By ITERA

Reorganize While Active! Now you can recover deleted record space without locking users out of your files when you reorganize them. With iTera's new Reorganize While Active™ solution, you can reorganize any size file with just a few seconds of downtime--whether the file is 5 GB in size or 100 GB! Want to help your company eliminate downtime? Email us at info@iterainc.com or call 800-957-4511 or visit us at www.iterainc.com