Admin Alert: A Checklist for Creating OS/400 User Profiles, Part I

September 14, 2005 Joe Hertvik

As an OS/400 administrator, you are already well familiar with creating user profiles. But while user profile creation may seem obvious, there are a few subtleties you need to be aware of to ensure that every profile you create is fit for the job at hand. To that end, let’s review a checklist for gathering information when creating new user profiles on an OS/400-based machine.

User profiles can be created through two interfaces. You can use the green-screen Create User Profile command (CRTUSRPRF) or you can use iSeries Operations Navigator’s (OpsNav) user profile function. For this checklist, I’ll use the traditional CRTUSRPRF interface but all of these options are also configurable through the OpsNav interface. The examples also come from the CRTUSRPRF command found in OS/400 V5R3, so while the same basic strategy I discuss here applies to earlier versions, some of these parameters may be slightly different in prior releases.

This week’s checklist covers the configuration parameters that affect security and basic user profile configuration, allowing you to create functional and secure user profiles. The checklist does not, however, show you how to tweak a user profile to provide configuration adjustments that will allow the user to run a specific application, use a desired job description, or to create a home directory for IFS-based applications. Those items will appear in Part II of this checklist, which will be published in a future column.

That said, here are six specific checklist questions whose answers will help you create a functioning user profile on any i5, iSeries, or AS/400 system.

1. Will you assign a non-obvious password to your user profile or let the user decide what he wants his password to be?

By default, the Password parameter (PASSWORD) for a new user profile is set to the same value as the user profile name. When this happens, the user is said to have a default password. This is not a good situation for security and it should be changed as soon as possible. You have two options for securing new user passwords: you can either assign a non-obvious password to the user; or you can mark the user password as expired and force the user to change it himself the first time he logs in.

To assign a non-obvious password to the user, simply type in whatever password you want to assign to the user profile in the PASSWORD parameter of the CRTUSRPRF command, and then distribute the password to the user along with his user profile name. This situation is desirable in that the user profile will always contain a non-obvious password. Its drawback is that the password may have to be written down and passed between one or more users before the user initially signs on.

If you decide to mark a default password as expired, OS/400 will allow the user to start a system session with the default password, but then force the user to change the password before he can finish signing on and start using the system. You can do this by setting the Set password to expired parameter (PWDEXP) to *YES. The advantage here is that the user sets the password himself, and the password will not be known by anyone else but the user; the disadvantage is that the user profile could be sitting open with a default password on your OS/400 partition for several days or possibly much longer before the user gets around to finally signing on and changing it.

2. What user class will this user be assigned to?

In OS/400, you can assign a user to one of several user classes; user class is designated under the User Class parameter (USRCLS) of the CRTUSRPRF command. The user class you choose will determine whether the user has normal system authorities or whether they can perform additional tasks normally reserved for higher-level users. Your choices for user class are the following:

• User (*USER) – An ordinary user with no special system authorities.
• System Operator (*SYSOPR) – The user has the ability to perform system backups (*SAVSYS authority) and control system jobs (*JOBCTL authority).
• Programmer – The user has no special system authorities beyond that of a normal user.
• Security Administrator (*SECADM) – The user can create, change, or delete other user profiles.
• Security (*SECOFR) – The user possesses all system authorities, and he can perform any task on the system. But beware. Many shops are too loose with *SECOFR authority. In general, it should be reserved for one or two trusted people in the IT department and that’s it.

3. Should the user profile contain the default current library or should you assign a different current library for them?

A user’s current library is the first library in their library list, and it is set in the Current Library parameter (CURLIB) of the CRTUSRPRF command. The current library can be critical in that it is the OS/400 library where new objects are created if no other library is explicitly mentioned in a command. You can set a user’s current library to a specific library, or you can set it to the default current library by changing CURLIB’s value to *CRTDFT. Setting CURLIB to *CRTDFT sets the CURLIB parameter to library QGPL.

4. What (if any) programs should be run when the user signs on, and should the user be allowed to run OS/400 commands?

Depending on what type of user you are creating, there are various options you can select for the Initial Program to Call (INLPGM), Initial Menu (INLMNU) and Limit Capabilities (LMTCPB) parameters. These parameters define the programs and commands that green-screen users can run on your system; but there are also special settings for these parameters that are used for server users, who access OS/400 through remote connection technology rather than by starting a PC5250 screen.

Each of these parameters has a special function. The INLPGM parameter tells OS/400 the library and program name of the program to start when that particular green-screen user signs on. No parameters can be passed to this program. For server users who will never sign-on to the green-screen, you can set this parameter to *NONE.

