Security Toolbox Essentials for Managing User Profiles


By Dan Riehl


First Appearing in System iNEWS Magazine


© 2004-2009 Dan Riehl , All rights reserved



OS/400 provides some great administration tools to help you manage the user profiles on your system. While there are scads of commands that can be used in user profile management, I have selected I few of my favorites that you should consider adding to your security toolbox.




·        Finding User Profiles with Matching Passwords


The CL command ANZDFTPWD(Analyze default passwords) is a tool that allows you to easily generate a list of users who have matching passwords; Quite a trick when you consider that OS/400 passwords are stored using a one-way encryption algorithm. In addition, the command optionally allows you specify an action to be taken against those offending profiles. You can specify that the profiles are to be disabled(i.e. the user cannot sign on), or that you want to set the password to an expired state(i.e. the user must assign a new password next time they sign on.)


Here is the report generated by ANZDFTPWD.





                                                   User profiles with default passwords                                             Page    1

5769SS1 V5R2M0  000526                             OPENSYS   10/17/03  09:51:19

Action taken against profiles  . . . . . . :   *NONE


Profile         STATUS         PWDEXP     Text

SDCXCADA        *ENABLED        *NO       Willy Singer

SDCXCCAA        *DISABLED       *NO       Garret Butcher

SDCXCCAF        *ENABLED        *NO       Charly Boller

SDCXCCMG        *DISABLED       *NO       Fark S. Barr

SDCYCCTH        *ENABLED        *NO       Mike K. Adams

SSDCYCDR        *DISABLED       *NO       N. K. Griffen

SEFFCDMP        *ENABLED        *NO       Lucky Beans

SEFFCGIF        *DISABLED       *NO       Roscoe Young

SEFFCJJE        *ENABLED        *NO       Cheese Head

SFHHCJJ9        *DISABLED       *NO       Par T. On

SFHHCJM4        *DISABLED       *NO       I. O. Wou

SFHHCKM3        *DISABLED       *NO       S. Miller

QSYSOPR         *ENABLED        *NO       System Operator    




When you run this command on your system, you may see similar results to this. Several user profiles have matching passwords, and many are enabled. One really nasty entry in the list is the one for QSYSOPR. The QSYSOPR profile has a matching password, and is enabled. Anyone trying to break into your system would most likely try to log-in with the default IBM supplied profiles like QSECOFR, QSYSOPR, etc…


I cannot stress the importance of making sure that no entries ever appear on this list. User profiles should never have matching passwords. If they do,  your system security can easily be compromised.


I like to schedule this report to run automatically each week.  To do this I add and an entry to the job scheduler(WRKJOBSCDE, or other scheduler) to run the command ANZDFTPWD with the selected options. As in  ANZDFTPWD   ACTION(*PWDEXP). This will run the report for you and will set all default passwords to an expired state.





·        Printing User Profile information



The PRTUSRPRF(Print User Profile)  command is a tool I often use to keep track of my user profiles.  The command can be used to print all kinds of information about the user profiles, but the command options that generate the information I usually want to see are as specified here:




This command generates the list shown below. I see all special authorities assigned to user, and the value of the Limit Capability flag in their user profile. Any special authorities held by the user are marked with an X under the special authority they hold. You can also see on the report if the special authority resides in the user profile or in a group profile to which the user is assigned.






                                            User Profile Information                                        Page     1

 5769SS1 V4R5M0  000526                                                                    TIPS1  12/04/01  09:21:25                                                        

  Report type  . . . . . . . . . :   *AUTINFO                               

  Select by  . . . . . . . . . . :   *SPCAUT                                   

  Special authorities  . . . . . :   *ALL                                      

                          -------------Special Authorities-------------        

                                      *IO                                                          Group

  User        Group       *ALL  *AUD  SYS  *JOB  *SAV  *SEC  *SER  *SPL  User          Group       Authority   Limited

  Profile     Profiles     OBJ   IT   CFG   CTL   SYS   ADM  VICE   CTL  Class Owner   Authority   Type        Capability

  MAXMDSF                                    X                       X   *USER *GRPPRF  *NONE      *PRIVATE    *PARTIAL


  MAXKRTM                                          X                 X   *USER *GRPPRF  *NONE      *PRIVATE    *PARTIAL


  MAXFPKL                                                                *USER *GRPPRF  *NONE      *PRIVATE    *PARTIAL


  MAXWWNN                   X     X     X    X     X           X     X   *PGMR *GRPPRF  *NONE      *PRIVATE    *NO





There is one problem with this command that you need to be aware of. Let's say you only want to list users with *ALLOBJ(ALL Object) special authority.  You would enter the command as shown here.




The problem is that unless the *ALLOBJ special authority has been assigned to their individual user profile, their user profile will not appear on this list, making it appear that the user does not have *ALLOBJ.  If the user is a member of a group profile that has *ALLOBJ authority, the report is erroneous.


Since a group profile's special authorities cascade down to the individual user profile level, if the group has *ALLOBJ, all members of that group have *ALLOBJ.


