Analyze Default Passwords (ANZDFTPWD)

Where allowed to run: All environments (*ALL) Threadsafe: No The Analyze Default Passwords (ANZDFTPWD) command allows you to print a report of all the user profiles on the system that have a default password and to take an action against the profiles. A profile has a default password when the profile's password matches the user profile name. When the system is operating at password level 2 or 3, both the uppercase and lowercase values of the user profile name are checked. However, mixed case values of the user profile name will not be checked. For example, if the user profile JAMES has a password of 'JAMES' or 'james' it will be detected as having a default password; but passwords of 'JaMeS' or 'James' will not be detected as default passwords. Restriction: You must have *ALLOBJ and *SECADM special authorities to use this command. The format of the report depends on what action is taken against the profiles. When no action is taken, each entry will contain the user profile name, the user profile's status (STATUS), whether the profile's password is expired (PWDEXP), and the text description associated with the profile (TEXT). When an action is taken against the profiles, each entry will also contain the user profile's STATUS and PWDEXP values after the profile has been changed. The list of user profiles with default passwords is also put in the system file QASECPWD in library QUSRSYS. Each entry contains the user profile name, the user profile STATUS and PWDEXP values before and after the profile is changed, and the user profile TEXT value. If no action was requested, the second set of STATUS and PWDEXP values will be blank.

Parameters
Keyword Description ACTION Action taken against profiles Choices Single values: *NONE Other values (up to 2 repetitions): *DISABLE, *PWDEXP Notes Optional

Action taken against profiles (ACTION) The action to be taken against the user profiles that have a default password. The possible values are: *NONE No action is taken against profiles with a default password. *DISABLE The user profile STATUS field is set to *DISABLED. *PWDEXP The user profile PWDEXP field is set to *YES.

Examples ANZDFTPWD ACTION(*DISABLE *PWDEXP) This command analyzes all user profiles on the system. Any user profiles on the system that have a default password will be disabled and their passwords will be set to expired. Error messages *ESCAPE Messages CPFB301 Cannot open file &2 in library &3. CPFB302 Not authorized to check for default passwords.

Admin Alert: Dealing with Default OS/400 Passwords

A necessary part of OS/400 security checking is sniffing out and changing user profiles that contain default passwords. Default passwords occur when an OS/400 password is equal to the user profile name. They occur often when creating new user IDs because default passwords are the default setting for new IDs in both OS/400 V4R5 and V5R1. As a result, many systems may have a number of user profiles that are ripe targets for hacking. Since this is a fairly common situation in OS/400 shops--and one that could endanger the security of an iSeries or AS/400 box--you have to be on guard in detecting and eliminating these passwords. Fortunately, default-password hunting is easy on an iSeries or AS/400 machine. IBM provides the green-screen Analyze Default Password (ANZDFTPWD) command, which allows you to find and automatically disable or expire any user profile containing a default password. This command is standard in most recent OS/400 versions and ANZDFTPWD can run in either batch or interactive mode, depending on your needs. ANZDFTPWD runs in three separate action modes: report only, without affecting user profiles (*NONE); report and disable profiles with default passwords (*DISABLE); and report and expire default password user profiles (*PWDEXP). The action mode is selected through the Action taken against profiles' (ACTION) parameter, and here is a brief description of the three ways you can run ANZDFTPWD. To obtain a report of any user profiles that contain a default password, type the following ANZDFTPWD command from a green-screen command line: ANZDFTPWD ACTION(*NONE) This produces a user-profiles-with-default-passwords report, which lists the following information for each suspect profile: The user profile name. The user profile status (*ENABLED or *DISABLED). Disabled profiles cannot sign in to OS/400. If you're using the green-screen Work with User Profiles (WRKUSRPRF) command to view the user profile, this is the same value as the STATUS parameter. If you're using the iSeries Operations Navigator User Properties dialogue to work with the profile, this is analogous to whether or not there is a check mark in the "Enable user for processing" check box. Whether or not the user profile is currently set to expire. This is a *YES or *NO value that can be found in the "Set password to expired" (PWDEXP) field on the WRKUSRPRF screen, or in the "User must change password at next sign-on" check box inside OpsNav. If a password is set to expire, OS/400 will force the user to change it at his next sign on. The text description associated with the user profile.

