Watch Out When Restoring User Profiles

By Rich Loeber

I was recently confronted with an issue on one of our test IBM i boxes.  The box is implemented as a “warm” backup site for one of our customers.  Every night, a simple FTP of changed objects takes place from their server to our test box.  The theory is that the customer can afford to loose one day’s worth of processed transactions for the ease and relatively low expense of maintaining this sort of backup site.

The problem posed to me concerned their security configuration.  While their program base and data files were all being properly synced night after night, their passwords were growing woefully out of date on the backup site.  If they had an emergency, nobody would remember their older passwords.

I thought that the solution would be simple.  Just run a SAVSECDTA (Save Security Data) on their system, then restore it on our test box.  Before doing this, I compared the user profile base on both systems and found some areas for concern where the same user profile existed in both places.  Fortunately, the RSTUSRPRF (Restore User Profiles) command lets you either restore specific profiles or restore all profiles with an exclusion list.  I wanted to exclude all Q* profiles plus a handful of common profiles that exist on both systems.  My list ended up being fairly short.

I was all set to bring these profiles current, but when I tried the RSTUSRPRF, I was gently reminded that this command can only be run when the system is in restricted state.  Our test box hosts several websites including one that runs in secure HTTPS mode.  Thinking this would be a quick process, I shut down the system after notifying a few people that there would be a short interruption in service.  When the system came to restricted state, I ran the user profile restore which ran quickly and without any issues.

I then restarted the system, and here is where it got interesting.  At first, it looked like everything was fine, but I soon found that the web server instance that was using HTTPS was not restarting correctly.  After poking around for a few minutes, I found that it was objecting to the digital certificate that was specified for the site.  I fired up the Digital Certificate Manager (DCM) to see what was going on and the certificate looked just fine.  I decided to delete the certificate and re-add it, and here is where the train wreck was revealed.

When I tried to re-issue the certificate, I was advised that my password for the certificate store was invalid and that I would have to change the password before I could issue the new certificate.  I dutifully changed the password, but the same error kept coming back up.

After a long investigation period, I finally determined (with help from on-line friends) that the root of the problem was the RSTUSRPRF.  It turns out that the restore user profile process restores critical data and keys for the digital certificate store while restoring your profiles.  I now had this information from our client’s box, not ours.  None of the certificates on our system were valid any longer and additional applications on the test box were also failing because of this.

The solution was fairly simple.  You just have to restore the Digital Certificate Manager objects from a security backup from your system on top of the restore just done from the foreign system.  The RSTUSRPRF has the following format for this process:


It took me a while to find a current backup of our system’s security data (another story for another time).  As soon as I did this, then DCM would work correctly and the invalid digital certificates could all be re-created.  While our system was not technically down for this time period, several applications were knocked out for almost 6 hours.

Who would ever guess that restoring user profiles would end up hosing your digital certificate files?  A friend blames this all on IBM for such a kludgey implementation of DCM.  I have to say that I agree.  The save and restore of this certificate information should not be hidden along with the user profile save/restore.  The fix should be a new command from IBM for RSTSECDTA.  Let the user profile restore do just that and move other operations to a different command process.

IBM i Security New Year’s Resolutions

By Rich Loeber

