Whatis23
4040 pts. | Aug 10 2009 11:47PM GMT
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.
Batman47
525 pts. | Aug 11 2009 3:28PM GMT
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).
Splat
1070 pts. | Aug 12 2009 2:20PM GMT
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.