Using *NONE for the ACTION merely produces the default-passwords report. It doesn't perform any actions against the dangerous profiles. System and political situations may require you to manually--rather than automatically--take action when dealing with default password users. So IBM allows you to run ANZDFTPWD in a reporting mode only. A prudent plan would be to produce this report automatically on a weekly basis by adding a scheduled entry in the OS/400 job scheduler (which can be accessed by adding a scheduled task command through the Management Central function of OpsNav, or through the green-screen Work with Job Schedule Entries, or WRKJOBSCDE, command). If you want to automatically change user profiles with default passwords, you can run ANZDFTPWD with ACTION set to either the *DISABLE or the *PWDEXP value. You would use the *DISABLE setting as follows: ANZDFTPWD ACTION(*DISABLE) OS/400 will automatically disable any default password user from signing on to your system, and these users will have to come to your department to be re-activated for access. This is drastic action and you might want to run the command in report mode first to make sure you don't accidentally disable any high-ranking figure's user profile, such as your company president, without giving that person a warning. But in terms of security, this will tightly close any default password holes in your system. A less drastic way of dealing with these passwords is to expire the user profile by setting ACTION to *PWDEXP. With an expired password, the next time a default-password user logs in to the system, OS/400 will him them to change his password before he can sign on. This is a nice way to handle the situation because it allows the user--not the system administrator--to straighten out the password without any technical assistance. The down side is if a hacker discovers a default password profile, he can simply change the password himself and then he still has complete access to the system. The important thing to remember is that expiring a password limits your exposure to hackers; it doesn't eliminate it. Regularly running ANZDFTPWD on your system is good policy. And don't think that you can ignore default passwords if your AS/400 isn't attached to the Internet. Internal users are just as capable of committing mischief with someone else's ID as an outside hacker is. A disgruntled user could easily damage your data if you're not vigilant. So if you're responsible for OS/400 security, it's a good idea to get comfortable with ANZDFTPWD and check for default passwords often.

Admin Alert: Getting Around System i Default Passwords, Part 1

Since processing time immemorial, i5/OS and OS/400 computers have had problems with default passwords. Default passwords occur when a user password is equal to its corresponding user profile name. They are mostly created by the system's user creation commands, and i5/OS administrators can spend a lot of time finding and changing these hacker magnets. This week, I'll examine the dynamics of System i default passwords and how they are created. Today's article is part one of a two-part series exploring default passwords and their creation, detection, and prevention. This week, I'll explore the mechanics of how default passwords are created and their consequences. Next week, I'll look at some best practices for preventing or limiting system exposure to these easily guessed passwords.

How Default Passwords Are Created

Many default passwords are nasty by-products of using the green-screen Create User Profile command (CRTUSRPRF). These passwords occur because (IMHO) there are flaws in the default settings for two key CRTUSRPRF parameters. When you use CRTUSRPRF's default settings to create a user profile, you are executing this command with these parameters. CRTUSRPRF USRPRF(user_profile_name) PASSWORD(*USRPRF) PWDEXP(*NO) TEXT('your_text_string') By default, the User password parameter (PASSWORD) is set to *USRPRF, which means that the password for a new user will automatically be set to the user profile name. So if you don't override the PASSWORD parameter with a hard-to-guess password at user profile creation, you are automatically creating a security hole within your system. To compound this problem, the Set password to expired parameter (PWDEXP) automatically defaults to *NO inside CRTUSRPRF. Setting PWDEXP to *NO means that once the user signs on, he will not be prompted to change his password and the default password will remain active in the system. This parameter combination creates an easily guessed password for hackers and internal users who want to make mischief on your system. If an i5/OS administrator has been careless and never changes the defaults when creating new users, any System i, iSeries, or AS/400 box can easily contain a number of active hackable user profiles. Granted, these passwords will eventually expire according to the Password expiration interval parameter (PWDEXPITV) listed in the user profile, but it's a dangerous and sloppy security policy to leave open user profiles on the system. If the system is not correctly configured, users can also change their passwords to a default password by using the Change Password command (CHGPWD), the Change User Profile command (CHGUSRPRF), or the PC5250 Change iSeries Password function (more on this in

the next issue of Four Hundred Guru). So there is a secondary source of default passwords on your system that you need to watch out for. In i5/OS, it takes two steps to solve the default password security issue. First, you need to detect and change (or disable) any existing default passwords on your system to eliminate the risk of hacking, which is the subject of this week's article. You may also want to set up an auditing technique to find new default passwords as they occur. Second, you need to look at your system settings and modify them to prevent additional default passwords from being generated, which will be covered next week.

Detecting and Changing Default Passwords

