AS/400 User Profile Disabling
Two weekends ago I upgraded our i520 from OS V5R3M0 to V5R4M0 and ever since we have had problems with user profiles becoming disabled. These are not because of incorrect password either, as many users are ones who use the system daily and have had no previouse issues with passwords.
Software/Hardware used:
Software/Hardware used:
ASKED:
August 10, 2009 4:45 PM
UPDATED:
August 12, 2009 2:20 PM
Answer Wiki:
Have a look at the system values to see if there might be a reason that they are being diabled easier than they were before the upgrade. If you had spooled the system values before the upgrade (This is a good idea!) compare the current to the old settings:
WRKSYSVAL SYSVAL(*SEC) OUTPUT(*PRINT)
These are the values I would be looking at:
QMAXSGNACN
QMAXSIGN
QSECURITY
Voodoo
To see all answers submitted to the Answer Wiki: View Answer History.
Other than an activation schedule (which would use scheduled times), the system values are the only OS method which would disable user profiles. The history log will keep a record of every failed login attempt (filter for CPF2234) so if there is nothing listed, you have another issue.
You could be running the ANZDFTPWD command with the *DISABLE parameter which will disable all profiles that use the IBM default password.
The ANZPRFACT command will disable profiles (even those that don’t use the IBM default for a password) based on the number of days of inactivity that you specify. Use the DSPACTPRFL command to see the number of days a profile is inactive before it becomes disabled. This command will also list the profiles that will be excluded.
Use the WRKJOBSCDE command to view your IBM Job Schedule Entries and look for the QSECIDL1 job, which will run the ANZPRFACT command.
One other area I can think of is iSeries (or system i or IBM i) Access. If a client has Auto-reconnect checked in their Configuration the session will automatically repeat a sign-on attempt multiple times if there is a problem with the network…. so, if the user enters the incorrect password only once the profile can become disabled if QMAXSGNACN is set to 2 or 3 no matter what you have QMAXSIGN at (hopefully, it’s not set to *NOMAX, which would be very poor security). Look further into IBM i Access if the problem is still not found…. using OpsNav, check the properties of the system on a client having this issue. If they are not using ‘Prompt every time’ to signon then they could be using the Windows password (which may not be the same).
If you don’t have a QSYSMSG message queue built, do so (create it in QSYS). It will records when a profile is disabled via a failed sign-on attempt – it does not record profiles disabled by ANZPRFACT.