Default Passwords

Q: How do I avoid default passwords on my system?

A: The best way to avoid default passwords is to not create profiles with default passwords. (Default passwords are passwords that are the same as the user profile name.) This usually requires a process change, because the Create User Profile (CRTUSRPRF) command defaults to create passwords that are the same as the user profile names. So you have two choices: You can demand that your administrators who create profiles create profiles with "real" passwords--that is, passwords that are not the same as the user name, or (my preference) you can change the command default for the password parameter of CRTUSRPRF to be *NONE rather than *USRPRF. That way, if the administrator forgets to change the password to a "real" password, the profile is created without a password and therefore cannot be abused. Creating a profile without a password is actually a good practice. The profile is only "activated" when the user's manager calls to get the password and then delivers it to the new employee. This practice avoids profiles being created for people who never actually join the company, which seems to be a problem in larger corporations.

If default passwords exist on the system, you can detect them using the Analyze Default Password (ANZDFTPWD) command, which produces a report of all the users with default passwords. In addition, it can either set these profiles to *DISABLED status and/or require the users to change their passwords the next time they sign on. Make sure to send the report to a secure output queue. You don't want the list of users with default passwords circulating around the company!

User Class Parameter

Q: What's the User Class parameter on CRTUSRPRF used for?

A: Not much. The system uses it to default the special authorities the user is going to have, but those can be overridden. OS/400 also uses the user class to determine which OS/400 menu options the user will be shown. Common to popular belief, it is not used during authority checking. At no time does OS/400 look to see what user class the user is in when determining if the user has sufficient authority to access an object.

Error Message CPI2224

Q: When I create a user profile, I sometimes get the error message CPI2224--User class and special authorities do not match system-supplied values. What does it mean, and should I be concerned?

A: What the message is trying to tell you is that the profile has been created with special authorities that do not match the special authorities that normally come with the user class the user is in. Default special authorities for each user class are shown in the table below.

If your system is running at security level 20, all user classes have *ALLOBJ and *SAVSYS in addition to the other special authorities they have at higher security levels. This is one of the reasons that it's a really bad thing--from a security point of view--to run your system at security level 20!

When creating a profile, you can choose one user class and special authorities that totally differ from the defaults. For example, you can put a user in the SECOFR user class and remove all the special authorities. Or you can put users in the USER user class and give them all special authorities. Should you be concerned about getting the "mismatch" message? No. Your concern should be making sure you give the users only the special authorities required to perform their jobs.

Override System Values with Parameters

Q: Aren't there some user profile parameters that override system values? Which ones are they?

A: The Limit Device Session, Password Expiration Interval, and Display Sign-On Information parameters override the corresponding system value settings.

You'll most likely use the Limit Device Session parameter when you limit the users who can sign on to more than one session using the QLMTDEVSSN system value. You can then use the Limit Device Session parameter in the profiles of such users--e.g., operators, system administrators, and programmers--to allow them to be able to sign on to more than one device.

The Password Expiration Interval parameter may be used in a couple of ways. First, you can use them when you have processes, such as FTP, that run on a scheduled basis and have a password hard-coded into the FTP script or onto a PC hard drive. I do not recommend this practice, but it happens. In this case, the Password Expiration Interval parameter is used to specify the value of *NOMAX so that this password is not changed. Second, you may use it to require security officers and other powerful profiles to change their password more frequently than the rest of the users on the system. For example, the QPWDEXPITV can be set to 90, requiring users to change their passwords every 90 days. The security officers' profiles can use the Password Expiration Interval parameter to require their passwords to be changed every 30 days. I do recommend this practice.

The Display Sign-On Information parameter overrides the QDSPSGNINF system value. However, neither the system value nor the user profile parameter are very useful. In the case of iSeries Access for Windows, the value you see for the last sign-on date and time is about two seconds earlier. That's because you've signed on to the sign-on server before signing on to the Telnet server. The concept is a good one. When using this function, users are presented with the last sign-on date and time right after they sign on to the system. The idea is that users can monitor their information and therefore know if someone (other than themselves) has signed on to the system. Use of this function takes education--users must be informed to pay attention to this information and told what to do or who to call if something doesn't look right. This education rarely occurs. In fact, the reality is that most users are annoyed by this display because they are required to hit Enter again before getting to their application, and they totally ignore the information displayed. This, combined with the fact that you often don't get valid information anyway, tends to make me recommend not using this function. If you do use this function, turn it off at the system value and turn it on using the Display Sign-On Information parameter in the profiles of powerful users--users whose profiles, if compromised, will do the most damage.

Group Profile Parameters and Supplemental Group Profile Parameters

Q: What's the difference between the group profile parameter and the supplemental group profile parameter?

A: The group profile parameter defines the user's first group. You can define additional attributes for the first group, but no additional attributes are available for the supplemental groups. For example, you can specify the owner parameter to say that all newly created objects are owned by the group. (Unfortunately, most of the file systems don't honor this setting.) Or you can specify that ownership is retained but this group is to be given a private authority to anything that is created by this user. Honestly, I don't see this parameter in use very often and don't recommend its use because of the number of private authorities this has the potential of creating on the system. These additional attributes are the only things that distinguish the group profile from the supplemental groups. When defining group profiles in a user profile, I recommend that you specify them in the order of use. In other words, if the source of most authority comes from group ZZZ, define that group in the group profile parameter. If you define five group profiles for a user, don't define them in alphabetical order. During an authority check, OS/400 checks a user's groups in the order they're specified in the user's profile, with the profile specified for the group profile parameter being checked first.

Group IDs

Q: I tried to make a profile a member of a group profile, but I got a message saying that I couldn't because a group profile couldn't be a member of another group. I did a Display User Profile (DSPUSRPRF), specifying the *GRPMBR option to see the members of the profile. None were listed. What's going on?

A: Check to see if the profile has a Group ID (GID). A GID is a numeric representation of the user. Perhaps the profile was once a group. Even if you remove all of the members from a group, the GID remains. That, or perhaps someone explicitly defined a GID for the profile. In either case, you can specify GID(*NONE), and that should clear up the problem.


Carol Woodbury is co-author of the book Implementing AS/400 Security as well as co-founder of SkyView Partners, a firm specializing in security consulting and services. Carol has 13 years in the security industry, 10 of those working for IBM's Enterprise Server Group as the AS/400 Security Architect and Chief Engineering Manager of Security Technology. Carol recently authored iSeries security training videos that are now available for purchase at www.expertanytime.com. Carol can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..

 

Carol Woodbury is IBM i Security SME and Senior Advisor to Kisco Systems, a firm focused on providing IBM i security solutions. Carol has over 30 years’ experience with IBM i security, starting her career as Security Team Leader and Chief Engineering Manager for iSeries Security at IBM in Rochester, MN. Since leaving IBM, she has co-founded two companies: SkyView Partners and DXR Security. Her practical experience and her intimate knowledge of the system combine for a unique viewpoint and experience level that cannot be matched.

Carol is known worldwide as an author and award-winning speaker on security technology, specializing in IBM i security topics. She has written seven books on IBM i security, including her two current books, IBM i Security Administration and Compliance, 3^rd Edition and Mastering IBM i Security, A Modern, Step-by-Step Approach. Carol has been named an IBM Champion since 2018 and holds her CISSP and CRISC security certifications.

---

MC Press books written by Carol Woodbury available now on the MC Press Bookstore.

		IBM i Security Administration and Compliance: Third Edition Don't miss the newest edition by the industry’s #1 IBM i security expert. List Price $71.95 Now On Sale
		Mastering IBM i Security Get the must-have guide by the industry’s #1 security authority. List Price $49.95 Now On Sale