Both i5/OS and the OS/400 operating system contain a special green screen command to list out all user profiles that contain default passwords. This command is called Analyze Default Passwords (ANZDFTPWD) and it can be run in one of three modes for detecting, disabling, and expiring default passwords. First, to produce a list of users who have default passwords, you would run ANZDFTPWD this way. ANZDFTPWD ACTION(*NONE) In this mode, ANZDFTPWD produces a User profiles with default passwords report that details all users who have default passwords. This report contains the following information for each user. The user profile name. The operating status of the user (enabled or disabled). Whether each default password is active or expired on the system. Expired passwords are designated in the PWDEXP parameter of the user profile, as described above, which forces the user to change his password the next time he signs on. The text description describing the user profile.

This information is also stored in the QASECPWD file in the QUSRSYS library. So if you decide to run ANZDFTPWD as a scheduled job, you could create a program that reads the QASECPWD file and processes it according to your shop's needs. Once you have the report, you can make some decisions on what to do with your default password users. ANZDFTPWD provides two options for dealing with default passwords. You can either disable all user profiles with default passwords or you can set all the default password profiles to a status of expired (*EXPIRED), which will force these users to change their passwords the next time they sign on to the system.

To disable all system users with default passwords, run the ANZDFTPWD command this way: ANZDFTPWD ACTION(*DISABLE) To expire all default passwords on your system, you would run ANZDFTPWD this way: ANZDFTPWD ACTION(*PWDEXP) However, a word of caution is in order here. I highly recommend that you first review the User profiles with default passwords report or QASECPWD file before taking either of these actions. There may be specific reasons some users have default passwords--I'm not advocating their usage, but sometimes people are allowed to have this capability--or it may cause a major shock to your users and help desk if you disable several user profiles at once. Prudence is called for in handling these situations, and you may need to manually work with each user to decide how to resolve the problem.

Is It Any Better with OpsNav?

While it's clear that there is a problem when using CRTUSRPRF to create users with default passwords, what about user profiles and passwords that are created inside iSeries Navigator (OpsNav)? The bad news is that the default password problem also exists with OpsNav-created user profiles. The good news is that the problem isn't as severe as it is when you use CRTUSRPRF. You create new i5/OS users in OpsNav by right-clicking on the Security -->Users and Groups -->All Users node and selecting New User from the pop-up menu that appears. This brings you to OpsNav's New User feature, where you can enter the user name, description, password, and other properties for creating a user. By default, the Password entry box is set to Use user name, which will create a default password for your new user if left unchanged. However, one of the differences between OpsNav user profile creation and CRTUSRPRF is that the Set password to expired parameter has been restyled to a check box on the OpsNav New User panel. This check box is labeled User must change their password at next sign-on. When you designate Use user name in the Password entry box, OpsNav will automatically check (turn on) the User must change their password at next sign-on check-box. OpsNav will also gray-out this check box option when Use user name is selected, so that the user will be forced to change their default password the first time they sign on. If you manually enter a different password in the Password box, the User must change their password at next sign-on check-box will be opened again for modification. So while OpsNav creates the same default password security problem that exists with CRTUSRPRF, it moderates the problem by forcing default password users to change their password the first time they sign on. While this isn't a perfect solution, it limits the problem to users who have never signed on to the system. Once a user signs on, they will have to change their password and their default password problem goes away.

Limiting Default Password Exposure

If you make no other changes to your system, a good first step in eliminating the accidental creation of default password users is to use OpsNav for user profile creation, rather than using the green-screen CRTUSRPRF command. This is because OpsNav will automatically configure default password users so that they will be required to change their password when they sign on. If you're still using CRTUSRPRF, you may want to specify procedures to either always enter a unique password for a new user or to always enter *YES for the Set password to expired parameter. However, since the PWDEXP parameter default is *NO, this could be a spotty solution if people forget to change this setting. You may also want to set up a procedure to automatically print out an ANZDFTPWD report (which will also generate a QASECPWD password file reload) every month for review. However, be careful when printing the ANZDFTPWD User profiles with default passwords report because that report by itself may constitute an audit point. The ANZDFTPWD report should only be printed to a secured location, it should not be left lying around for others to discover, and it should be shredded after use. You should also make sure that the QASECPWD file is secured from *PUBLIC use. These recommendations are simple things that you can do to prevent and detect the use of default passwords. Next week, I'll discuss a few system changes that will further help you win the battle against default passwords.

About Our Testing Environment

Configurations described in this article were tested on an i5 550 box running i5/OS V5R3. Many of the commands may also be available in earlier versions of the operating system running on iSeries or AS/400 machines. If a command is present in earlier versions of the i5/OS or OS/400 operating systems, you may notice some variations in the pre-V5R3 copies of these commands. These differences may be due to command improvements that have occurred from release to release.