IBM AS400 (I-Series) Key Controls for User Accounts

Wednesday, November 09, 2011

Kevin Somppi


In 1988, IBM introduced the AS400 platform as a mid-range small business processing solution. 

The AS400 later became known as the I-SERIES.  There are more than 30,000 applications for the I-SERIES, many of which are programmed in RPG III. 

It is used in a variety of networking configurations, including as a host or intermediate node to other I-SERIES systems, as a remote to mainframe networks, and as a network server to network workstations. 

The I-SERIES can support many networks, each with hundreds of clients.

There is continued use of this platform in both small and medium sized companies.  Hackers continue to have an interest in medium size companies, as reported in this USA Today article - .

To protect your network, security must also be applied to the I-SERIES platforms.  So we start with the basic controls, the first steps to securing your I-series platform. 

Understand and document all methods used to access the I-SERIES platform; users may have unauthorized access to the environment through an alternative access method.  Policies and procedures should be fully documented for adding users and granting access, handling of terminated user accounts, as well as changes to existing access. 

Obtain a listing of all user profiles on the system by user and group profile.  Verify that all user IDs are for valid current employees.  There are many system account IDs which start with Q, (e.g., QLPAUTO, QLPINSTALL, QSPL, QRJE, QFNC, QGATE, QPGMR, QSRVBAS).  These should all be set to NONE or the vendor supplied passwords should have been changed. 

Two additional system IDs which carry significant authorities are: QSECOFR and QSYSOPR and should have the passwords changed as well.  Also determine which user profiles have been granted special authorities, which are QSECOFR, ALLOBJ, SECADM, SAVSYS, JOBCTL, SERVICE, SPLCTL, and AUDIT. 

Special authorities should only be granted to system or security administrators.  If normal users require special authorities for job related functions, the need should be reviewed closely and approved by management.

It is also important to know which users have object authority to the sensitive system commands.  Some examples of these commands would be:  ADDAUTLE, CHGAUTLE, CHGDTA, CHGNETA, CHGOBJOWN, CHGSYSVAL.  A complete listing of these commands can be found in your system documentation.

In conclusion, it is impossible to prove that a platform or program has no bugs; however, if you take the time to reasonably test and find the obvious vulnerabilities and remediate them, and challenge the access which your user community has been granted, you stand a better chance of not being compromised.

Possibly Related Articles:
Network Access Control
Information Security
Access Control Network Security hackers Authorization SysAdmin IBM AS400 IBM I-SERIES
Post Rating I Like this!
I-SERIES IBM I had to double check the publication date, because this reads like it was written 10 years ago.

First, the platform was never spelled with a hyphen, nor was it ever all caps. No one in the history of the midrange platform ever called it the I-SERIES. Right away, the red flags go up as far as the experience of the author.

Second, the hardware has been called Power 6 or Power 7 for years. The OS is called IBM i. RPGIII has been moribund for at least a decade. Again, this calls the experience of the author into question.

Aside from the seeming antiquity of the piece, there are outright errors. Special values are all preceded with an asterisk in the IBM i world. So the value for 'no password' is not NONE (as stated) but rather, *NONE.

There is no special authority QSECOFR.

The IBM manuals are online at:

In an editorialist vein, I found the final paragraph incongruous. Writing of a 'conclusion' that a bug free system is impossible after discussing 'out of the box' security was jarring.

A disappointing article.
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.