Testing User Profiles

By Rich Loeber

If you're reading this, you're probably either a Security Officer or working in the security group in your IBM i shop. I'll bet, however, that you didn't start your career in the security area, but worked your way into your current position, starting as a programmer or a database administrator or some other related field. In your earlier positions, I'm sure you learned a lot of principals about testing. Don't let this fall by the wayside in your current position. Security testing is just as important as application testing.

Today, we'll take a look at testing your user profiles. In future articles, I'll also be taking a look at other testing regimens for your security setup.

The best time to test a user profile is when you initially create it. If, however, you have never tested your user profiles, you may want to tackle a project to get the profiles on your system tested on a periodic basis to make sure that they conform to your security objectives. This article will assume that you have your user profiles organized into groups with group profiles active.

As with all testing, the objective is to check and make sure that the security setup for a user profile (or group) is meeting the objectives you designed. To do this with a new profile, make sure that you set the password to a temporary code and that the PWDEXP parameter for the profile is set to *YES. Using this method, the system will allow a single signon with the temporary password and then prompt you during signon to change your password immediately. When you signon to test the profile, you can then change the password to the user's final password or to another temporary code. If you do assign a new temporary code, you'll have to set the PWDEXP back to *YES when you're all done.

The first thing to check on any new profile is to make sure that the signon completes successfully. If it fails, look in the special QEZJOBLOG output queue for a joblog for the failed logon session. It is amazing what a joblog can tell you about failures on your system and a close examination of the joblog starting from the top should reveal any problems that have happened to cause the logon process to fail. Typical problems you will encounter include missing or misspelled library names, incorrect initial menu names and incorrect initial program references.

Once you've signed on correctly, then you should exercise the profile to make sure that it meets your objectives. Ask yourself the following questions as you work with the new profile:

• Is the right menu displayed?
• Does the user have access to the command line? If yes, should they?
• If an initial program was called for, did it execute correctly?
• What happens when you press the Attention key function? Is it what you want the user to see?
• Where is printed output going for the session? Is this where you wanted it to go?
• What happens when you attempt to run the application or applications that this user should be using?
• Are there any system tasks that the user should be able to run? Can they?
• Are there specific functions that the user should be barred from? Can you access them?
• Can the user access their printed output spool file? Do they have access to view other user's spool files? Should they?
• Check the user's desktop environment for remote access tools. Using the user profile, can the user access data on your system that they are not authorized for?

Make notes for yourself on any issues uncovered, then go back and make any changes that need to be done to bring the profile or group into compliance with your security objectives. If you detect any problems, be sure to repeat the test until everything is OK. At that point, you can turn the profile over to the user.

If you have never tested or audited your current profiles, you can use this same method but you will have to warn the users that you are doing a review. You can use the PWDEXP parameter on the user profile to help with this testing. Change the user's password to a temporary code for your testing logon. Once you've completed your test, change the PWDEXP parameter to *YES and set a temporary code that you've already told your user about. Then, the next time they log on to your system, the IBM i OS will ask them for a new password and they're back in business with little interruption to their daily job tasks.

If you have any questions about anything in this tip, just ask me and I'll give you my best shot. My email address is rich at kisco.com. All email will be answered.