Creating User Profiles on the IBM i

Before a user can sign on and use the IBM i, a user profile must be created and assigned to the user.

We create user profiles using the Create User Profile command, CRTUSRPRF. Only the security officer profile, QSECOFR, or another profile that has security administrator special authority, *SECADM, can create, change, or delete user profiles.

The user profile parameter, USRPRF, is the only required parameter and is meant to hold the user profile name decided on for the new user. For example, to create the user profile THX1138, we enter the command CRTUSRPRF USRPRF(THX1138). We can then verify that the user profile has been created by issuing the command DSPUSRPRF USRPRF(THX1138). Doing this, we can see that there are in fact a cornucopia of options for creating and defining a user profile, which in this case were filled out using the defaults for the CRTUSRPRF command.

A password is assigned at the time of creation of the user profile. The Password parameter, PASSWORD, allows us to set a password for a new user. The default value for this parameter is *USRPRF, which dictates that the password be the same as the user profile name. The *NONE special value makes it so that the user cannot in fact sign in to the system; this is recommended for workers who have are on vacation, or have recently left the organization. For example, to create a user profile, LASERVAULT, that cannot be logged in to, we would issue the command CRTUSRPRF USRPRF(LASERVAULT) PASSWORD(*NONE).  

To test this, let’s issue the SIGNOFF command to sign out of our current user profile. At the log in screen, first we attempt to log in as the LASERVAULT user, where we are greeted with the message “No password associated with user LASERVAULT”. Next, we sign in as the user THX1138, remembering here that the username and password are the same. Finally, we sign out again using the SIGNOFF command, then sign back in as with our regular user profile.

The password length is determined by two system values, the Password Maximum Length system value, QPWDMAXLEN, and the Password Minimum Length system value, QPWDMINLEN. To display the minimum length allowed for a password, we execute the command DSPSYSVAL SYSVAL(QPWDMINLEN). A value from 1-10 is allowable, but the longer the password, the better.

The Set Password to Expired parameter, PWDEXP, lets us set the password for a specific user profile to be expired. The two values we can use for this parameter are simply *YES and *NO. When the password is set to expired, the user profile will be prompted to enter a new password when they sign on. When creating a new profile, administrators usually set the PWDEXP field to *YES to indicate that the password should be changed by the user when they sign on. To create a user profile HAL9000 that will have to create a new password after signing on to the system, we issue the command CRTUSRPRF URSPRF(HAL9000) PWDEXP(*YES).

We can then test the effectiveness of the PWDEXP(*YES) parameter by singing off from our user profile via the SIGNOFF command and singing in as HAL9000, remembering here that by default the password is the same as the user profile name. As soon as we sign in we are taken to the Change Password screen. We can also access this screen, and change  our password, by issuing the Change Password command, CHGPWD.

The Profile Status parameter, STATUS, specifies whether a user profile is enabled or disabled for sign-on. The STATUS parameter can be either *ENABLED, in which case the system allows the user to sign on to the system, or *DISABLED, in which case the system will not allow the user to sign on until an authorized user re-enables the profile by changing the value to *ENABLED.

The special authorities parameter, SPCAUT, is used to assign the special authorities to a user. Special authorities are needed to perform certain functions on the system. The all object authority, *ALLOBJ, grants the user the authority for accessing any system resource. The security administrator authority, *SECADM, grants the authority to create or change user profiles. The save system  authority, *SAVSYS, is used to save, restore, and free storage for all objects on the system. The job control authority, *JOBCTL, is used to change, display, hold, release, cancel, clear all jobs that are on the system, and stop active subsystems. The service authority, *SERVICE, allows the user to perform system service functions, such as save and restore. The audit authority, *AUDIT, allows the user to change the system values that control auditing, as well as change the auditing for specific objects and users. Finally, the spool control authority, *SPLCTL, grants the user the ability to manipulate other user’s spooled files.

The two other special values for the SPCAUT parameter are *NONE, where no special authorities are granted, and *USRCLS, where special authorities are given based on the value entered in the user class parameter.

