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.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online