Many people, self included, take this time of year for a little introspection.  We try to see where we have problems or weaknesses and then contemplate methods and strategies to make changes.  If we’re serious, we’ll sit down and make a list of things to do in the New Year.  As the security officer for your IBM i shop, this is a good opportunity to do just that for your installation and here’s my list of some items you should consider.

  • Finally take the plunge and move the security level of your system up at least one level.  If you’re running at level 20 (shame on you!), move to level 30.  If you’re at level 30, move to level 40.  Take the time to plan the move and use system security auditing to check results before you make the change.
  • Check your system for user profiles with permanent passwords; then change them all.  This will, at least, enforce an annual change in these passwords.  And, this means your personal password too!
  • Review the user profiles on your system and look for people who have left the company.  Make sure those profiles are disabled and their passwords have been changed to *NONE.  If you can do so easily, remove the profiles.
  • Review all user profiles with the *ALLOBJ special authority or *SECADM/*SECOFR user class.  Verify that each profile has a valid business reason for these high level access permissions.
  • Do a full audit of all of the security related system values on your box and make sure they are set up to enforce your company’s security policies correctly.
  • Audit your system backup plan and make sure that the tapes are being properly labeled and stored for quick and accurate recovery if needed.
  • Check on the way your backup tapes are transported to and from your off-site storage facility to make sure they are secure in transit.
  • Dust off your Disaster Recovery plan and make sure it still works.  Bring it up to date, then schedule an actual test.
  • Review physical security arrangements for your computer room and for all devices attached to your system.  Do a walk thru and actually look at the various work locations.  Check for things like passwords on post-it notes and lists of system resources.  Spank a few hands (not literally) for violators.  Your physical presence in the end-user’s environment will go a long way towards reinforcing the importance of security.
  • Resolve to review your system security audit journal on a regular basis.  If you don’t have it active, turn it on.  If you have it turned on but never look at it, develop a review process to check for problem issues.
  • If you don’t have network security implemented at the exit point level on your system, commit to getting this done in the new year.  Either write your own exit routines or take a look at one of the many packages available for this important area of system security.  If you’re new to this, take a good look at Kisco’s SafeNet/i Exit Point solution.

If you have other items to add to the list, let me know by email.  I’d love to hear about your new year’s resolutions.

For me, I’m going to just resolve to loose 20 pounds this year.  But then, that was my resolution last year and I’m weighing in at the same rate this year.  At least things didn’t get worse.  Let’s hope that your system security resolutions fare better.

More Control over User Profiles

By Rich Loeber

No matter how good your office procedures are for setting up, enabling, disabling and removing users from your system, there is always room for error.  There is nothing like a quick check of your user profile base to help keep your user profiles in good order.  The user profile is a key that lets people into your system and keeping the keys in order is, or should be, a primary obligation of your security controls.

For many of us who have been doing this for a while, the quick review takes the form of a session with the WRKUSRPRF command using the *ALL option.  But, this is a tedious process at best and you can easily miss something important this way.  The ideal would be to get the user profile information organized into various views to focus in on the myriad aspects of security that exist in today’s IBM i world.

Fortunately, IBM’s i/OS contains a facility to help you with this.  The command “Print User Profile” (PRTUSRPRF) has the ability to generate up to four different format reports that will organize your user profile information base to give you a good overview.  The report information for the four different reports concentrate on:

  • Authority type information
  • Environment type information
  • Password type information
  • Password level type information (V5R1 and higher only)

The command has up to four parameters to control the information presented on the listings.  Some of these parameters are context sensitive and will not always be prompted depending on other values you enter.  In addition to indicating which of the four report formats you want, you can also narrow your selection of the specific user profiles to be included, thereby letting you analyze like profiles together.  These selection options let you limit the reports to only users with specific special authority settings and users for specific user classes.  You will probably want to start by specifying all users, but if you’re in a very large shop, this may produce too much information for you to be able to focus in on.

The four reports, however, are the key to using this tool effectively.  The report on authority type information shows each selected profile along with a reference to any group profile or supplemental groups that the profile belongs to.  Then, the special authorities in effect for the user are shown along with their user class, the user profile object ownership setting and other object ownership related information.  A quick scan of this report can quickly show you users that are categorized in an incorrect group, users who are in a group that gives them more access rights than you really intend and many other options.

The report on environment type information presents a different report format.  This report focuses in on the job execution environment in place for each user profile.  These things include the current library, initial menu/library, default job description and other settings that control how jobs run by each user profile will be setup by your system.  This report lets you do a quick audit of user profiles to make sure that they are set up for just the work they should be doing and no more.

The third report produces password type information.  This report lists the current enabled/disabled status of each profile, the current number of invalid signon attempts, the last signon, when their password was last changed and more information that will help with administration of password controls.  In preparing this article, I discovered some unusual values on this report that seemed to indicate someone attempting to gain access to our test system via Telnet using the QSRV and QSYSOPR user profiles.  Both profiles were disabled and the not-valid signon attempts were at the maximum.  Since nobody uses these profiles in our shop, I can only conclude that an illegal signon attempt was made for both of these.  Fortunately, it appears that these attempts failed since we do not have the default passwords still active for any of the IBM supplied ‘Q’ user profiles.  Using this report, you can perform a very quick scan of the setup for each user and quickly spot anomalies, like I did.

The fourth report prints a report on password level type information.  Under the more recent versions of i/OS, you can optionally use longer passwords (up to 128 bytes long) and you can specify a controlled switch over from one setup to another.  This fourth report supplies you with information on how this extended password level is configured for each user on your system.  You can see additional information about this on the system value QPWDLVL and by using the DSPSECA command on these systems.

These four reports, and their various mutations when you use the filtering options, will give you a good tool in keeping current on the status of the user profile pool on your system.  A monthly review of the first three reports would be in order and you can simplify this by just loading these commands into your system job scheduler to automatically run on a monthly basis.

Getting Control over User Profiles

By Rich Loeber

Every IBM i shop has the potential to have active user profiles on the system for users who have left the company.  Unless your personnel department is extra careful about global notifications when people leave, then you may have a security exposure that you don’t even know about.

You can, if you’re careful about setting up user profiles, take care of this problem when new profiles are created.  The “Password expiration interval” (PWDEXPITV) parameter on the Create User Profile (CRTUSRPRF) command lets you set up a separate expiration day interval for each user.  On a system-wide basis, you can also enforce a default expiration interval with the system value QPWDEXPITV.  Using the system value, you just have to use the default *SYSVAL setting for the PWDEXPITV parameter for each user profile.  I suspect that a lot of shops use this arrangement.

However, in every shop, there are users who have passwords that are set to never expire.  This is not recommended, but may make sense for some people who can closely guard their password and use the system heavily.  (I know many programmers and system operators who enjoy this luxury.)  For these people, simply relying on the password expiration interval won’t work, leaving you an even more serious exposure since the type of people who want permanent passwords also tend to have broad access to your system.

The good news is that IBM’s i/OS contains a way for you to enforce periodic expiration on user profiles that have not been used for a specified period of time.  There are several i/OS commands that will help you to enforce a policy of automatically forcing unused profiles to inactive status by disabling them.

The “Analyze Profile Activity” (ANZPRFACT) command will let you set up and control the number of days that the system should use to check for unused profiles.  Then, after this has been set, the system will scan the active profiles on your system once per day and disable those that have not been used for the specific period of time.  Before you start to use this, however, be sure to read on.  (Note, you can disable this check by running this command again and changing the setting to *NOMAX.)

The “Display Active Profile List” (DSPACTPRFL) command will let you display a list of specific profiles that the ANZPRFACT command will ignore when it is checking for unused profile activity.  These might be certain profiles that own object code on your system but are not actually used for signon purposes.  Some applications may require that these owner profiles remain active on your system.  This may be particularly true of third party software.

The “Change Active Profile List” (CHGACTPRFL) command lets you modify this list of profiles on your system.  You can use this command to add or remove entries from the list.  It is important to note that most Q profiles (IBM profiles) are automatically excluded from ANZPRFACT processing.  If you prompt the ANZPRFACT  command and use the HELP facility, you can access a quick list of the Q profiles that are excluded.

It is important for you to check the list (DSPACTPRFL) and update the list (CHGACTPRFL) before any regularly scheduled analysis processing takes place.  This will make sure that you don’t shoot yourself in the foot by disabling a user profile that needs to remain active.  If you use third party software on your system, check with each developer to find out if their ownership profile needs to remain enabled on your system.  Some third party software won’t care of the profile is disabled, but it is important to get the developer’s blessing before taking this step.  If you do have an owner profile that needs to remain enabled, you can always prevent user logon attempts by changing the password to *NONE.

Checking For Default Passwords

By Rich Loeber,

When you create a new user profile, there are a ton of parameter values that you can select from to customize exactly how that profile will work on your system. A lot of us, because of time constraints or ignorance, have a tendency to take a lot of the defaults that IBM’s i/OS presents to us. One of those defaults, unfortunately, is the user profile’s password. Using default passwords is never a good idea, even when you’re rushed for time. This tip will show you an easy way to identify default user profiles on your system so you can get these passwords changed. A recent study I read showed a surprising number of IBM i shops that use at least some default passwords in their day-to-day operations, don’t be one of them.

IBM ships its i/OS with the default value for the PASSWORD parameter on the Create User Profile (CRTUSRPRF) command set to the special value of *USRPRF. When you use this setting, the password for the user profile is set to the same as the user profile itself. So, if I set up a user profile for RICHARD and leave the PASSWORD parameter set to *USRPRF, then the password for RICHARD is going to be RICHARD. It won’t take a rocket scientist for someone who wants to get into your system to be able to figure out how to log on with this in place.

If you’re concerned about this, it would probably be a good idea to change the default setting for the PASSWORD parameter from *USRPRF to *NONE. In my book, having no password is better than having one that everyone will know. You can make this quick change by just running the following Change Command Default (CHGCMDDFT):


If you do this, remember that the next time you upgrade your installed version of i/OS, the setting will get changed and you will have to repeat this process.

Fortunately, i/OS provides you with a nice utility that will let you analyze the profiles on your system and identify any that have the default password in place. The command to do this is Analyze Default Passwords (ANZDFTPWD) and can be found on the SECTOOLS menu. When you run this analysis, a listing of all user profiles with default passwords will be produced on your system. This listing will show the profile status and whether or not the password has expired.

If you want to quickly take care of any current default password profiles on your system, there is a parameter on the command called the ACTION parameter. It defaults to *NONE, which will not take any remedial action. If you choose, you can use either the *DISABLE option or the *PWDEXP option (or both). Selecting these options will immediately disable any profiles that are currently useable that have default passwords in place. The second option will set the password to show that it is expired. Both will stop the user profiles in question from further use.

Obviously, before taking remedial action, it would be a good idea to make a best effort to contact any affected users to let them know that they will have to change the password they are using when this change is made.

Personally, I think IBM should just do away with default passwords completely. They removed security level 10, and I think this falls right into that same category.

If you have any specific questions about this topic, you can reach me at (, I’ll try to answer your questions. All email messages will be answered.

Custom Password Validation Program

By Rich Loeber,

While the IBM i operating system has very good features for controlling password selection, sometimes your password policy just can’t be enforced without additional checking. You may have a list of reserved words that you specifically do not want anyone using as a password. Or, you may have some very stringent requirements that are just not covered by the system values that control password assignment in IBM’s i/OS.

When this happens, the only solution is to code your own password validation routine. This can be coded in any high level language. The operating system passes four parameters to your program, one of which is a single character return code. Once you’ve had a chance to complete your validation testing, just set the return code to the value you want and exit your program. If you set the return code to zero (‘0′), then the operating system will assume that your password is acceptable and the password is updated. The parameters passed are, in order, the new password, the old password, the return code and the user profile for a total of 31 characters.

To tell the operating system that you now have your own password validation program in place, you need to update the system value “Password validation program” (QPWDVLDPGM). It is shipped from the factory set to *NONE. To use your own program, just change this value to your program name and library name. It is recommended that you store this program object in the QSYS library so that it is always saved when you backup your operating system.

Once your program is in place, test it to make sure that it is getting called. Use the CHGPWD command and intentionally use a password that will cause your routine to fail. You will see that a message is displayed indicating that the password rules are not met along with the value of the return code that you used. By varying the return code for different situations, you can give your support team a heads up as to the exact reason for the password failure. While you’re completing your testing, make sure that you process a valid password change to make sure that normal changes are not adversely affected by your new validation routine.

Registering your specific program with the QPWDVLDPGM system value will only work if you are using standard 10 character user profiles and passwords. If you are using the newer long passwords, then you will have to write an exit program and register it using the exit point registration facility. If you take this path, then the QPWDVLDPGM system value must get set to the special setting of *REGFAC and the exit program is registered by the WRKREGINF command. Beware, however, that the parameters for the exit point are very different. There is a good example of the format needed for this exit program in the IBM security guide.

One thing to watch out for in this process is that the passwords, both old and new, are passed to your program without any encryption. So, do not store any values received in a database file as this will compromise security on your system. In fact, you should periodically check this system value to make sure that it does not change and that the program processing additional validation rules remains unchanged. This could easily be abused on your system, so lock up the program object.

If you’d be interested in receiving a sample program for default 10 character password validation, I’ve written one just to test how this works on my system. Let me know and I’ll send the program shell to you. If you have any questions about this topic you can reach me at (, I’ll try to answer any questions you may have. All email messages will be answered.

Password Basics – Password Administration

By Rich Loeber,

There are a number of good practices that you can adopt in the area of password administration that will also help to keep things healthy. First, you should have a procedure in place to disable user profiles for people who have left your company. I normally recommend that the HR department include the IT security officer on all termination notifications. I must admit, however, that this does not always do the trick.

An alternative to this is the use the Analyze Profile Activity (ANZPRFACT) command on your system about once a month. This command will search out the unused profiles on your system and set them to disabled status. There is a variable number of days that you can use, but 30 is a pretty good bet.

You should also require all users to periodically change their passwords. The following system value will help with this:

QPWDEXPITV – “Password expiration interval”

This will force your users to change their password at the interval, in days, that you specify on the system value. Very secure installations may require passwords to change every day, but most business installations can get along just fine with a 60 day cycle, which is what I normally recommend. This is one that is unpopular with users, but if you are going to take security seriously, it is a must.

You should also do a period review of your user profile base. In this review, I recommend that you check for profiles that have permanent passwords assigned. In some shops, the programmers tend to appropriate this right for themselves, but they should be on rotating passwords just like the rest of the user community.

I also recommend that you look at the options offered on the SECTOOLS menu. Space limitations here do not let me go into these in more depth, but take a look and you may discover some interesting exposures on your system. There are also many more system values that you can employ in your quest for the perfect security setup. One last item I like to recommend is a periodic physical inspection of your user community workstations. It is amazing how often this will turn up passwords written down and “hidden” under mouse pads and even posted right on the face of terminals. All the password controls in the world will not overcome this problem. If you find one of these, I would recommend that you revoke the user’s access to the system and wait for them to complain, then go into detail about why their access rights were revoked. They should get the message.

Password Basics – Password Selection

By Rich Loeber,

There is nothing quite so basic in the security arena as a password. The combination of user profile and password, if properly used and administered, can go a long way to establishing sound system security on your IBM i system.

To start with, configuration and selection of your password is important. All those terrible computer hacker movies do have something going for them when they have people guessing passwords. Too many people select a password that is just too easy to guess. (I was actually at a client recently where the password for QSECOFR was set to ‘PASSWORD’!)

There is a good way to deal with this problem on your IBM i. There are two system values that can help you to enforce the selection of passwords that are harder to guess. These are:

  • QPWDLMTCHR – “Limit characters in password”
  • QPWDRQDDGT – “Require digit in password”

By changing the QPWDLMTCHR setting to the value “AEIOU”, you will disallow all passwords that contain vowels. Setting the QPWDRQDDGT value to ‘1′ will require that at least one character position of the password will have to contain a numeric character. Between these two settings, you can almost guarantee passwords that are much harder to guess.

Along these same lines, there are three other system values that you should consider:

  • QPWDMINLEN – “Minimum password length”
  • QPWDRQDDIF – “Duplicate password control”
  • QPWDLMTREP – “Limit repeating characters in password”

I normally recommend that the minimum password length be set to 5 and 6 is even better. The duplicate password control limits how frequently your users can reuse old favorites. Using the maximum value of ‘1′ effectively prevents recycling of favorite passwords by disallowing a password that has been used sometime during the previous 32 password changes. Also, limiting repeating characters will also provide a little more control. I recommend using the value of ‘2′ to simply disallow contiguous repeating characters.

Remember, the whole idea is to eliminate passwords that are easy to guess but not make is so difficult that people never remember their own passwords. There is a fine line here between protecting your system and keeping your users happy and productive.

Password Level – What’s Right For You?

By Rich Loeber,

Ever since the introduction of OS/400 V5R1, a new system value for “Password Level” has been available called Password Level (QPWDLVL). This value lets you have additional control over the kinds of passwords you use on your system and how the system treats them. Using the features provided through this new value, you can implement passwords of up to 128 characters in length.

Why would anyone ever want to have a password that long? I asked myself that very question, but when I started looking into the issue, some things jumped out at me that make perfect sense. With a long password, you can implement a “pass phrase” rather than a password. The implementation of the long passwords allows for case sensitive passwords and will accept imbedded blanks and every character on the keyboard. This complexity in your password can easily increase the difficulty for people trying to break into your system.

The system value that controls this is QPWDLVL and it can have the following settings:

  • “0″ – the default setting which sets up 10 character passwords and is what you are probably used to now.
  • “1″ – uses the same 10 character passwords, but the iSeries NetServer passwords for Windows Network Neighborhood access are not kept on the system. If your system does not communicate with any Win-X machines using Network Neighborhood, you might want to consider this.
  • “2″ – allows you to have passwords of up to 128 characters that are comprised of any character on the keyboard, are case sensitive and may contain blanks (but not all blanks).
  • “3″ – implements the same level “2″ passwords but adds the restriction on Windows Network Neighborhood that level “1″ includes.

If I were implementing a new system, I’d seriously consider adopting level “2″ as a standard right from the get go. But, most of you out there in Ibmilanbd have an imbedded culture of 10 character passwords with specific rules in place that you have your users well trained for. The good news is that you can move to a new password level as long as you do a little planning in advance.

Moving from level “0″ to level “1″ is pretty simple and does not require much planning. This will simply eliminate the storage of another set of encrypted passwords on your system. Moving from level “0″ or “1″ to a higher level should take some planning before you take the plunge.

One of the nice things is that whenever you create a new profile, OS/400 creates the associated level “2″ and level “3″ passwords just in case you want to move to the higher password level. So, the codes are already there on your system. The possible downside is that imbedded code and certain client software may not get along with the longer passwords. Consequently, if you decide to make this change, you really should get a full backup of your current security profiles and passwords using the SAVSECDTA command. This way, if things go south on you, you can recover back to where you are now quite easily. You can use the DSPAUTUSR command to check your profiles for users with passwords that will not work at the higher levels. There is a good, comprehensive discussion on how to move to a higher password level in the i/OS manual “Tips and Tools for Securing Your iSeries” (SC41-5300-06) that you should also take a close look at.

If you have any questions concerning this tip, feel free to contact me directly. My email address is I’d love to hear from anyone who is using the longer passwords just to find out how the switchover process went for them.