So many attributes, so little time. It’s tempting to just skip over some of them, isn’t it?

If any of you have prompted the Create or Change User Profile commands, you’ll know that there are a full five pages worth of attributes that can be specified for a user profile. Do you have to specify all of them? Are some parameters more important than others? Read on to find out.

A user profile (*USRPRF) object is what defines the user to IBM i. When creating or changing a user profile, you can define the user’s password, security capabilities, and group assignments, but that’s not all you can specify. You can specify characteristics of the user’s environment, such as the user’s initial program, menu, and attention programs as well as the characteristics of their job—their primary language, run priority, assistance level, and more. It’s not necessary to specify all of the parameters when creating a new profile; it’s often sufficient to take the default settings. But there are some attributes that, from a security perspective, are key. Let’s take a look.

Password Attributes

It starts with a User password parameter. When you create a user profile or reset a user’s password, it’s important that you don’t take the default setting. The default sets the password to be the same as the user profile name, which clearly makes the password easy to guess! I encourage you to set all—even the first password given to a profile—to a value that meets your organization’s password rules. To accomplish this, use the QPWDRULES system value to specify your composition rules, including *LMTPRFNAME and *ALLCRTCHG in your list of values.

Some profiles shouldn’t have a password. Profiles that are created to own objects, run batch jobs, or are a group profile have no need to ever sign on or be used to establish a connection and therefore don’t need a password. To eliminate the possibility of users logging in with this type of profile, set the password attribute to *NONE, as in PASSWORD(*NONE).

The next password parameter that requires attention is the Password expired parameter. When creating a profile to be used for sign on or when resetting a password because the user has forgotten it, set the password expired attribute to *YES so that user will be required to change the password upon first use.

The Password expiration interval is the final password parameter I’ll discuss. This attribute determines how often the profile’s password must be changed. For users, I encourage you to leave this value as *SYSVAL and set the QPWDEXPITV system value to 90 (days) or less. Never is it appropriate for a profile used by an individual to have a never-expiring password!

Service accounts (those profiles used for FTP and ODBC connections) will likely have this value set to *NOMAX so that automated processes aren’t interrupted by expiring passwords. *NOMAX should be reserved only for these types of profiles. I encourage you to change these passwords periodically. These passwords are hard-coded—often in cleartext—and typically become known by many individuals. Periodically changing these passwords will help prevent service accounts from being abused or used for something other than their intended purpose.

For profiles whose password is set to *NONE, leave this value as *SYSVAL rather than *NOMAX. The system doesn’t look at this parameter when the password is *NONE, so there’s no need to make these profiles appear as though they have a non-expiring password.

User Class and Special Authorities

The User class parameter is an easy way to default the special authorities a user profile is assigned, but it is never used in the authority-checking algorithm, so don’t look at it once the profile has been created. Of more concern should be the special authorities assigned to the profile. Special authorities provide the user with the ability to perform some function. I’ve discussed these settings in other articles, so I’m not going to describe them individually. Suffice it to say, profiles should only be assigned the special authorities required to perform their job—no more. This follows the concept of “least privilege access,” which is the practice of granting only the capabilities required—never more. Profiles are often granted special authorities they don’t need due to the practice of copying a profile when creating a new one. While I understand the ease of copying a profile rather than creating one from scratch, I encourage you to create model or template profiles that represent the roles on your system and copy one of those, rather than the profile of an existing user that may have more rights than a new profile should be assigned.

Group Profile and Supplemental Groups

The group profile fields allow you to assign users to a role. Often, users are members of multiple roles, thus the need to specify multiple groups. Assign the most-used role (group) to the Group profile parameter. Then you can assign up to 15 additional roles in the supplemental group parameter. The Owner parameter after the Group profile attribute allows you to specify that any objects created by this profile are to be owned by the group named in the Group profile parameter. This is often a good practice to establish so that users don’t end up owning objects, which is especially helpful when deleting a profile. However, be aware that this parameter is ignored when the user creates something in the IFS. In other words, the user retains ownership of objects created into the IFS.

Limited Capability

The Limited capability parameter determines whether users can enter commands if they can get to a command line. While the limited capability parameter is ignored on many connections (such as ODBC), it’s still a good practice to set this parameter to *YES. That way, if the profile gains access to a command line, the commands that can be run are limited. I set service accounts, group profiles, and profiles used for batch jobs to LMTCPB(*YES) so they don’t show up on a report listing profiles with command-line access. (Any time I can set an attribute that removes a profile from a report that is reviewed and questioned by an auditor, I take advantage of that setting.)

Initial Program, Initial Menu, and Attention Program

These parameters help set up the user’s environment. The initial program is evaluated first. Once the program named in this parameter is done running, the initial menu is invoked. For service accounts, I set INLPGM to *NONE and INLMNU to *SIGNOFF to prevent the user ID/password from being used via interactive signon. I also set the ATNPGM to *NONE so that someone can’t get onto the system by signing on and then quickly pressing the Attention key. Note that these three attributes are totally ignored except when the profile is used to sign on via a Telnet (5250 emulation) session.

Text Description

You’re probably thinking, why is Carol talking about the text field? I’m discussing it because, as I’ve worked with our clients, I’ve seen too many blank text fields, fields with the initials DND for Do Not Delete with no other explanation, fields with the word “test” but that are used for production processes and offer generally unhelpful descriptions. Be kind to the administrators who come after you and put as much description in this field as possible.

Summary

It’s not as if other user profile parameters aren’t useful. For example, two parameters near the end of CRTUSRPRF and CHGUSRPRF allow you to have the profile set to status of *DISABLED on a specific date or in a specific timeframe (for example, in 31 days). These are useful either when you know a profile is temporary or when a user is retiring for example. Using these attributes will take action on the profile rather than having to wait for your normal profile “aging” process to disable the profile. However, some attributes have definite security implications and need special attention. I hope this article will help you focus on and choose the best settings for each.