A Case For Contextual Security

By Rich Loeber

My wife and I live in the Adirondack Mountains of northern New York state.  During most of the year, except for 10 weeks during the summer, we have very few neighbors with the closest being almost a mile away.  On a normal day, we get a handful of cars that drive down our road (unless you count the number of times the snow plow goes by).  In this context, we’re not very concerned about security.  We rarely, if ever, lock our doors.  We know all of the year round residents and they know us.  We all look out for each other and that seems to be all of the security that we need.  Our biggest security consideration is the local bear population, they get into the trash if you’re not careful and make quite a mess.

In the IBM i world, context can define how you handle security.  Security in the OS is not attenuated to context, so you have to think about your requirements and implement contextual considerations as they apply.

What do I mean by contextual security?  Here’s the classic example.

Suppose that you have an order processing application that records credit card information and then processes that information to obtain credit card authorization approvals.  Obviously, the clerk entering the order needs to have access to your customer database in order to enter the credit card information or validate the information that you already have on file.  Within your standard security model, you will need to grant this user access to the information with sufficient authority to add new information, change existing information or even delete current erroneous information.  For their normal order processing tasks, this user can be configured easily to provide for database access and change authority.

But, what about other possible accesses to this data that do not fall within the normal context of their job execution?  The same level of access that they normally require is inappropriate when accessing your customer credit card information via FTP or by using IBM iAccess download functions.  When using these functions, this same profile can make a copy of all the credit card information on their desktop, then copy the information to a flash disk or memory stick and walk out of the office with all of your credit card information in tact and nobody would be the wiser until the story breaks in the NY Times.

Given this reality, obviously the single context approach to database security is not going to work.  The user does need access rights to do their normal job requirements, but they need to be restricted from access for other contexts.

Fortunately, there are several ways to accomplish this on the IBM i and I’ll just mention three of them here so you can start thinking of how to get this taken care of.

First, and possibly easiest although not always cheapest, is to buy and install a good exit point security solution.  There are several such solutions available on the market from reputable software developers.  (I recommend SafeNet/i, the solution from my company.)  The exit point solution lets you define a network access context for your users and restrict network accesses that might otherwise be wide open to them.  You won’t have to change the security setup in the IBM i OS, but the extra layer of security from the exit point solution will add the contextual security you need from network based applications like those already mentioned.  You could write your own exit programs, but exit point programming is not for the feint of heart and the rules periodically change as the OS goes from release to release, so it is better to go with a good solution from a trusted software supplier (like ours!).

There are two other approaches that are similar in nature and can also let you define security on your IBM i based on context.  One is adopted authority, the other is profile swapping.  In both cases, the security in force when you application runs is NOT based on the user profile doing the work but on some other method.  With adopted authority, your program is set to base security decisions on the user profile that owns the program, not on the profile that is running the program.  This way, you can control who gets to use the program, then the program itself can control the resources that it needs access rights to.  With profile swapping, you can let the requesting user profile control things up to the point where different access rights are needed, then under program control, you can call an API in the OS to swap profiles and run under a different profile for a given duration of processing.  Either way, the user profile used to determine access rights is different from the user signed into the application, giving you contextual control over the situation.

If you have any questions about this topic, you can reach me at rich at kisco.com, I’ll give it my best shot.  All email messages will be answered.

Watching Your Super Users

By Rich Loeber

Every IBM i shop has a few super users that you, as security officer, have to be concerned about.  For one reason or another, a few user profiles just have to have full access to your system.  This tip will show you one way to check up on what these users are up to, using the system security journal.

For specific user profiles, you can implement additional security auditing that is over and above what your system is configured to capture.  To make sure that your super users are not over stepping their bounds, you can set up the security journal to capture additional security events for these specific profiles.

To get started, you need to have the security journal active on your system.  If it is not active, you can just run the Change Security Auditing (CHGSECAUD) command.  Running the command with the defaults shipped with the OS will set up the security journal (QAUDJRN).  By setting the default values to *NONE, you will limit what the security journal captures so you can experiment with tracking an individual user profile’s activity.  Of course, if you already have the security journal active and running on your system, you can skip this step and continue on with setting up the individual profile controls.

