Q:We want to restrict the access of one user profile to be able to sign on at one specific device only. The user profile should not be able to sign on to any other workstation. We created an authorization list named DEVICES and added the restricted user profile with *EXCLUDE authority. We then used that authorization list to secure all of our workstations except for the one the restricted user profile was to use. This worked well for existing devices, but new devices needed to be secured as they were created.
Is it possible to change the Create Device Display (CRTDEVDSP) command's default value for the authority (AUT) parameter to an authorization list name?
A:Yes. With the Change Command (CHGCMD) command, you can change the default value of the AUT parameter of the CRTDEVDSP command. This will secure new display devices with the authorization list.
However, do not change the command in library QSYS. Create your own version of the CRTDEVDSP in your own library (e.g., MYSYS) and then place the library in front of QSYS in the system portion of your library list. Then, the command defaults from your installation library will be used during the creation of devices. To create your own version, duplicate the IBM CRT-DEVDSP command and change the default to specify an authorization list on newly created devices.
Be sure to keep all changes to IBM commands in a CL program. When you install a new release, you may need to repeat the change of command defaults. This is important, even when you are using your own installation library such as MYSYS. The number of command parameters may change in the new release, and you will need to repeat the change of commands. Keeping all modifications to IBM objects greatly simplifies the release upgrade process.
One alternative to using the authorization list would be to change the initial program for the user profile. The initial program could check the device name and immediately sign off if it was not run from the correct workstation. This may be simpler than going to the trouble of creating a special library to contain customized commands, creating the customized commands, and naming an authorization list for every device.
Q:Our location uses the same user profile and password to start the Client Access router at the 200 PCs attached to our AS/400. What are the security ramifications of all users starting the router with the same profile? If all users use the same user profile, will it have a performance impact?
A: There is no performance impact for the same user profile being used to start the router. The major disadvantage of using the same user profile for each PC is there is no way to distinguish the users for file transfer purposes. System auditors do not like the use of shared user profiles because there is no individual accountability for actions when a large number of users share the same profile and password.
The use of the same user profile and password to start the Client Access router is often done so that the router startup can be automated through input redirection to avoid entry of the user profile and password. The following example illustrates the use of redirection to supply the user profile and password from the file SECRET.TXT.
STARTRTR < C:SECRET.TXT
I do not recommend this technique, but many AS/400 installations use it to simplify the startup procedures for the end users. The exposure is that anyone who can power on the PC will be able to start the Client Access router. At a minimum, I would recommend that the file that contains the user profile and password not be stored on the local hard drive (C) but instead be stored on a network server. Users will be required to sign on to the network before they are allowed to start the router. Storing the user profile and password on the network server also makes it easier to change the file that contains the profile and password. Making the change on 200 individual PCs is a very labor intensive effort.
If you are going to use a widely known user profile-such as PCUSER or GUEST-then you'll want to prevent users from being able to sign on to the AS/400 with the profile. The recommended procedure is to create the user profile in such a way that, if the user profile is used for an interactive sign-on, the user is immediately signed off. This can be done by specifying an initial menu of *SIGNOFF and no initial program.
CRTUSRPRF USRPRF(PCUSER) + PASSWORD(PCUSER) + INLPGM(*NONE) + INLMNU(*SIGNOFF) + LMTCPB(*YES)
In this situation, you should also prevent the user from getting access to the system request menu. The system request menu can be exploited to display information and messages that allow a hacker to break into your system.
I was conducting a security penetration test (i.e., getting paid to be a hacker), and I found a profile that had been created as shown above. When I signed on, I was immediately given a screen that told me my initial program had terminated and to press Enter to sign off. However, I used system request at that point and was able to display the messages for QSYSOPR and other user profiles. It took less than five minutes to find the name of another user profile that had a password that was the same as the user profile, and I had a command line.
To prevent specific users from seeing the system request menu, you must restrict their access to the QGMNSYSR panel group in QSYS. You can prevent a user from accessing QGMNSYSR by specifying *EXCLUDE authority.
GRTOBJAUT OBJ(QSYS/QGMNSYSR) + OBJTYPE(*PNLGRP) + USER(PCUSER) + AUT(*EXCLUDE)
I discovered another method (by accident) that is equally effective. If the user profile specifies an initial program that the user profile has no authority to, the user profile cannot be used to sign on, and IBM automatically blocks the system request menu.
CRTUSRPRF USRPRF(PCUSER) + PASSWORD(PCUSER) + LMTCPB(*YES) + INLPGM(NO_ACCESS) + INLMNU(*SIGNOFF)