Sure you can use ANZDFTPWD (Analyze Default Passwords) to get a list of IBM i users with default passwords. You can also use some simple SQL in conjunction with the USER_INFO IBM i service in QSYS2 to do the same thing…but better.
To get the standard ANZDFTPWD report you can run the following statement:
So why use SQL?
ANZDFTPWD gets you everything you really need to determine who has a default password right? Well, yes. However, ANZDFTPWD doesn’t give you the full picture or allow you to be proactive. It doesn’t gauge severity of those user profiles in the result set either. ANZDFTPWD just shows you what accounts have default passwords, if the account password is set to expire and if they’re enabled or not.
With SQL you can find other information like users with special authorities, their default menus/programs, and a whole lot of other good information to determine a more accurate risk assessment. Maybe you want to find out if users have signed on recently or never at all. A profile with a recent sign-on means that they’re potentially a bigger security concern as perhaps the account has already been compromised. An account that hasn’t signed on hasn’t had the chance to do any damage…yet.
If we expand on the statement we can find enabled users with default passwords who have special authorities but only accounts that have signed on already. That doesn’t mean the accounts that haven’t signed on aren’t a problem. Run this without the PREVIOUS_SIGNON filter too.
But there’s more info to glean!
Let’s take it a step further and find out who’s creating those accounts by using the USER_CREATOR field. Maybe you have a few people who can create accounts but only one person is building them with excess authority. Or maybe the problem is widespread for all account creators. In this example we want a similar filter but only retrieve the profile (AUTHORIZATION_NAME), the person who created the account (USER_CREATOR) and the date/time it was created (CREATION_TIMESTAMP).
While no accounts with default password are acceptable, you can certainly narrow your list down to prioritize some of the most important accounts to fix, and perhaps the associated processes that created them wrong in the first place.