Admin Alert: Getting Around System i Default Passwords, Part 2
August 1, 2007 Joe Hertvik
|
In the last issue, I discussed how System i default passwords are created, their consequences, and how they can be detected and neutralized. Today, I’m going to shift the focus over to some simple command configurations for limiting or eliminating the proliferation of default password user profiles in your partition. What Are Default Passwords and When Are They a Problem? Default i5/OS and OS/400 passwords occur when a user profile’s password value is the same as its corresponding user profile name (i.e. a user profile called JOE has a password of ‘JOE’). Active default passwords are a security risk because external hackers as well as malicious internal users can easily guess their existence and use them to sign on and create mischief on your system. User profiles with default passwords can be created by using the default password and password expiration values in the green-screen Create User Profile command (CRTUSRPRF). These user profiles can also be created through iSeries Navigator’s (OpsNav) New User feature, but their exposure is limited because OpsNav automatically expires the passwords that it creates for default password user profiles. Automatic expiration forces a user to change their password after the first time they sign on to the system. The mechanics of how default passwords are created, as well as their detection and resolution through the Analyze Default Password command (ANZDFTPWD), were discussed in the last issue. This article demonstrates two techniques for modifying the CRTUSRPRF command to limit or eliminate its problems with creating default password user profiles that can be used over and over again in the system. Solution #1: Automatically Expiring All Default Passwords The main problem with default password user profile creation lies in the difference between creating a user profile in CRTUSRPRF and creating it in OpsNav. CRTUSRPRF does not automatically expire any default passwords that it creates; OpsNav does. CRTUSRPRF leaves these passwords active which enables users to continuously sign on to the system with a default password, creating a larger security risk. OpsNav only enables its default password user profiles for one-time access, after which the password must be changed. So to limit the number of active default user profiles on the System i, it makes sense to modify the Create User Profile command process to automatically expire default passwords as their corresponding user profiles are created, as OpsNav does. The solution to automatic expiration for CRTUSURPRF default passwords is to change the default value for the command’s Set password to expired parameter (PWDEXP) to *YES. PWDEXP’s shipped default value is *NO, which enables default password user profiles to sign on as many times as they want. Once the PWDEXP parameter is changed to *YES, new users will be forced to change their password to a harder-to-guess password the first time they log on to the system, the same way that default password user profiles are automatically expired under OpsNav. So changing this parameter eliminates the difference in the way that the two methods treat default passwords. I can easily change CRTUSRPRF’s PWDEXP default parameter by using the Change Command Default command (CHGCMDDFT) (see this story for more on that). To change the default setting for CRTUSRPRF’s Set password to expired parameter to *YES, I could simply execute this CHGCMDDFT command on a 5250 green-screen. CHGCMDDFT CMD(CRTUSRPRF) NEWDFT(‘PWDEXP(*YES)’) Executing this command causes the following defaults to now appear whenever I use the CRTUSRPRF command to create a new user profile on the green-screen. CRTUSRPRF USRPRF(user_profile_name) PASSWORD(*USRPRF) PWDEXP(*YES) By doing this, all newly created default password user profiles (whether they were created in OpsNav or in CRTUSRPRF) will be forced to change their passwords the first time that they sign on. Changing CRTUSRPRF this way limits system exposure to default passwords, and each user would be in charge of entering their own private password that can never by viewed by a system administrator. The downside to making this change is that it will still leave some default password user profiles on the system, but all of those profiles will now have a short life span. You should also note that changing CRTUSRPRF this way does not force an i5/OS administrator to create each user profile with a default password. These are just default parameter changes that I am working with, and administrators are always free to enter unique passwords for new users and to reset the Set password to expired parameter back to *NO for a new user, if they want. This technique is intended only to solve problems that occur when a new user profile is created with CRTUSRPRF defaults. Solution #2: Eliminating Default Passwords While solution #1 has a harmony all its own, it’s not the only answer to the problem. In researching this article, I ran across several prominent references that suggest the way around the CRTUSRPRF default password problem is to change the default value for CRTUSRPRF’s Password parameter to *NONE. *NONE would specify that the user profile has no password and cannot sign on, unless their user profile is assigned a valid password from the system administrator. To implement this change, I can execute the following CHGCMDDFT command: CHGCMDDFT CMD(CRTUSRPRF) NEWDFT(‘PASSWORD(*NONE)’) The idea here is that it’s better to have a user profile with no password rather than to have a user profile with a default password that everyone in the organization knows. There’s also an implicit assumption that the i5/OS administrator will always have to assign a non-trivial password to the user before the profile can sign on and use the system. The downside on this issue is that this fix can only be implemented for the CRTUSRPRF command. As far as I know, there is no way to change the default values for the Password input box in OpsNav’s New User function. Head-to-Head with Both Solutions There are the two solutions for changing CRTUSRPRF to deal with its default password problems.
It should be noted that if you make either of these changes to CRTUSRPRF’s default parameters, the change could be overlaid the next time you perform an i5/OS upgrade. This is because updated commands are usually delivered with a new operating system and whatever changes you made to the old command will need to be re-applied to the new command. 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. RELATED STORIES Getting Around System i Default Passwords, Part 1 How to Change OS/400 Command Default Parameters
|
