Profiles with a Default Password – User Profiles
The Analyze Default Password (ANZDFTPWD) is great, especially if you’re just getting acquainted with IBM i, but I prefer to get information formatted in a way that helps me more easily analyze risk associated with those profiles.
Let’s look at ANZDFTPWD. In addition to the name of the profile with a password that’s the same as the user profile name, the report provides the profile’s status (enabled or disabled), indicates whether the password is expired, and shows the text description, which is somewhat useful information, but if I have profiles with default passwords, especially a long list of them, I want more information so I know where to focus my efforts in setting that password to something other than the default. I want the special authorities so I can address the most powerful profiles first, group and supplemental groups so I can know if it has been assigned to a powerful group, status so I can focus on those that are enabled, last-used timestamp so I can understand if it’s currently in use, creation timestamp so I know when it was created (recently or years ago), the creator so I can educate that administrator on the need to create profiles with a strong password, and the text description so (hopefully) I can have some idea what this profile is used for.
Yes, I could have gotten all of this information by first starting with ANZDFTPWD and then running Display User Profile (DSPUSRPRF) on each individual profile, but why do that when I can get what I need by using one simple SQL statement?
Now let’s take a look at group profiles.
Reviewing the list of profiles assigned to each group is important in order to catch a user who has changed jobs and perhaps been assigned a new group profile but was left with their original groups to facilitate cross-training. To make sure users have access only to the information required to perform their jobs, their group and supplemental group assignments need to be reviewed regularly; I recommend at least once a quarter. To review all members of all groups, simply run this:
If you want to focus on the members of one specific group, such as QPGMR, add a Where clause:
Group profiles aren’t meant to be used for sign-on; therefore, there are several parameters I examine to make sure that can’t happen or that the profile doesn’t show up unnecessarily on reports (such as reports with non-expiring passwords or profiles that are limited capabilities *NO). Yes, you can visually examine the attributes of each group profile to make sure they’re configured correctly, but I think this is much more efficient:
