|
||
|
SecureMyi.com Security and Systems Management Newsletter for the IBM i
January 8, 2014 - Vol 4, Issue 1
|
||
|
|
||
|
SecureMyi.com Security and Systems Management Newsletter for the IBM i
January 8, 2014 - Vol 4, Issue 1
|
||
|
br>
|
Checkup on your User Profiles for 2014 and BeyondBy 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 PasswordsThe 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
User
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 PasswordsPrior 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. DSPSSTUSR USRID(*ALL) 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 informationThe 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: PRTUSRPRF TYPE(*ALL) SELECT(*SPCAUT) SPCAUT(*ALL) 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-------------
*IO
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
TXDUSEG
MAXKRTM X X *USER *YES
TXDUSEG
MAXFPKL *USER *YES
TXDUSEG
MAXWWNN X X X X X X X *PGMR *NO
TXDPGMS
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. PRTUSRPRF TYPE(*ALL) SELECT(*SPCAUT) SPCAUT(*ALLOBJ) 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. PRTUSRPRF TYPE(*ALL) SELECT(*SPCAUT) SPCAUT(*ALL) Handling Dormant UsersRemember 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: CHGACTPRFL USRPRF(MYGROUP YOURGROUP) ACTION(*ADD) 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: ANZPRFACT INACDAYS(180) 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: ANZPRFACT INACDAYS(*NOMAX) 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. DSPAUTUSR SEQ(*GRPPRF) Display Authorized Users
Password
Group User Last No
Profile Profile Changed Password Text
ADMINS
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
HELPDESK
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 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. 
|
|
|