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 (rich@kisco.com), 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 rich@kisco.com. I’d love to hear from anyone who is using the longer passwords just to find out how the switchover process went for them.

More On Automating Your Disaster Recovery Restore

By Rich Loeber,

Some while ago, I wrote a security tip about automating your IBM i disaster recovery restore process. Of the many tips I’ve done over the years, none has drawn as much “fan mail” as this particular tip.

The essence of the tip is an implementation of the OS/400 command LODRUN to automatically restore a full system backup tape. The LODRUN searches the tape for a known program (named QINSTAPP), loads that program into the session QTEMP library and then calls it. Your QINSTAPP program can then load the contents of the tape. The only thing you have to do is create the QINSTAPP program and include it in the backup.

Well, I created that methodology quite a while ago, and a “fan” recently contacted me to let me know that, during testing, he found a problem with it. It seems that the current versions of i/OS don’t like it when the SAVLIB for *ALLUSR or *NONSYS libraries is not the first backup set on the tape. The tip clearly was calling for the QINSTAPP *PGM object to be the first object on the tape, so there was a conflict.

First, I have to commend my “fan” (Keith Scott at Hoover Materials Handling Group) for putting the process to the test. Over the years, I’ve given away hundreds of copies of the shell CL program for QINSTAPP and Keith was the only one to test it and find the problem. No matter where you get your code, testing should ALWAYS be a requirement, especially for something so important as a disaster recovery procedure. I tested this process long ago and it worked then, but it is problematic today.

The news is not all bad, however. With the current versions of i/OS, the LODRUN command supports a SEQNBR parameter where you can use a *SEARCH parameter. This will cause the process to scan the tape until it finds the QINSTAPP saved from QTEMP. At that point, it will load the program and run it.

There is a downside, however. Because the SAVLIB has to come first on the tape, there is a lot of tape searching going on before the actual save gets going. This could add 30 minutes or so to your restore process, depending on the kind of tape you’re using. But, the restoration process is still fully automated, so there’s a strong benefit.

The modified save process should now be changed to save your system in the following sequence:

  • SAVLIB for the libraries you want to save (either *ALLUSR or *NONSYS)
  • SAVOBJ for the QINSTAPP saved from QTEMP
  • AVSECDTA to save your security setup
  • SAVDLO for your shared folder objects
  • SAV for the IFS (other than shared folders)

The QINSTAPP has to be changed to first restore the security data which will sit on the tape right after the QINSTAPP itself. Then, the restore should force a rewind on the tape and restore the libraries. When that’s done, the remaining restores for the IFS will complete the process. When all is said and done, the last step must be a RSTAUT to restore object authorities.

To properly illustrate this, I’ve updated my sample QINSTAPP CL program and also created a companion QDRSAVE CL program to show the system save process in the right sequence. If you’d like to see these sample programs, send me an email (rich@kisco.com) and I’ll send you the shells that I recently created.

Automating Your Disaster Recovery Restore

By Rich Loeber,

Part of the job of a security officer is creating, maintaining and testing your disaster recovery plan. A major part of disaster recovery is recreating your computing environment on a completely different system and this always involves data and program restores. You might be one of the fortunate ones that has access to a comprehensive third party save/restore application that automates the disaster recovery restore process for you. If you’re in this group, this post is not for you. But, if you’re a small to medium sized shop that can’t afford (or won’t consider) one of these products, then you’re on your own to create a workable disaster recovery method.

If you fall into this group, then you should consider implementing a LODRUN program to automate your disaster recovery process. LODRUN is an i/OS command that is normally just used by developers of third party software as a method of controlling the installation process for their software packages. But, LODRUN can easily be used to automate your recovery restore process as well.

When you run the LODRUN program, the command calls a process which looks for a *PGM object at the beginning of the tape with the unique name of QINSTAPP. Once found, it will transfer this *PGM object into the special QTEMP library and then call it, passing along the parameters from the LODRUN command which includes the device name of the tape drive being used.

So, for you to have a controlled restore of your backup tape, all you need to do is create a CL program named QINSTAPP with a single parameter for the tape device name. Then, you can use that CL program to do the controlled restore from the tape onto the new system.