With the security audit journal active, you are now able to set up specific event controls at the user profile level.  This is done using the Change User Auditing (CHGUSRAUD) command.  Type this command in and use the F4 key to prompt for the parameters.  For this tip, we’ll concentrate on the “User action auditing” (AUDLVL) parameter and what things you can track at the user profile level.  These include the following:

 

  • *CMD – this setting will record command strings used by the profile in the journal for your review.  With this setting, you can see what specific OS commands the super user is using and make sure that command line abuse is not happening.
  • *CREATE – this setting will let you track all new objects created by the super user.
  • *DELETE – using this setting, you can see when a super user deletes an object.  Since this is a concern for super users, you can track it easily using this method.
  • *OBJMGT – this setting tracks object renames and moves.
  • *SAVRST – this setting lets you track save and restore operations by the super user.
  • *SERVICE – this setting lets you track the super user’s use of system service tools.
  • *SPLFDTA – this setting lets you track actions taken on spool files.
  • *SYSMGT – this setting tracks system management functions.
  • …. more

Different levels of IBM’s i/OS include a number of new/different functions that you mAY want to explore.  The AUDLVL parameter accepts many more options thaN I’ve listed here.  For your installation, you may find some of the other values of particular interest.

A nice side benefit of logging super user activity to the security journal is that it is a good proof for your auditors that super user profiles are being used responsibly.  Every auditor I know of who knows what they are doing is concerned about what super users are up to.  This method goes a long way to satisfy their requirements.

If you have any questions about anything included in this tip you can reach me at rich at kisco.com,  All email messages will be answered as quickly as possible.

Recovering Your IBM i Security Configuration

By Rich Loeber

I once worked, many years ago, with a company that had a disaster recovery plan in place and actually tested it once or twice.  The plan called for us to arrive at the recovery center and then, almost immediately, turn security on the recovery box OFF to make things easier during the recovery.  There was no corresponding step later in the recovery to reactivate security, so for the duration of any disaster, the backup system was exposed to security violations.  Now, to give them some credit, this was in the days before networks and the Internet, so their exposure was probably pretty limited.  In today’s world, however, when you have to switch over to a disaster recovery site, you will need to have your security plan in place and built into the recovery process.

To understand how best to do this, you first have to understand what the different security objects and settings are on your system along with how and where they are saved.

System values make up a large component of your security policy implementation.  The system values are all stored in the QSYS library.  They are saved when you run a SAVSYS, the “Entire system” or “System data only” options on the SAVE menu or when you save your entire system using the “Run Backup” (RUNBCKUP) command.  When you get to your recovery site and restore your OS from one of these, your system values will get restored in the process.  Keep in mind that these settings will be restored the way they existed when your SAVSYS was created.

User profiles, including group profiles, are also stored in the QSYS library and are saved when you save the OS.  Since these can change more frequently than the OS, you can also save them using the “Save Security Data” (SAVSECDTA) command.  When you restore your OS, you will get the profiles as they existed when that backup was taken.  If you have saved the the profiles separately, make sure that you restore them again as soon as the OS has been restored so that you get the most current set of passwords available.

Job Descriptions can also have an important affect on how jobs run and how security is enforced on your system.  IBM generally recommends that you create your job descriptions in the QGPL library where they keep theirs, but a job description can be created and stored in any library on your system, especially if you are running any third party software.  When you backup a library using the “Save Library” (SAVLIB) or “Save Object” (SAVOBJ) command, the job descriptions will travel along and will be restored when those libraries are restored.

Finally we get to your resource security setup.  This, by its very nature, is a bit more complicated than the above items, but certainly manageable.  The good news is that a lot of the resource security information is stored directly with the object.  This includes its public authority setting, its object audit setting, the profile of the object’s owner, the primary group and the link, if any, to an authorization list.  So, when you save the objects in your library, you will also be saving these security items.  The two resource security pieces that are not included are the authorization list itself and the private authority configuration.