To avoid this problem, specify the command as follows. Then all special authorities held by the user, and by the user's group are listed as in report above.






·        Activating user profiles only when needed



To enable a user profile, and disable it at a particular time on specific days, you can use the command CHGACTSCDE(Change Profile Activation Schedule Entry).


For example, to enable the user profile BOB from 11:00am, and disable it at 5:00pm, on Wednesday, you could use the following command.




However, if you do not remove this activation schedule entry, the profile will be enabled each Wednesday at the specified time.  So, you will manually need to remove the entry after each usage.


To remove a user profile from the activation schedule, run the command



You should note, that even though you disable a user profile, any job using that profile currently active or on a job queue will not be effected.  (i.e.  It will not kill jobs, even though you disable the profile.)




·        Handling Dormant Users


Remember that user from the accounting department that quit two years ago because he wanted to go fishing? Well, his user profile has never been removed, and it is still enabled for use.  I would suggest that this is a bad thing. Dormant user profiles, those that have not been used for awhile, should probably be deleted, but at the very minimum, they should be disabled. Disabling a user profile prevents the profile from being used for logging into the system.


The command ANZPRFACT(Analyze Profile activity) was created for just that purpose.  Enter the command on a command line, and specify a number of days from 1 - 366. Press enter.  You have just added an entry to the OS/400 job schedule that will come alive every day at 1:00am and disable all user profiles that have been inactive for at least the number of days you specified.


But  Wait!  Before you run the ANZPRFACT command, you probably want to run another command first, so you don't hose yourself.  That command is CHGACTPRFL(Change Active Profile List). You run this command to specify user profiles that are exempted from being disabled by the ANZPRFACT command.  For example, you may want to exclude your user profiles that cannot sign-on(i.e. Password=*NONE).   (Note: Many IBM supplied "Q" user profiles are already exempted, so you don't need to make an exception for them. Press F1(Help) on the ANZPRFACT command prompt to see a list of the user profiles specifically excluded by the command.)


The command takes the following form:




To remove user profiles from the exemption list, specify *REMOVE instead of *ADD.


To display the active profile list, you can use the command DSPACTPRFL.


One other issue is that some User profiles used for communications work never actually sign-on to the system, even though they are used everyday. Make sure to add these to the active profile list.


Well, now that we set our active profile list(those profiles that will never be disabled by the ANZPRFACT command), we can get back to the ANZPRFACT command itself. The command is specified as follows:




Here we specify that if a profile has been inactive for at least 180 days, the profile should be disabled. This assumes that the profile is not specified on the active profile list.  The INACDAYS(Inactive Days)  parameter can be specified as a number of days from 1 to 366 days.


So, how does the command figure out when a profile was last used?  Good question.  If the profile object's Last-Used date does not contain a value(never signed on), the object restore date is checked. If it does not contain a restore date(Never restored), the profile's object creation date is used for the calculation.


The command does not disable profiles immediately when you enter the command. Instead the ANZPRFACT command does an ADDJOBSCDE(Add Job Schedule Entry) command to add a job named QSECIDL1 to the OS/400 job scheduler. The job is scheduled to run every day at 1:00am.  If you want to run it at a different time, change the job schedule entry using the command WRKJOBSCDE(Work with Job Schedule Entries).


If you decide that you no longer want to run the scheduled job, you use the command:




This action will remove the job schedule entry.


Whenever a profile is disabled using the ANZPRFACT command, a message is sent to the message queue of the user that ran the ANZPRFACT command, indicating the user profile that has been disabled.  When you receive these messages, you should determine if the user profile can be deleted from your system.



·        What users are members of what Group profile?


I had always looked for a command that would list group profiles, and the members within that group. I just never thought there was such a command.  Well, happily there is one. The command DSPAUTUSR(Display Authorized Users) has a parameter SEQ, that allows you to specify that you want to list out user profiles, within group profile.  Here's the command, and the resulting output.





                            Display Authorized Users                           



 Group       User        Last         No                                       

 Profile     Profile     Changed   Password  Text                              


             BillH       09/11/03            Bill Hines                      

             JEH1        09/12/03            J, Green           

             JEH2        09/16/03            K, Grission

             JEH3        09/16/03            George Only     

             JEH4        09/16/03            Kevin Carter       

             JEH6        09/16/03            Susan Prasley     


             A1624       09/02/03            Luke                       

             A1734       09/26/03            Sally Anne                   

             B1265       09/05/03            Jerry Lewis                    

             H3768       09/18/03            Ted Brown                     

             L5698       09/18/03            Keith Miller                 


 Press Enter to continue.                                                      


 F3=Exit   F11=Password Level Information   F12=Cancel   F17=Top   F18=Bottom






What now?


In order to effectively manage your user profiles, these commands are indispensable. You have these great tools sitting on your system. Put them to use. As you devise and hone your OS/400 user profile security policies, these tools should be in the top drawer of your security toolbox.  


© 2004-2009 Dan Riehl , All rights reserved