A typical off-site backup tape will contain the following items:

1. A backup of the user profiles
2. A backup of the configuration
3. Backups of the user libraries
4. Backups of the IFS objects

You are probably already familiar with exactly how you do backups for your shop. To use the LODRUN method for an automated restore, all you need to do is create a CL program named QINSTAPP that will restore the objects from the backup tape in the same sequence in which they are recorded on the tape.

Some hints:

1. Change your save program to transfer the QINSTAPP *PGM object to QTEMP and then do a SAVOBJ to save it as the very first object on your backup tape.

2. Be sure that you use the *LEAVE option so that the tape is properly positioned after each restore is completed.

3. Be sure to run the RSTAUT command after everything has been restored to get the authorities correct.

4. Use the CHKTAP command at the very end to rewind and/or unload the tape, this will give you better flexibility when it is time to make changes to your program.

5. Add a clear comment to the CL program you use for creating backups that advises any programmer that works on that program to make sure and mirror any changes in your restore program.

6. When you first create the QINSTAPP CL program, have your save program handy so that you get the sequence of events absolutely correct.

When you’re ready to run the restore, all you’ll need to do is mount the tape and issue the LODRUN command. At that point, you custom restore program will take over and give you a quick, complete and controlled restore of your system on your recovery system. If you’d like to see a sample QINSTAPP program, send me an email (rich@kisco.com) and I’ll send you a shell that I recently created.

Configuring HTTPS

By Rich Loeber,

If you’ve been developing applications on your IBM i that access the system through a web browser, then you’re probably already familiar with the durable and reliable Apache web server function built into the IBM i/OS. This tip will show you how to upgrade an existing HTTP server instance so that it can be used with HTTPS security. If you have any sensitive information being passed between your browser and your IBM i, implementing HTTPS security will encrypt the data and protect it from unscrupulous “sniffers” either in your network structure or over the public Internet.

This example assumes that you have a working Apache server instance named WEBSERVER. It also assumes that you will create and use a self-signed digital certificate named WEBCERT.

HTTPS Configuration Overview
—————————-

The following sequence of events must be completed to convert your working HTTP server instance from a plain HTTP server configuration to a secure HTTPS server configuration.

1. Start the *ADMIN server instance on your System i and log in.

2. Select your current HTTP server instance.

3. Enable SSL for the server instance and register the WEBSERVE application.

4. Change the server instance to use port 443.

5. Connect to the Digital Certificate Manager application on your browser.

6. Create a new digital certificate in the *SYSTEM certificate store.

7. Validate the newly created certificate.

8. Assign the new certificate to the WEBSERVE application.

9. Start the updated WEBSERVER server instance.

10. Verify that the configuration is working correctly.

————–

Step 1 – Start the *ADMIN server instance on your System i and log in.

From the command line on your system, enter the following command:

STRTCPSVR SERVER(*HTTP) HTTPSVR(*ADMIN)

This will start the web server administration tool on your system. This startup process can take a minute or two to complete. After waiting, go to your web browser and enter the following address in the address box of your browser:

http://yoursystemi.com:2001

You will be prompted for a logon process. You must sign on as a security officer with full authority to your system, such as QSECOFR. When the logon is complete, the IBM i5/OS Tasks menu should be displayed. On some releases of the IBM i/OS, you may have to select a link to the “i5/OS Tasks” page following a successful logon process.
————————————————————–

Step 2 – Select your current HTTP server instance.

From the i5/OS Tasks menu, select the “IBM Web Administration for i5/OS” link. This will start the Apache web administration tool. Select the “Manage” tab and then, when it is displayed, select the “HTTP Servers” tab. In the “Server:” selection box, locate and select the WEBSERVER server. If it is not there, then you need to configure it and test it in a non-secure environment before continuing with this procedure. When you have selected the WEBSERVER server, verify that it is showing with a status of “Stopped”. If it is showing as active, then you will need to stop it now before continuing.
————————————————————–

Step 3 – Enable SSL for the server instance and register the WEBSERVER application