All authorization lists are stored in the QSYS library.  They are saved when you save your OS and they are also saved when you run the SAVSECDTA command.  As with the user profiles already mentioned, these can change more dynamically than the OS, so having a separate SAVSECDTA is a good idea.  After you restore your OS, make sure to include a restore of your security data to get the most recent versions of your authorization lists.

Private authorities are also stored in the QSYS library and are included as a part of the user profile data.  So, when you save the most recent profile information, you are also saving the most recent private authorities.  When you recover your profiles, you are also recovering the private authorities.  But …. there is a catch.  After your system has been recovered, including the most recent profiles and ALL application libraries, you will also have to run the “Restore Authority” (RSTAUT) command for *ALL users.  This will restore the private authorities to objects and to authorization lists.  This is a step that can be overlooked with dire consequences as far as your security implementation is concerned.

There is more information about all of this in IBM’s Security Manual for the OS.  I recommend you review the manual for more details.

If you have any questions about anything included in this tip, you can reach me at rich at kisco dot com,  All email messages will be answered as quickly as possible.

How Much Security Is Too Much?

By Rich Loeber

Last time, I posed the question “Just how much security is enough security for your IBM i?”  This tip will explore the contrary thought of “Just how much security is too much?”.  Is there a point where security is just too much for your installation?

First, we need to admit that all security involves overhead expense.  If you are running security software features in the operating system, they take some computing resources to perform access validation routines.  When you run additional security validation, such as exit point processing, that adds more processing overhead.  When you require users to regularly change their passwords, that requires time every so often on the part of every user on the system to reset their password to a new value.  When someone has a problem during the normal course of their business day that ends up being related to security, this is additional overhead not only on the part of the end user but also by your support staff.  No matter how you look at it, good security costs money.

But, is there a point where you have too much security and the benefits are outweighed by the security protection deployed?  I think the answer is a clear yes, in certain circumstances.

Some time ago, I did a consulting gig for a large company located in North America.  This company had a very aggressive security implementation for outside vendors.  And, they apparently use a lot of outside vendors who need access to their network.  They had a complicated VPN installed which required a remote token generator be shipped to me.  When the token arrived, it included indecipherable instructions on how to gain access which ultimately did not work.  It was a long and drawn out process, but it ended up taking me three days and countless hours of trial and error with various members of their support desk team to get access to their system just to get started on a project that was behind schedule at the outset.  Once I got into their IBM i processor, I found that my profile had not been properly set up and there was a further delay in getting started.

In this case, the costs associated with the security implementation became excessive.  I was on the clock for this entire experience and the customer ended up paying dearly for this wasted time.  For this customer, I’d conclude that too much security was in place or that the security deployed was insufficiently funded.  The whole point was to provide a secure signon to their IBM i from a remote location, but the number of layers needed to get through was just too much.

When is there too much security?  One check is to see if normal business transactions are regularly stopped due to security checking.  If people in your organization can’t get their normal day-to-day work done due to security hurdles, then maybe there is too much security in place and a review of your setup is in order.

Another check is to see if your support costs are on budget or running way over.  If you’re spending significantly more money on support and that can be traced to security issues, that’s another red flag that something is quite wrong in your security environment.

I know that some of you security officers out there are going to cringe at this, but security is always a compromise between operating efficiency and data integrity.  You need to have a good balance, tempered by an honest assessment of what you’re protecting.

If you have any questions about this topic you can reach me at rich at kisco.com,  All email messages will be answered as quickly as possible.

How Much Security Is Enough?

By Rich Loeber

Just how much security is enough security for your IBM i?  This tip will explore this question and, hopefully, get you thinking about your own environment.