The INLMNU parameter specifies the initial menu that is displayed when the user signs on and displays a command line on a PC5250 session. Setting it to ‘MAIN’ (the parameter default) displays the OS/400 Main Menu. You can change this parameter to any other menu command on the system, provided it can be called through the OS/400 command processor, QCMD. For server users, you can set INLMNU to *SIGNOFF, which allows the user to access OS/400 as a server user but which, in conjunction with the INLPGM parameter set to *NONE, will automatically log the user off if they try to sign on to a green-screen session.

The LMTCPB parameter does two things. First, it tells OS/400 whether users can change certain user profile values, such as the Initial Program, Initial Menu, and Current Library values after they sign on. And second, it tells OS/400 what type of command line access they can use. Setting LMTCPB to *NO means the user can change all their user profile values, change their Attention key program (ATTN), and run commands from an OS/400 command line. Changing it to *PARTIAL tells OS/400 that the user cannot change their user profile or ATTN values, but they can still run OS/400 commands from a command line. For the ultimate lockdown, changing LMTCPB to *YES tells OS/400 that the user cannot change his user profile and ATTN key values and he cannot run commands from a command line (but he can still select options from a menu). The *YES parameter secures your system from users running unauthorized commands. This parameter will have no effect for server users whose INLPGM and INLMNU parameters are set to *NONE and *SIGNOFF, respectively.

5. What other special authorities should the user have?

In OS/400 and i5/OS, special authorities are given to users to allow them to perform certain restricted functions on the system. These authorities are assigned in the Special authority parameter (SPCAUT) of a user profile. Special authorities work hand-in-hand with the profile’s user class assigned in point 2. User profiles with a user class of System Operator (*SYSOPR) are automatically assigned the special authority to save and restore system objects and to control system jobs. Users who are designated as Security Officers (*SECOFR) can perform any and all restricted functions on the system. For all other users, you can assign one or more of the following special authorities to a user profile:

• All object (*ALLOBJ) authority allows the user to access any system resource, regardless of whether or not they are explicitly authorized to use that object. Because *ALLOBJ basically gives users carte blanche to update any item on the system, this special authority should be given out only on a need-to-have basis.
• Audit (*AUDIT) allows the user to perform all auditing functions on the system, including turning on and turning off auditing.
• Job Control (*JOBCTL) allows the user to perform any function (change, hold, delete, release, etc) on any jobs that are currently running on the system or for jobs that are sitting in a system job queue. In addition, the user has the ability to start OS/400 writers and remote output queues, and to stop active subsystems. Like *ALLOBJ, you may want to restrict access to *JOBCTL authority.
• Save system (*SAVSYS) authority allows the user to save, restore, or free storage for all objects on the system, regardless of whether or not the user has object management authority to those objects.
• Input/output (I/O) system configuration authority (*IOSYSCFG) gives the user the ability to change system I/O configurations.
• Security Administrator authority (*SECADM) allows a user to add, change, or delete user profiles on the system. The user must be authorized to the user profile commands (CRTUSRPRF, DLTUSRPRF, and CHGUSRPRF) to use this authority. The catch here is that a security administrator user cannot assign any special authorities to another user that it does not itself already have.
• Spool control authority (*SPLCTL) allows a user to work with printers and writers.

6. How often should the user be forced to change their password?

The Password expiration interval parameter (PWDEXPITV) tells OS/400 how often (in days) the user should be forced to change their password. If the user has not changed his password by the end of the PWDEXPITV interval, the user profile password will automatically expire. OS/400 will give the user several chances to change his password, so if the password is allowed to expire, it’s the user’s own fault. Here are the values that you can set PWDEXPITV to.

• Any number between 1-366 days. If password expiration is set for a user, OS/400 will not allow passwords to remain active for more than one year.
• No expiration date (*NOMAX) tells OS/400 that the password will remain active forever unless the user voluntarily changes it or the system administrator changes it.
• Use the Password Expiration Interval system value (*SYSVAL). This setting tells OS/400 to use the value for password expiration days found in the Password expiration interval system value (QPWDEXPITV). This is the default value for the PWDEXPITV parameter. If you decide to use *SYSVAL, check what value QPWDEXPITV is set to, because OS/400 sets the password expiration interval system value to a default value of *NOMAX.

After you answer these six questions, you will have all the information you need to get a basic user profile up and running on the system. In the next column, I’ll cover some standard user profile customization parameters that you may need to set up to allow a user profile to access specific applications and perform specific functions.