Select the “Security” link from the lefthand panel. In the tab labeled “SSL with Certificate Authentication”, select the SSL box and choose the “Enabled” setting. Then, in the box immediately next to the “SSL certificate application name:”, key in the value “WEBSERVE”. We recommend that you do this in all capital letters. Press the “Apply” button to record these changes.
————————————————————–

Step 4 – Change the server instance to use port 443.

Select the “General Server Configuration” link in the lefthand panel. Under the “General Settings” tab, locate the port selection. You will need to first remove the entry for port 80 (the default for non-secure web connections) and then add an entry for port 443. When this is done, make sure you press the “Apply” button at the bottom of the page.

Next, select the “Security” link again. Scroll down until you see the entry box for “HTTPS_PORT environment variable” and enter the value 443 in this box as well. Press the “Apply” button at the bottom of the page.
————————————————————–

Step 5 – Connect to the Digital Certificate Manager application on your browser.

In your browser, re-enter the base address for the i5/OS Tasks:

http://yoursystemi.com:2001

This will bring you back to the main menu. Select the link for the “Digital Certificate Manager”.

Note: The following process will self-issue a digital certificate for use with your HTTPS server instance. When used from your browser, this will give you a warning because your server is not a registered certificate issuer, but the process will work correctly as long as you bypass the warning. On some browsers, such as Firefox, you will be allowed to accept the certificate the first time you use it and it will not be questioned again. Other browsers, like some versions of Internet Explorer, will question your use every time. Regardless, you will know where the certificate came from and you will be able to trust it by virtue of that knowledge.
————————————————————–

Step 6 – Create a new digital certificate in the *SYSTEM certificate store.

Select the button in the top left corner of your browser that reads “Select a Certificate Store”. On the next panel, select the *SYSTEM store and press the “Continue” button. (If the *SYSTEM store does not exist, you will need to first create it using the “Create New Certificate Store” link.) Your system will prompt you for the password for the *SYSTEM certificate store. If you don’t know the password, you can use the reset function to assign a new password. When you are finished, the *SYSTEM certificate store will be open and available.

Now, select the “Create Certificate” link from the left-hand panel. On the next panel, select the option for “Server or client certificate” and press the “Continue” button. Next, select the option for “Local Certificate Authority” and press “Continue” again. Now the certificate form is displayed. Fill out the required fields as follows:

Certificate label Enter the value “WEBSERVER”.

Common name Enter a unique name. I recommend that you use the system name for your system (or partition) as shown from the DSPNETA command display.

Organization name Enter the name of your company or organization.

State or province Enter the name of the state or province where you are located.

Country or region Enter an abbreviation for your country.

Select the “Continue” button at the bottom of the page and your certificate will be created.
————————————————————–

Step 7 – Validate the newly created certificate.

In the left hand panel, select the “Manage certificates” link. Next, select the “Validate certificate” link. Choose the “Server or client” option and press the “Continue” button. Select the WEBSERVER that you just created, then press the “Validate” button at the bottom of the page. If everything with the certificate is OK, a message will be displayed confirming that the certificate is valid.
————————————————————–

Step 8 – Assign the new certificate to the WEBSERVE application.

In the left hand panel, select the “Assign certificate” link. Select the WEBSERVER certificate, then press the “Assign to Applications” button. Locate the WEBSERVE application in the list displayed and place a check mark next to it. Press the “Continue” button. A message will be displayed confirming that the certificate is now assigned to the application.
————————————————————–

Step 9 – Start the updated WEBSERVER server instance.

On a terminal session command line, enter the following command:

STRTCPSVR SERVER(*HTTP) HTTPSVR(WEBSERVER)

This will start the server instance that has been converted for use with HTTPS security. If the server instance fails to start, make sure there is not another server instance active using the secure port number 443. Only one application at a time can be active using this port. If you need more than one active, you will have to change the server instance to use a different port number.
————————————————————–

Step 10 – Verify that the configuration is working correctly.

Once the server instance has been started, enter the following web address into your browser’s address box:

https://yoursystemi.com

A test page from the WEBSERVER server instance should be displayed. As stated earlier, a warning message about the certificate in use may be issued by your browser. Please note the comments associated with Step 5 above about this issue.