In the good old days, enough security meant that you had a lock on the computer room door and you actually used it.  Keeping people out of the computer room was all that was necessary.  Then along came CRTs and cabling started reaching outside the computer room environs and security became more of an issue.  Someone came up with the idea of requiring a CRT user to log into the system using a user identifier and a password.  With that little invention, things seemed to get back under control.  But, before long, along came PCs followed closely by client/server applications and then the Internet.  Now what do we do?

For many shops, a strict reliance on the user profile and password is still the watchword of the day.  But, is that enough given today’s technology?  I think not.  The problem with today’s networked environment is that you can never be absolutely certain who is at the other end of the line.

But, what is enough?  The concept of the Firewall has captured the hearts of many security officers to address this issue.  In fact, for many companies, the firewall is the be-all and end-all of their security plan.  “We’ve got a firewall in place!” …. case closed.  But, is that enough along with your user profile/password implementation?  Again, I think not.  Multiple studies of computer break-ins and data compromises reveal that fully half of all such incidents are inside jobs committed within the boundaries of the firewall “protection”.

What you really need is a multifaceted approach to security.  You need passwords, a firewall, and more.  In the old days, if the bad guy could get into the computer room, he could do some damage.  But, if you had multiple doors with multiple locks, it would take him longer to break in and you’d have a much better chance of catching him in the process.  In a way, today’s environment needs to be thought of in this same way.  Relying on a single security defense is just not enough today.  You have to deploy multiple defense strategies to be successful.

For your IBM i installation, this should include all of the security tools that are at your disposal.  It means implementing object security based on a coherent company-wide policy.  It means strictly limiting those profiles that have all object authority.  It means implementing exit point security with object level controls there as well.  It means controlling which IP addresses you are going to trust and allow access into your system.  It means having a good user profile and password maintenance plan in place with regular rotation of passwords.  It means quickly rescinding access rights for people who leave or change job assignments.  And the list goes on and on.

I suppose that it is a true statement that no computer system is 100% secure.  But, if you build enough fences that have to be climbed and add enough doors that have to be unlocked, the result will be as secure a system as is possible.  What you don’t want to do is make it easy, which unfortunately is all too common in today’s IT shops.

If you have any questions about this topic you can reach me at rich at kisco.com,  All email messages will be answered as quickly as possible.

Watch Out For FTP “Script Kids”

By Rich Loeber

Some time ago, I wrote about the dangers of having an open FTP server running on your IBM i.  At that time, I advised that FTP was a clear point of potential entry into your system by persons with malicious intentions.

Since then, I’ve been observing repeated attack attempts on my personal IBM i in my office and I’ve identified a particular type of attack that has me worried.  It is what is called a “Script Kid” attack.  It is called this because the attack is mounted using an FTP script so it can be repeated over and over again on any target.  The word “Kid” is used because it is so easy, even a child could mount the attack.

Typically, a “Script Kid” attack will repeatedly attempt to log on to your system using a well known profile name.  Fortunately for IBM i security officers, the most common profiles used by the Kids are ADMIN and ADMINISTRATOR which are very popular profiles in the Unix world.  Good news for us as these attacks will generally get nowhere on the IBM i.

However, not all Kids stick with this basic attack form.  One that worries me a lot happened a few weeks ago and is the event that prompts this writing today.

This Script Kid started signon attempts through FTP using common first names.  Each name made 3 signon attempts, each using a different password.  I’m sure the script called for commonly used passwords such as “password”, “security” or the same value as the user profile.  Scanning through the log of rejects for this attempt, I see a very comprehensive list of first names used such as ABBY, ABIGAIL, ABRAHAM, ABUSE, ACCOUNTS, ADAM, ADRIAN, ALAN, ALBERT and so on.

On the surface, this attack pattern seems like it would fail miserably as long as you have good password policies in place.  And, as far as preventing access to your system, this is a true statement.  However, this kind of attack could have a devastating impact on your system by cycling through commonly used profiles and causing them to be disabled by the operating system.  Most IBM i shops allow for three logon retries when an incorrect password is entered.  After the third attempt, the profile is disabled and can only be reactivated by a security officer.  You could easily find yourself suddenly inundated with requests to reactivate disabled accounts all over your shop, bringing work on your system to a halt.  (For password resets, our iResetMe software can help.)

