The QRETSVRSEC (Retain Server Security Data) system value determines whether security data needed by the AS/400 to authenticate a user on a target system through the client/server interfaces can be retained on the host system. If not, the server will prompt the user for an ID and password when authenticating the user for the target system. If the security data can be retained, the server will use the retained security information to perform the authentication process. The FFQRETSVRSEC system value will be used for TCP/IP, Novell Netware, and Lotus Notes client/server interfaces.

Now, let’s look at each of the five system security levels, starting with the lowest.

Level 10 — No Security

Level 10 is the lowest level of system security available. Level 10 represents a nonsecure system. No password is required to access the system, and all users have access to all system resources. This security level does not restrict access to any system object. The users are, however, prevented from affecting the jobs of other users on the system.

When only physical security, such as a lock on the computer room door, is needed, a system security level of 10 can be specified. Any user who has access to the system can sign on and use the system. That user does not need to be enrolled. To be enrolled in a system means a user profile for the user exists somewhere in the system. If a user profile does not exist, one is automatically created when level 10 security is specified.

Level 20 — Password Security

When your situation requires only sign-on security, you can specify level 20. This level requires the AS/400 user to be enrolled and to enter a valid password to gain access to the system. Once access to the system is granted, users are not restricted from using any system resources. This is similar to level 10 security, except a password is initially needed to gain access.

One special case exists to limit a user’s access to the system at level 20. A user profile can indicate that the user is a limited-capability user. A limited-capability user is limited to selecting options from menus. Most of the system menus have a command entry line, and an installation can restrict the use of commands on these menus.

Suppose, for example, we have a group of system users in our business who are responsible for taking orders for our products and entering those orders into the system. We may elect to create a special menu for these users and let them perform only business functions they can select from this menu. We can accomplish this by enrolling these users as limited-capability users and specifying in their user profile the initial menu for them to use.

But even for a limited-capability user, some commands are necessary. The system allows this user to execute four commands: to send messages, to display messages, to display job status, and to sign off. The user commands and system commands available to the limited-capability user can be individually defined. Limited capability also determines which fields the user can modify at sign-on.

We describe both levels 10 and 20 as nonsecure systems, because once the user is into the system, almost anything goes. We do not recommend using either of these levels except for special circumstances where the system has very limited access from the outside.

Level 30 — Resource Security

The minimum level of security we recommend is level 30. At level 30, the AS/400 user must be enrolled and must enter a valid password to gain access to the system — the same as with level 20. Once access to the system is granted, resource security then requires a user to have the authority to access the system resources; unauthorized access is not allowed. In addition, a user can be enrolled as a limited-capability user under level 30 security.

Individual users can be authorized to use system objects, such as files, programs, and devices. Shortly, we will see how the user profile provides the capability to give users the authority to system objects. We also will look at other ways a user can access system objects using group and public authority.

Level 30 was the highest level of security available on the System/38. This level of security didn’t distinguish between a user object and one that was used only by the operating system. With the aid of the MI assembler available on the System/38 and some mappings of the internal structure of objects, a major problem began to develop. ISVs were beginning to write application packages that were dependent on the internal object structures, which was beginning to violate the technology independence of the MI.

For the initial version of the AS/400, this same level of security was carried over. Even though there was no MI assembler for the AS/400, and we didn’t publish information on the internals, it didn’t take too long for people to realize the AS/400 was a System/38. So programs that were dependent on the internal object structures worked on the AS/400.

We knew that we had requirements for even higher levels of security on the AS/400 as we moved into client/server computing, and that these higher levels had to block access to many of the internal objects. We also knew that we were going to change these internal structures, especially as we moved to RISC. But if we implemented just the higher level of security on the AS/400, those programs that tried to access system object internals would no longer work, causing problems for many of our customers.

We announced that we would implement a new level of security at V1R3, and that the new level would no longer allow access to the internal objects. We also began to seek out the ISVs who were using the internal objects. We wanted to provide them with standard system APIs they could use to get the information they needed for their programs.

Most of these programs were utilities that used the information in some field inside a system object. A tape-management system, for example, may have needed some additional information about the tape header. The only way to get this information was to go into a system object. We created hundreds of APIs to provide this needed information across the MI, and we guaranteed these APIs would always work in future releases of the operating system. Essentially, these APIs were new MI instructions. We were then free to make changes under the covers.