Admin Alert: A Checklist for Creating OS/400 User Profiles, Part II
September 21, 2005 Joe Hertvik
In the Admin Alert from last week, I presented a checklist of questions to ask when you are creating a basic OS/400 user profile. This week, I am expanding that checklist to include additional questions for configuring a user profile to run application programs. Using both checklists, you can confidently set up a user profile that is uniquely configured to run existing applications on your system.
OS/400 provides two ways to create user profiles. You can use the green-screen Create User Profile command (CRTUSRPRF) or you can use the iSeries Operations Navigator (OpsNav) user profile function. For this checklist, I’ll use the traditional CRTUSRPRF interface but all of these options can be configured through OpsNav. The examples come from the CRTUSRPRF command IBM provides in i5/OS V5R3, so while the basic strategy I discuss here applies to earlier versions, some of these parameters may be slightly different in prior releases of OS/400.
That said, here are four specific questions that will help you correctly configure a user profile to access application software and objects inside OS/400.
1. Which, if any, group profiles should the user be assigned to?
OS/400 users can be assigned membership in up to 15 different group profiles by listing the target group profile names under the Group Profile (GRPPRF) and Supplemental Groups (SUPGRPPRF) fields in the CRTUSRPRF command. By doing this, any of the authorities that belong to a user’s designated group profile can be referenced when the user tries to access an object that he does not possess the proper authority to use. User profiles provide you with an easy way to configure application access for a group of users through one user profile. An OS/400 user profile always adopts the authorities of its collected group profiles, and, generally speaking, the user can always access any object that one of its designated group profiles has access rights to.
Unfortunately, there are a few kinks in group profile membership to beware of, including the following items:
- An IBM-supplied user profile–such as QDOC, QSRV, or QSPL–cannot be used as a group profile.
- You should avoid assigning users to a group profile that has Security authorization (*SEC) access on the system. Doing this means that, by default, the user will have access to every single object on the system.
- The user can have only one group profile assigned to it in the GRPPRF parameter.
- And a user group profile must be specified in the GRPPRF parameter before you can add any secondary group profiles in the SUPGRPPRF field.
- A group profile should never be used to access an application; it should be used for reference only.
2. Should the user have a home directory?
For many applications that use stream-file data in the OS/400 and i5/OS Integrated File System (IFS), you may need to create and assign an IFS home directory for that user. The home directory will be designated as the user’s initial working directory and some applications will not run without a specified home directory to access.
The location of your user’s home directory may be dictated by the application software you intend to run or you may be able to choose a location of your own. The format of the home directory name should be an IFS path name, which is similar to a Windows directory name, with the following format:
The most common place to put home directories is in a sub-directory under the ‘home’ directory off the root of the IFS (/). So if I were creating a home directory for a user profile named ‘JOE’, the user’s home directory would be ‘/home/joe’. To create this directory, I would first specify ‘/home/joe’ under the Home Directory parameter (HOMEDIR) in JOE’s user profile. I could do this as I create the user through CRTUSRPRF or as an update to an existing user profile, by using the Change User Profile (CHGUSRPRF) command.
The trick here is that these commands do not create the IFS home directory for you. You have to do that yourself, and you can perform this action on the green-screen by using the Create Directory command (CRTDIR), like this:
Be sure to substitute the name of your particular home directory for the directory name shown here.
Once the home directory is created, you then have to authorize your user to use this directory. You can easily do that by using the Change Authority command (CHGAUT), which allows you to specify access authorities for IFS objects. If I wanted to give my JOE user total authority to the ‘/home/joe’ directory, for example, I could run CHGAUT with the following parameters:
CHGAUT OBJ(‘/home/joe’) USER(JOE) DTAAUT(*RWX) OBJAUT(*ALL)
The New Data Authorities parameter (DTAAUT) specifies what actions the user can perform on data in this directory, with *RWX relating to standard Read, Write, and eXecute authorities. The New Object Authority parameter (OBJAUT) specifies what authorities the user has to the directory itself and to objects in the directory, and the default is to provide the user with total authority over the directory (*ALL). But you don’t have to give the user total access to the directory. If you want, you can tweak this command to provide whatever restricted form of directory security that you want.
3. How much storage should OS/400 allow the user to access?
Many applications require the user to create objects inside an OS/400 partition or to create work files. To control how much disk capacity a user can write to, the user profile commands include a Maximum Allowed Storage parameter (MAXSTG) for each user. As its name implies, this parameter allows you to set storage limits for each user. The limits are set in 4 KB increments, and they can be set in one of two ways:
- As a fixed number, in kilobytes, between 1 KB and the maximum amount of storage on your system. Since OS/400 sets and allocates these values in 4 KB increments, if you set it to a number that is not divisible by four, the system will round your user’s limit up to the next highest 4K increment. So if you set MAXSTG to 15 KB, for example, OS/400 would automatically create a 16 KB limit for the user.
- As access to the maximum amount of storage available on your system, when MAXSTG is set to *NOMAX. This means that there is no limit to the amount of storage a user can access on the system, which could create problems if one of his jobs enters a loop and accidentally fills up the entire disk drive.
By default, OS/400 sets the MAXSTG parameter to *NOMAX in the CRTUSRPRF command. But finding the right value for MAXSTG can be a tricky task. If you set it too low, applications could crash as your user restores or copies files or creates work files. If you set it too high, the user will never run out of space but you run the risk that the user could use too much disk capacity by running ambitious SQL commands or queries. For system operators or administrators who do a lot of work creating and restoring files for users, you may want to set MAXSTG to *NOMAX. For most others, you may want to determine a comfortable maximum amount of storage to allow the user to have, and make that number your standard limit.
4. Does the user need an OS/400 distribution directory entry?
Many applications require a system distribution directory entry before they will run correctly. I have found this to be true with several third-party software packages for faxing and emailing as well as for some Client Access and iSeries Access functions. So for me, the last step in creating a user profile and enabling it to run most applications is to create a system directory entry for that user, in case an entry is needed. Directory entries are easy to create and they are generated through the green-screen Work with Directory Entries command (WRKDIRE). A description of how to use WRKDIRE can be found in IBM’s iSeries CL Commands manual (see the references below).
By following the simple points listed in this article and in the previous article, you should have most of what you need to create a working user profile that can run almost any of your applications.
RELATED STORY AND RESOURCES