So, how can you defend against this type of attack?  For me, on my small test machine, I just shut down the FTP server when I saw the attack start up.  But that is not an easy option for most of you.  In my shop, I intentionally set up a phony profile on the system with the user profile of “ADMIN”.  I set it up to disable on the first bad password attempt and I designed the profile in such a way that it could not be used to gain access regardless of whether it resulted in a successful logon or not.  Then, I had our system monitoring software (we use our own SNDWEET for this), watch for messages in the QSYSMSG message queue.  When I am texted that the ADMIN profile has been disabled, then I know that an attack is under way.

The best solution is to have profile names that are uncommon.  Don’t use first names for your profiles.  A good solution is to pick profile names based on a combination of first and last name.  For those accounts that come with your system from IBM, the infamous Q profiles, make sure that none of them are used for regular production purposes.  You should keep these profiles on your system in a disabled state.  Sooner or later, a Script Kid is going to get around to putting QSYSOPR, QUSER and QSECOFR in their list of profile names to try.  You should also keep a backup security officer profile available in case QSECOFR gets disabled.  Finally, and I’ve said this many times before, never allow a profile to be created on your system using the default password.

If you have any questions about this topic you can reach me at rich at kisco.com,  All email messages will be answered as quickly as possible.

Rescinding Access Rights

By Rich Loeber

Most of the time, as an IBM i security officer, you are concerned with granting access rights to users.  To do this, you need to know what the user’s job responsibilities are and what they will be doing within the computing environment.  Based on existing security policies for your shop, you then configure security for each user so that they can get at the computing resources they need to do their job easily, smoothly and securely.

Once you have a user set up and running, however, I think they seem to fall off our radar since we’re then occupied with getting the next user(s) setup and configured.  You tend to address those areas where you have immediate demands at the expense of others.

One important thing to keep track of, however, are situations where access rights need to be modified or rescinded.  The most glaring situation is when someone leaves the company.  You should have a clearly developed plan of action to implement when someone leaves.  This plan should include:

  • Deactivating their user profile
  • Identifying any objects owned by their profile and reassigning them
  • Removing access rights for objects not owned by them
  • Deleting the user profile after all else is done

Just deactivating a profile is not sufficient.  Batch jobs can still be run under an inactive user profile and those jobs will still have rights to the object set that was defined for that user.  So, you must take the additional action of removing those access rights.  Rescinding access rights is just as important to a secure installation as granting those rights.

Chances are, your IBM i is currently sitting with loads of unnecessary access rights in place for people who are long gone.  Each one of those access rights is a potential security exposure and should be dealt with.  You should review the way the user was initially configured when their access rights were granted and then go through and reverse the process.

Making this work depends you being in the loop when someone leaves the company.  In a small shop, you normally learn this by word of mouth.  But, in any size shop, a formal notification process needs to be put in place to guarantee that inactive profiles are dealt with promptly.  This can be especially important if someone leaves on bad terms.  A firm procedure has to be in place with your HR staff and it must be enforced.

The other situation you need to be prepared for is when someone has a change in job responsibilities.  In this situation, you will not only need to grant new access rights for the user, but you will also have to backtrack and possibly remove some earlier rights that have already been granted.  Again, careful coordination must be worked out with your HR folks.  You are more likely to hear about this through less formal channels since the user will need to get reconfigured in order to start their new responsibilities.

If you have any questions about this topic you can reach me at rich at kisco.com,  All email messages will be answered as quickly as possible.

Restricting Use Of Certain System Commands

By Rich Loeber

When your IBM i is prepared in the factory, it is set so that most system commands and APIs have a public authority of *USE.  This setting will let anyone use just about any command or API on your system.  But, some of those commands and APIs could be used for malicious purposes.  This tip will show you a way that IBM has provided in the operating system to easily restrict those commands and APIs that can be most problematic.

