Network Attributes and IBM i Security

By Rich Loeber

Protecting your IBM i system from network users can be a daunting and challenging task. This tip will give you a few basics about it and, hopefully, get you thinking about this issue.

In the good old days, the IBM i (then called AS/400) was a closed system with the only connections to other systems being dedicated telephone lines running IBM's SNA protocol. Control over access from remote users was pretty easy given this environment. Then, along came networks and the Internet and this all changed. Soon, every IBM i on the block came with an Ethernet card and TCP/IP enabled. PCs running PC Support (aka: iSeries Access) replaced dumb terminals and emulation cards and the IBM i became a much more open system.

Now, many users with iSeries Access, can use upload and download utilities to access data on your system and even do entry and updates directly from these utilities. In fact, many installations have embraced these technology changes and implemented solutions with these capabilities in mind.

But, with the opening up of the system, new security considerations come into play. Consider the classic situation of a payroll clerk running your company's payroll application from their trusty old green screen application. Using secure menu design, you can implement a system that easily restricts this user's access to the payroll files. However, the IBM i security for these files will probably be *USE or *CHANGE to allow this user to process updates. If this user were to experiment with the iSeries Access utilities for download, that level of permission would allow them to quickly and easily download the entire payroll file to their PC, make changes and then upload it back to your system. That is most probably something that you never had in mind when security was first envisioned for this application.

So, as the security officer, what's a person to do?

For starters, there are some simple network attribute settings that you can use to implement controls. You can view the network attribute settings on your system using the Display Network Attributes (DSPNETA) command and make changes using the Change Network Attributes (CHGNETA) command. The three network attributes that I want to direct you to in this tip are:

• Job action (JOBACN)
• Client request access (PCSACC)
• DDM request access (DDMACC)

The Job action setting controls how the system will process remote requests to run jobs. It has three settings which are *REJECT, *FILE and *SEARCH. The default setting from the factory is *FILE. If you are concerned about this, just change the default setting to *REJECT and you're safe. When it is set to *FILE, the incoming request is queued to a network file for the designated user and the job must then be reviewed and started by the user. *SEARCH sets up a search of the network job table, but that is a topic for an entire tip by itself.

The PCSACC parameter (which has its roots in PC/Support, the early version of Client Access/iSeries Access or whatever name it goes by today), controls how a PC will have access to objects on your system. This has no bearing at all on the use of the workstation emulator, it is just for object access for the various iSeries Access functions like download, etc.

The possible values for PCSACC are:

• *REJECT - all object requests are rejected regardless of what they are.
• *OBJAUT - OS/400 object authority is checked and supported (the default setting).
• *REJFAC - the system checks for a registered exit program and passes authentication to the exit program for processing.
• program name - the registered program name is called to verify authentication.

If you just don't want anyone to have object access, then change this parameter to the *REJECT setting. In this day and age of platform integration, this will often not work for you, so you'll have to explore the other options. On the surface, *OBJAUT sounds like a good choice, and for many shops it will work nicely. However, this means that any user profile that is authorized to process and/or update files from an interactive application could also have full access from the iSeries Access side, which may not be ideal for maximum security. Using a program name or a registered exit point is the best method, but implementing exit point processing is a daunting challenge and much too much for a simple tip article. I'd recommend that rather than create your own exit programs, you consider purchasing one of the many good third party solutions that are available in today's market including SafeNet/i from Kisco Information Systems.

The DDM Request Access setting decides how to handle security from remote systems requesting data using the Distributed Data Management functions. These can be from PCs or from other DDM compatible platforms such as other IBM i systems or even mainframes.

The possible values for the DDMACC are similar to those for PCSACC with the exception that *REJFAC is not offered. The same advice for this applies as for PCSACC. The program name option provides the only "exit point" available to control DDM access.

If you have any specific questions about this topic, you can reach me at rich at kisco.com. I'll try to answer your questions. All email messages will be answered.