Security and Systems Management Newsletter for the IBM i                 January 8, 2014 - Vol 4, Issue 1
Skyview Partners
Software from Cilasoft

Skyview Partners

      Security Training from The 400 School

      Security Training from The 400 School br>

      Security Training from The 400 School

Checkup on your User Profiles for 2014 and Beyond

By Dan Riehl

IBM i 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 may want to add to your security management 'bag of tricks'.

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 passwords that exactly match the UserID name. These matching Passwords are called 'Default Passwords'. 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 the ANZDFTPWD command.

                  User profiles with default passwords	           Page    1

5770SS1 V7R1M0  100423	                        OPENSYS   01/03/14  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.

Checking up on SST/DST UserID and Passwords

Prior to IBM i 6.1, if you wanted to check for Default Passwords for Service Tools UserIDs, and general Service Tools User Settings, you had to Start System Service Tools(STRSST), and provide a valid service tools UserID and Password. As of IBM i 6.1, IBM has provided the Control Language command Display System Service Tools Users(DSPSSTUSR), which allows you to view the settings of your Service Tools Users.

Here is an example of using the DSPSSTUSR command to display a list of all SST Users to your display.


When examining the SST Users, you can easily spot Users for which the password has never been set from its original shipped value. Here we see that SST User 11111111 has never signed on to SST('Previous sign-on' is None), and the 'Date password last changed' is None. In this case, the password for the SST user 1111111 is the matching IBM shipped default value of 1111111.

                  Display Service Tools User ID                         
                                                        System: OPENSYS
 Service tools user ID  . . . . . . . . . . :   11111111                       
 Previous sign-on . . . . . . . . . . . . . :   None                           
 Password verification not valid  . . . . . :   0                              
 Status . . . . . . . . . . . . . . . . . . :   *ENABLED                       
 Linked user profile  . . . . . . . . . . . :                                  
   Linked user profile exists . . . . . . . :                                  
 Date password last changed . . . . . . . . :   None                           
 Date password expires  . . . . . . . . . . :   None                           
 Password is set expired  . . . . . . . . . :   No                             
 Description  . . . . . . . . . . . . . . . :   11111111                       

In contrast, below we see the SST User QSECOFR for which the password was last changed 06/20/13.

                         Display Service Tools User ID                         
                                                             System:   OPENSYS
 Service tools user ID  . . . . . . . . . . :   QSECOFR                        
 Previous sign-on . . . . . . . . . . . . . :   09/11/13  14:24:41             
 Password verification not valid  . . . . . :   0                              
 Status . . . . . . . . . . . . . . . . . . :   *ENABLED                       
 Linked user profile  . . . . . . . . . . . :   QSECOFR                        
   Linked user profile exists . . . . . . . :     Yes                          
 Date password last changed . . . . . . . . :   06/20/13                       
 Date password expires  . . . . . . . . . . :   None                           
 Password is set expired  . . . . . . . . . :   No                             
 Description  . . . . . . . . . . . . . . . :   QSECOFR                        

In addition to checking your IBM i User Profiles for default Passwords, it is important to also check for Service Tools User ID passwords that have not been changed from the original Default Value.

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 of which the user is a member.

                        User Profile Information                             Page     1
 5770SS1 V7R1M0  100423                                      OPENSYS 01/04/14  09:21:25

  Report type  . . . . . . . . . :   *AUTINFO                                
  Select by  . . . . . . . . . . :   *SPCAUT                                    
  Special authorities  . . . . . :   *ALL                                       
                          -------------Special Authorities-------------         
  User        Group      *ALL  *AUD  SYS  *JOB  *SAV  *SEC  *SER  *SPL  User   Limited
  Profile     Profiles    OBJ   IT   CFG   CTL   SYS   ADM  VICE   CTL  Class  Capability
  MAXMDSF                                   X                       X   *USER  *YES
  MAXKRTM                                         X                 X   *USER  *YES 
  MAXFPKL                                                               *USER  *YES
  MAXWWNN                  X     X     X    X     X           X     X   *PGMR  *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 inside 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 user will inherit *ALLOBJ from its group, but the report will not show these inherited special authorities.

Since a group profile's special authorities are inherited by the individual user profile, if the group has *ALLOBJ, all members of that group have *ALLOBJ.

To avoid this reporting problem, specify the command as follows. Then ALL special authorities held by the user, and by the User's groups will be listed, as in report above.


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 WRKJOBSCDE 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(Display Active Profile List).

One other issue is that some User Profiles used for communications work(e.g. QUSER) never actually sign-on to the system, even though they are used everyday. Make sure to add these to the active profile list. Also add Users that are only used for FTP Logon. FTP Logon does not update the 'Last Used Date' nor the 'Last Sign on Date' for a User Profile that is used for FTP exclusively.

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 ANZPRFACT command does not disable profiles immediately when you enter the command. Instead, under the covers, the command does an ADDJOBSCDE(Add Job Schedule Entry) command to add a job named QSECIDL1 to the IBM i 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 simply remove the Job Schedule Entry from the WRKJOBSCDE command display, or use the command:


This command will remove the Job Schedule Entry.

Whenever a profile is disabled using the ANZPRFACT command, a message is sent to the message queue assocaited with the job Schedule Entry, indicating the user profile that has been disabled. When a profile has been disabled by this utility, you should determine if the user profile can be deleted from your system.

What users are members of what Group profiles?

The DSPAUTUSR(Display Authorized Users) command allows you to list the User Profiles on your system. The command has a parameter SEQ, that allows you to specify that you want to list your User Profiles, within their respective groups. Here's the command, and the resulting output.


                    Display Authorized Users                            
 Group       User        Last         No                                        
 Profile     Profile     Changed   Password  Text                               
             BillH       11/11/13            Bill Hines                       
             JEH1        12/12/13            J, Green            
             JEH2        11/16/13            K, Grission 
             JEH3        12/16/13            George Only      
             JEH4        11/12/13            Kevin Carter        
             JEH6        11/11/13            Susan Prasley      
             A1624       11/02/13            Luke                        
             A1734       11/26/13            Sally Anne                    
             B1265       11/05/13            Jerry Lewis                    
             H3768       12/18/13            Ted Brown                      
             L5698       12/18/13            Keith Miller

And, 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 IBM i user profile security policies, these tools should be in your top drawer.

I also encourage you to check out these additional articles that specifically deal with securing your User Profiles.

    User Profile Hijacking and How to Avoid the Problem

    Create User Profile Exit Program User Profile Ownership Issues

About the Author

Dan Riehl is the Editor of the SecureMyi Security Newsletter and a Security Specialist for
the IT Security and Compliance Group

Dan performs IBM i security assessments and provides security consulting, remediation, forensic evaluations, and other customized security services for his clients. He also provides training in all aspects of IBM i security and other technical areas through The 400 School, Inc.

Dan Riehl on LinkedIn

      Security Training from

© Copyright 2014 - IT Security and Compliance Group