The user class parameter, USRCLS, specifies the type of user to associate with the user profile. The possible values are security officer, *SECOFR, security administrator, *SECADM, programmer, *PGMR, system operator, *SYSOPR, and user, *USR. The user classes represent convenient ways to assign special authorities to different types of users. When we assign user profiles to classes, the profiles inherit the special authorities associated with the class. The security officer, *SECOFR, is granted all object authority, security administrator authority, save system authority, job control authority, and spool control authority. The security administrator, *SECADM, is given security administrator authority. The system operator, *SYSOPR, is given save system authority and job control authority. The programmer and user classes, *PGMR and *USER, are given no special authorities.

As an example, we can create a user, PLYRONE, and assign them to the user class by issuing the command CRTUSRPRF USRPRF(PLYRONE) USRCLS(*USER). We can then use the DSPUSRPRF command to verify that the user PLYRONE has been assigned to the *USER class.

The Initial Menu parameter, INLMNU, indicates the name of the menu that is shown when the user signs on to the system. The default value for the Initial Menu parameter, INLMNU, is MAIN. As an example, let’s say we wanted to define a user profile for doing backups. We could assign such a user to the system operator class, *SYSOPR, and assign them the Backup menu, BACKUP, as their initial menu. To do this, we would issue the command CRTUSRPRF USRPRF(BCKUPMGR) USRCLS(*SYSOPR) INLMNU(BACKUP). Signing in as the user BCKUPMGR takes us directly to the BACKUP menu, which we can exit by pressing F9.

UBD (Universal Backup Device) is a backup appliance that plugs into your IBM i and appears as a tape device

Creating User Profiles on the IBM i

Signing on to an IBM i

Historically, an IBM 5250 terminal was used to access an IBM i system, which was then known as an AS/400. Display terminals, sometimes called “dumb” terminals, did not and do not have any information processing capability; instead, it was a simple hardware component consisting of a screen for displaying data and a keyboard for accepting input.

Nowadays, everyday access to an IBM i system is accomplished from a PC via 5250 emulation software. MochaSoft’s 5250 emulation software, for example, is quite popular.

The IBM i is a secure system that requires sign on before any commands can be performed. The Sign On menu shows the current system, workstation, and subsystem. Beneath these three assigned values are five labelled data entry fields, the first two of which are the username and password. Note that it is not possible to see the information typed into the Password field.

The other three fields, Program/procedure, Menu, and Current library, can be restricted; this is a often a good idea from a security standpoint. To restrict access to these three fields, the sign-on screen can be modified. We can also set the Limit Capabilities field to *YES in individual user profiles to keep them from being able to specify values for these three fields.

Screenshot (296)

There are actually two standard sign-on screens for the IBM i. The first is QDSIGNON, which is used when the system is configured for standard 10-character passwords; the second is QDSIGNON2, which is used when the system has been set up to use 128-character passwords.

A user profile object is used to identify a particular use or group of users to the IBM i system. A user is known to an IBM i system by the user profile name. When initially assigned a username, the password is normally set to that same name.

An IBM i system has several predefined user profiles, with QSECOFR and QSYSOPR being the two most frequently used. In fact, only the security officer profile, QSECOFR, or another profile with *SECADM special authority, has the ability to create, change, or delete user profiles.

QSYSOPR is the name of the IBM-supplied system operator profile, and is therefore the name of a user who can sign on to the IBM i system. We can sign in as QSYSOPR whenever we need to perform system operator tasks, such as backups and restores, or powering down the system.

If the IBM i system has just been installed, we can sign in with the user profile QSECOFR, and enter the preset password for that profile, which is likewise QSECOFR.

Signing on starts an interactive job. An interactive job involves real-time processing that requires a dialog between users and programs. In contrast, a batch job runs in the background, does not require user intervention, and often takes a long time to run.

Wanting to get the most out of your IBM i investment? Take a look at, the friendly IBM backup solution.

Signing on to an IBM i