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.
ANZDFTPWD
Report
User profiles with default
passwords Page 1
5769SS1 V5R2M0 000526 OPENSYS
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
SFHHCKM3 *DISABLED *NO
S. Miller
QSYSOPR *ENABLED *NO System Operator
More...
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:
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 to which the user
is assigned.
-----------------------------------------------------------------------------------------------------------------------
User Profile Information
Page 1
5769SS1 V4R5M0 000526
TIPS1
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
TXDUSEX
MAXKRTM
X X *USER *GRPPRF *NONE *PRIVATE *PARTIAL
TXDUSEX
MAXFPKL
*USER *GRPPRF *NONE *PRIVATE *PARTIAL
TXDUSEX
MAXWWNN X X X X X X X *PGMR *GRPPRF *NONE *PRIVATE *NO
TXDPGMX
------------------------------------------------------------------------------------------------------------------------
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 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.
PRTUSRPRF TYPE(*ALL) SELECT(*SPCAUT) SPCAUT(*ALL)
·
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
CHGACTSCDE USRPRF(BOB) ENBTIME('
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
CHGACTSCDE USRPRF(BOB) ENBTIME(*NONE) DSBTIME(*NONE) DAYS(*WED)
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
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.
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:
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
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
If
you decide that you no longer want to run the scheduled job, you use the
command:
ANZPRFACT INACDAYS(*NOMAX).
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.
DSPAUTUSR SEQ(*GRPPRF)
-----------------------------------------------------------------------------------------------------------
Display Authorized
Users
Password
Group
User Last No
Profile
Profile
Changed Password Text
ADMINS
BillH
JEH1
JEH2
JEH3
JEH4
JEH6
HELPDESK
A1624
A1734
B1265
H3768
L5698
More...
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