Admin Alert: Three Ways to Tighten OS/400 Security

September 15, 2004 Joe Hertvik

No matter what type of OS/400 shop you run, chances are good you can tighten your password and sign-on security. On i5, iSeries, and AS/400 boxes, this is a relatively easy thing to do; you just need to know your options and set security values accordingly. To that end, here are three easy ways that OS/400 can help you to tighten your system security.

Before starting, I should note that these values can be changed either through a green-screen 5250 session or through the graphical iSeries Navigator interface (still sentimentally referred to as OpsNav). To view and change these values on a green screen, use the Work with System Values (WRKSYSVAL) command to display or change all security-related system values (*SEC) on your system, like so:

WRKSYSVAL SYSVAL(*SEC)

These values can also be changed in OpsNav by following the Security, then Policies, path for your particular machine and then working with the Password Policy or Sign-On Policy panels under that path.

Given that, here are three OS/400 features you can take advantage of for tighter security.

Limit which devices OS/400 security officers can sign on to (OS/400 system value QLMTSECOFR). This value determines whether users with all object (*ALLOBJ) or service (*SERVICE) special authorities can sign on to any device connected to an i5, iSeries, or AS/400 machine. When set to 0 (off), users with security officer access can sign on to any device attached to their machine. When set to 1 (on), a security officer user profile must be granted explicit authority to a device in order to sign on to that device. If the user is not authorized, OS/400 will not let him sign on. This value can also be set under the Restrict privileged users to specific devices checkbox on the General tab of the OpsNav Sign-On Policy Properties panel.

Setting this value is a good idea for organizations in which system access is open to a large number of remote users or there are a lot of terminal sessions running in unsecured areas. But this technique does have its drawbacks. First, each individual security officer profile, not a group profile, must be authorized to each device it can use. This means that you have to plan and configure as many authorizations as necessary for each device a security-officer-enabled user profile may use. While good OS/400 security usually specifies that security officer access is limited to a few users, this could still produce be a fair amount of configuration work for even a few users.

A second drawback is that in many organizations, particularly in smaller shops, the users with security officer access are often the people who provide technical support throughout the company. They may need to sign on at any number of terminals to perform system maintenance. Limiting their access might also limit their ability to help people on the fly.

Another problem is that iSeries Access and Client Access configurations can work against QLMTSECOFR implementation. When PC5250 sessions are configured to avoid duplicate names on a workstation or on the network, PC5250 can create and use variations on the device name when the user starts a session. As a result, you could need to authorize your security officer to each variant device name that PC5250 might create.

It’s also worth noting that IBM defines security officer access fairly narrowly for this system value. QLMTSECOFR only covers users with ALLOBJ and SERVICE access; it does not cover users who have security administration authority (*SECADM), or those who can create, change, or delete user profiles. So while this value protects against those who would delete data or change the system, it doesn’t cover those who would create or modify user profiles.

Check your system and individual password expiration values (OS/400 system value QPWDEXPITV (this setting is also enabled under the Expiration tab of the OpsNav Password Policy Properties panel). QPWDEXPITV defines how long a user password is valid, and it can be set between one and 366 days. The shipped value is *NOMAX, which means passwords never expire if you don’t change them. You should also be aware that individual user profiles have password expiration intervals of their own, which are specified in the profile’s Password Expiration Interval (PWDEXPITV) parameter. While many user profiles’ PWDEXPITV value is set to *SYSVAL, which defaults to the QPWDEXPITV system value for their expiration interval, some individual user profiles may be set with their own *NOMAX expiration value. So it’s worth checking the QPWDEXPITV system value, as well as your user profiles, to determine at what intervals system passwords should expire. While checking individual profiles for *NOMAX expiration values can be a drag, the job becomes easier if you create a user profile information file (as outlined in “The Joys of Creating User Profile Information Files”).

Review all system values that deal with password composition and validation in order to force users to create more secure passwords. The following system values force users to create a harder-to-hack password or pass phrase. (All of these values are available under the green-screen OS/400 security system values or under the Validation tab in the OpsNav Password Policy Properties panel.)

• Requiring at least one digit in the password (system value QPWDRQDDGT) forces users to insert a number into any new passwords they create, which blunts the effect of using common words as passwords. However, what sometimes happens is that a user who wants to use a pet name as a password, such as “fluffy,” will simply add a number to the end of the common password to turn it into something that is different but is still easy to guess (like fluffy1, fluffy2). Used wrongly or by itself, this password could weaken your protection system. The default value is 0 (off). OpsNav lists this setting as Require at least one digit.

• Duplicating password control (system value QPWDRQDDIF) sets limits on how long users must wait before they can reuse an old password. The default is 0 (after one use), meaning that a new password can be the same as the password it replaces. Using this value, you can require that a new password be different from the previous four, six, eight, 10, 12, 18, 24, or 32 passwords the user has selected. This value is listed as Password re-use cycle in OpsNav.

• Limiting characters in a password (QPWDLMTCHR) is unusual, in that you can prevent specific letters or characters from being used in a password. For example, you could prevent the use of common words as passwords by restricting your users from using vowels in new passwords. The shipped value is *NONE (any valid character can be used in a password). OpsNav lists this value as Restricted characters.

• Requiring a minimum length for each password (QPWDMINLEN) forces passwords to be a certain length. The default minimum length is six characters, but you can increase the minimum length all the way up to 128 characters. Minimum and maximum password length values are also included in the Password Policy Properties panel.

• Limiting password character positions (QPWDPOSDIF) limits the use of the same characters in the same position they occupied in a previous password. This system value was specifically designed for users who like to use variations on a spouse’s name or other words that are easy to guess. This would stop someone from using “fluffy1” as a successor password to “fluffy,” because the system wouldn’t allow the letters f-l-u-f-f-y to occupy the same positions in the new password as they did in the old password. However, it’s been my experience that this value sometimes frustrates users who are blocked from picking a different password because many words have the same characters in the same positions. In OpsNav, this value is referred to as Require a new character in each position.

• Limiting adjacent digits in a password (QPWDLMTAJC) is handy because it stops users from using dates, office phone extensions, or home addresses in their passwords. The default value is 0 (off). OpsNav calls this value Restrict consecutive digits.

• Limiting repeating characters in a password (QPWDLMTREP) stops users from being lazy and choosing easy-to-guess passwords that contain the same letter over and over again. When this value is set on, any valid character can be used only once in a password. Look for the Restrict Repeating Characters drop-down box in OpsNav to set this value.

STRIKING A BALANCE

I’ve found that the key to using these settings is to balance the need for secure passwords against user frustration in creating and remembering passwords. You don’t want to limit user options so much that the only way they can remember their new passwords is by taping them to their monitors. So set these setting carefully, according to the needs of your organization, but beware that there will always be some pitfalls along the way.