The secret to this is the Revoke Public Authority (RVKPUBAUT) command.  This command, which calls a program named QSECRVKP in library QSYS, can be used to change the public authority for a host of commands and APIs to *EXCLUDE.  Doing this will allow you to control exactly which user profiles will have access to these commands so that you know who will be trusted with them.

Before you run out and execute the RVKPUBAUT command, you need to know what it is going to change on your system.  (For example, it restricts the RSTOBJ and RSTLIB commands.)  To get a full understanding of which commands and APIs will be changed, you can either take a look in the system documentation or, better yet, you can retrieve the CL program source for the QSECRVKP program and examine it yourself.   You can use the following command to retrieve the source code for this purpose:

RTVCLSRC PGM(QSECRVKP) SRCFILE(mylib/QCLSRC)

This assumes that you already have a source physical file in your library named QCLSRC.

When you run this command, there is a single parameter.  You need to supply the name of the library where these objects are stored.  At a minimum, you should run the command for the QSYS library.  If you have more than one national language on your system, you should also run the command for every QSYSxxx library on your system.

If you see commands and/or APIs where you do not want to change the system default, you can make changes to the retrieved CL source program and recompile it.  Do not place the newly compiled program back into QSYS as that will destroy the original as shipped from the factory.  It would be best to put the copy in a different library along with your own copy of the command object named RVKPUBAUT.  Change the library settings on your copy of the command to point to your modified version of the program.  Then, when you run the command, run it from your library and not from the QSYS library.

You should also be aware that running the RVKPUBAUT command will change the public setting for the root directory of the IFS on your system.  It will change it to *USE unless it is already at that level or lower.

Once you have these commands and APIs restricted, you can then go about authorizing them to the specific individuals in your organization that really do need their use.  The best way to set this up is to create an authorization list for this set of users and then set up each of the commands and APIs to point to the authorization list.  Then, as people come and leave, a simple change to the authorization list will take care of all authorization issues to these restricted use commands and APIs.

If you have any questions about this topic you can reach me at rich at kisco.com,  I’ll try to answer any questions you may have.  All email messages will be answered.

Tracking User Profile Changes

By Rich Loeber

In response to a recent tip, I heard from a reader who suggested a good technique that they use for managing a large base of user profiles on their system.  They submitted this suggestion and I’ve been playing with it and it really does give you the basis for managing your user profile base quite nicely.

What this security officer does is to periodically create a database file of the basic information set up for the entire user profile base.  They then compare this to a version of the database to one created a couple of weeks earlier.  Through a series of Query reports, they are able to list activity in the user profile base that gives them exception reports to review.

To get started, with this approach, you need to create your baseline or historical database.  This is done using the Display User Profile (DSPUSRPRF) command.  Select all profiles for basic information and specify an *OUTFILE.  Then sit back and wait a few days, or as my reader suggested, two weeks.  You may want to wait longer depending on how much time you have and how large your user profile base is.

Then, after the selected time period, run the Display User Profile (DSPUSRPRF) command again, but specify the output to a different *OUTFILE database.  Once you have these two files, you can then run a series of Query reports that compare the two files.

My reader recommends at least four reports, but when you get the hang of this, additional reports may be helpful.  The four reports that they work with are:

•    New User Profiles Added
•    Old User Profiles Deleted
•    User Profiles with no Sign-on Activity
•    User Profiles with changes to their Special Authorities

Using IBM i Query, this is really quite easy.  You can match the two files on the user profile field and select different key match criteria depending on the exact report that you are going to create.  In some cases, you’ll want records on one file but not on the other and vice versa.  In other cases, you will want to look at profiles that are on both files but have field mismatches.

Then, when you’re all done with your reporting, copy the current user profile database over into your historical user profile database and wait another couple of weeks to repeat the process.

