Question: I recently took a position that manages AS/400 security administration for a company with over 2,000 user profiles. For the last several years, the system value QPWDEXPITV has been set to *NOMAX. After a recent audit, the auditors would like to change this value to 90 days. My understanding is that, if I change this, the system will look at the Date Password Last Changed field in the user profile and expire any profile with a last change date greater than 90 days, which will be all profiles. If this is true, I don’t know if I would want all users having to deal with changing their passwords on the same day. I would like to know if there is an API or any way to change the last change date in the user profile. That way, I could limit the amount of profiles expiring per day. Or, are there any other suggestions on how to implement phasing in the password change process.

Answer: I can’t think of a single more important security item than the need to expire old passwords and profiles. It is difficult to gain access to an AS/400 without a valid user profile and password, so one of the most important steps towards keeping your system safe is making sure that someone cannot gain access through an old or easily guessed password. While there isn’t a specific API or other (QSECURITY level 40-compliant) way of modifying the user profile’s Date Password Last Changed parameter, I do believe there are several ways of accomplishing your task.

If the goal is to expire everyone’s passwords, but to do it in a measured fashion, you could choose several methods of segmenting your user population so that a limited number of passwords are expired each day. The CL program EXPPWD (available on the Web at www.midrangecomputing.com/mc) gives you an example of how you might expire all of the passwords that begin with a particular letter of the alphabet. The program starts by dumping all of the user profiles that match the given letter into an outfile called Users in library QTEMP and then reads through each record and changes the password expiration parameter (PWDEXP) to *YES. This is just one example of how the user base could be segmented. Browse the file description for the Users and you’ll likely find many other ways to split up this task (group profile and accounting code are just two quick examples that come to mind).

If you ran this version of the program once a day for 25 days (assuming you exempt the letter Q because your smart enough not to name any user profiles beginning with that letter), you could have all of your profiles reset in about a month’s time. Simply call the program, passing a single letter, and it will expire passwords for all of the user

profiles that begin with that letter (e.g., CALL PROGRAM(EXPPWD) PARM( ‘A’ )). After all of the profiles have been reset, you then change the system value for Password Expiration Interval (CHGSYSVAL QPWDEXPITV) to 90 days so that all passwords would expire on roughly the same schedule in the future.

Question: My system operators do not have authority to view job logs. They have *JOBCTL special authority. Isn’t this enough? Or, is authority controlled somewhere else?

Answer: *JOBCTL special authority is usually enough to view another user’s job log. The exception to this rule is that your operators will not be allowed to view the job log of a user that has *ALLOBJ special authority unless they are running with *ALLOBJ special authority themselves. If you want to provide your operators with the ability to view any job log, then create a special Adopted Authority routine that provides them with that function.

In fact, the situation you describe is custom made for an Adopted Authority routine. These routines are best suited for cases where you want to give an extremely specific level of authority to a specific group of users for a limited amount of time. It is vitally important that when you create an Adopted Authority program, you prevent its users from exiting out of it and gaining access to a command line. The risk there is that once a user has called an Adopted Authority routine, any subsequent action they take while that routine is still active will run under the adopted authority. This means that if a user calls program A, and program A both adopts authority and provides access to a command line, the user is now able to run any program or command with the elevated authority that adopted authority provides.

The CL program DSPJOBLOGA in Figure 1 (page 125) is an example of a program that provides a specific amount of elevated authority for a finite task. When program DSPJOBLOGA is compiled by a user with *ALLOBJ special authority, and it is told to adopt its owner’s authority via the compile parameter (USRPRF = *OWNER), this program will grant the ability to view any job log on the system to any user who is authorized to run the program. And that is all that it provides. As you will see, deliberate steps were taken in this program to prevent any user from using the program for anything other than displaying job logs. For starters, this CL program uses a standard error-handling routine. There are many different versions of this in circulation, but the important point is that the program monitors for all error messages (MONMSG CPF0000 at the beginning of the program), and it prevents itself from looping in the error routine through the use of the &ERRORFLAG variable. Any error that may be encountered is then routed to line 24 of the display and appears just as any normal Escape or Diagnostic message would.

The program also prevents users from exiting out to their Attention Key Handling program by turning Attention Key Handling off at the start of the program and turning it back on at the end of the program.

After accounting for possible blank input parameters, the program displays the requested job log and then promptly returns. When the program returns, or ends, the adopted authority is released, and users go back to running under their usual system authorities.

When you create Adopted Authority routines, you want to ensure that their use is restricted to a select group of users, in your case, just the system operators. To do that, edit the object authorities (EDTOBJAUT) and make sure that *PUBLIC has *EXCLUDE rights to the program. Then grant *USE rights to any user that you want to be able to use DSPJOBLOGA.

And while this program is meant as an example of how to correctly create Adopted Authority routines, it also solves the problem you are facing. I’ve included command source on the Web at www.midrangecomputing. com/mc to make the program easier for users. After you compile the command, you should edit its authorities as well and grant the

same authorities to *PUBLIC and to your user base as you did to the DSPJOBLOGA program.

John Earl is the founder and Director of Technology and Security for  The PowerTech Group.  a Seattle-area software company that specializes in System i security. He has over 25 years experience with IBM midrange systems and security, has published numerous articles and columns for industry magazines, and served as a Subject Matter Expert (SME) for Security for COMMON. A highly regarded speaker on OS/400 and i5/OS security, Mr. Earl has presented several hundred of iSeries security sessions at industry conferences and user groups all over the world. He is a three-time winner of COMMON's Speaker Excellence award and has also served on the board of directors of COMMON U.S.

 

He can be reached at 253.872.7788 or at This email address is being protected from spambots. You need JavaScript enabled to view it..

 

 

Also Read

IBM i Security Essentials: 4 Components for an Effective Strategy

New IBM i Security Features and a Farewell

Securing IBM i: A Dual Responsibility