Bullet-Proofing OS/400 User Profiles from Automatic Disablement, Expiration

April 20, 2005 Hey, Joe

I liked your article about using the Analyze Profile Activity command (ANZPRFACT) to automatically disable inactive user profiles. I wasn’t aware that you could set up an active profile list by using the DSPACTPRFL and CHGACTPRFL commands. I don’t have any entries in my active profile list, but ANZPRFACT has a bad habit of disabling several of my Q* user profiles. Do you recommend adding the Q* profiles into my active profile list?

–Rob

Most definitely. That’s what IBM designed the active profile list for: to shield user profiles from ANZPRFACT processing. But remember that there are several Q* profiles that ANZPRFACT will never consider inactive, including QSECOFR, QDOC, and QTCP, so you don’t need to add any of the Q* exception profiles to the list. For a complete listing of the Q* user profiles that ANZPRFACT ignores, bring up the ANZPRFACT command and press the Help key (F1). IBM lists out the ignored profiles in its ANZPRFACT help text.

You should also understand that ANZPRFACT isn’t the only way that OS/400 can disable a user profile or force a user to change their password. In addition to ANZPRFACT, user profile readiness can also be affected by the following two functions:

The password expiration date parameter (PWDEXPITV) in each user profile.

PWDEXPITV specifies a set number of days that the current password will be active before OS/400 expires the password. OS/400 will provide warnings to the user before the password expires and–once password expiration occurs–the user will be forced to change the password to a new value before he can sign-on again. This isn’t much of a problem for interactive work, but it can cause problems for batch or repetitive server processing jobs running under a user with an expired password (I just had this happen to me a week ago and it’s not pretty). Using PWDEXPITV, you can set your passwords to expire anywhere between 1 and 366 days after the password was last changed. You can also set PWDEXPITV to *NOMAX, which means that the password never expires. In addition, PWDEXPITV can be set to the *SYSVAL literal, which means that the user profile will take its password expiration interval value from the Password Expiration Interval system value (QPWDEXPITV). *SYSVAL is the default value for this parameter.

Automatic expiration after a set number of incorrect sign-on attempts.

OS/400 contains two system values–the maximum sign-on attempts allowed value (QMAXSIGN) and the action to take for failed sign-on attempts value (QMAXSGNACN)–that will also disable a user profile. The way this works is that QMAXSIGN has a default value of 3, and that represents the number of consecutive failed sign-on attempts that can occur for a user profile before OS/400 will take action to prevent an unauthorized user from hacking into the system. Once the QMAXSIGN value is breached, OS/400 will take the action listed in the QMAXSGNACN system value in order to thwart a potential intrusion. QMAXSGNACN can be set to one of three values:

‘1’= Disable the device that is producing the failed sign-on attempts
‘2’= Disable the user profile that is being used in the failed sign-on attempts
‘3’= Disable both the device and the user profile that were used in the failed sign-on attempts

OS/400 will generally put a message in either the QSYSOPR message queue or the history log after it disables a user profile, so you can scan those areas for a heads-up warning when this happens.

One other thought I had on this subject is that for certain user profiles that are used strictly for batch or repetitive processing you could strip the password away from those profiles so that the user cannot interactively sign-on to the system. Doing this prevents someone from trying to sign-on and accidentally disabling the user profile while retaining the profile’s ability to be used for non-interactive work. User profiles without a password can still be used to run a scheduled job, in a Submit Job command (SBMJOB), or in prestart and autostart jobs. Removing the password only removes the user profile’s ability to run interactive jobs. With some limitations, the profile can still be used to run batch or repetitive server work. You can strip the password from a user profile by specifying the *NONE literal in the User password parameter (PASSWORD) of the profile.

So if you really want to bullet-proof your user profiles from the threat of being disabled or having an expired password, you could use a combination of these techniques where the password is disabled, the user profile name is shielded from ANZPRFACT processing in the active profile list, and the password expiration parameter is set to *NOMAX. This would protect a user profile from automatic disablement and password expiration as well as any other single technique I could think of. It’s a little overkill, but it would definitely do the trick.

Just a few long-winded thoughts on user profile protection. Thanks for the question and I hope this helps.

–Joe