These exception reports will show you significant change areas in your user profile base.  You can verify that new profiles added are valid and the same for deleted profiles.  For profiles with no sign-on activity, you can check to see if the users are just on vacation or are actually gone from the company.  For users whose special authorities have changed, you can verify that the changes were warranted.

Other reports you might want to consider are users with group profile changes, users with expired passwords and much more, limited only by your imagination.

If you’re interested, I’ve created the four query reports and a CL program that ties this all together.  If you’d like a copy of these in a save file so you can load them directly onto your system, just ask.  If you have any questions about this topic you can reach me at rich at kisco.com,  I’ll try to answer any questions you may have.  All email messages will be answered.

Strengthen Your Passwords

By Rich Loeber

Secure access to your system often starts with your user profile and password policy.  If you’ve been working in the IBM i world for any length of time, this is very familiar territory for you.  You may even have this task assigned to an underling who maintains your user profile base without any instruction or interaction from you.

Sign-on passwords are your first line of defense in your approach to security.  Your password policies are important tools in securing your system.  If you’ve been around a while, you may not be aware of the latest controls that are now available in IBM’s i/OS to help implement stronger password controls.  Over the years, additional controls have been implemented and strengthened.  This tip will review the system values that you can use to implement your password policy.

For starters, you should not have any permanently assigned passwords on your system.  While this is technically possible, it is NEVER recommended.  The system value QPWDEXPITV lets you enforce how often your users need to change their password to continue valid access to your system.  IBM recommends that you do this every 60 days.  Since users have to change their passwords often, some users may want to just alternate between two favorite passwords.  Another system value control in place is QPWDRQDDIF, which defines how many password iterations can go by before a password can be reused.  IBM recommends you set this to level 5 which will enforce 10 iterations.  I recommend a higher number to discourage this practice altogether.

To control how your password is constructed, you want to eliminate common words and names from use so that password guessing is ruled out.  One easy way to do this is to exclude all vowels from use in passwords, which can be done using the QPWDLMTCHR system value.  This lets you specify up to 10 characters (letters or numbers) that must be excluded from passwords.  By using the string “AEIOUY”, you will exclude all vowels from use in passwords.  One thing to note is that the QPWDLMTCHR is not enforced when you are using long passwords at password level 2 or 3 (QPWDLVL).  Another system value that controls password content is QPWDRQDDGT.  When this value is set to ‘1′, then each password must include at least one numeric digit, again making guesswork that much more difficult.

There are three more password system values that help to control password content.  QPWDLMTAJC lets you disallow repeated adjacent numerical digits in the password when the value is set to ‘1′.  Similarly, for characters, the QPWDLMTREP does the same function for alpha characters.  For this value, using ‘1′ will disallow the use of the same character anywhere within the password.  The value of ‘2′ will disallow consecutive use of the same character.  Lastly, the QPWDPOSDIF system value controls password changes.  When this value is set to ‘1′, a new password cannot have any character in the same position as the previous password.  This prevents the user from changing their password by just changing one or two characters.

Two system values control the minimum and maximum length of your passwords.  QPWDMINLEN defines the minimum number of characters required by your password.  IBM recommends a setting of 6, and I concur.  QPWDMAXLEN defines the maximum number of characters.  IBM recommends that you set this to 8, but I really don’t know why.  It depends on the type of passwords you are using as defined by the QPWDLVL setting.  Depending on how this is set, your system might support password lengths up to 128 characters of mixed case values (but that is a different discussion).

Lastly, if none of these settings will adequately implement your password policy, you can write your own exit program.  The system value QPWDVLDPGM will let you register your exit program.  When there is a program registered to this exit point, it will be called whenever a new user is added or when a password is changed.  Your program can do any additional validation testing, returning a pass/fail indicator to the exit point.

This seems like a lot to consider, but with the system values set properly, you can let the operating system enforce your password policies without a second thought.  You only have to set them up once and they will do the job faithfully from that point on.

If you have any questions about this topic you can reach me at rich at kisco.com,  I’ll try to answer any questions you may have.  All email messages will be answered.