fhg
Volume 7, Number 28 -- August 1, 2007

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

Published: August 1, 2007

by 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.

  1. You can change the default value for the Set password to expired parameter (PWDEXP) to *YES for the CRTUSRPRF command, so that any default passwords will need to be changed the first time the user logs on. This change makes the CRTUSRPRF command behave the same way as the OpsNav New User function. The downside is that this will leave some default password user profiles on the system until the first time the user signs on and changes the password. Unless you override this parameter at user profile creation, it will also expire passwords for all non-default user profiles that you create with CRTUSRPRF.
  2. You can change the default value for the Password parameter (PASSWORD) in CRTUSRPRF to *NONE so that the user will not be able to log in until the administrator creating the user profile assigns a valid password to the user. This solves the problem with CRTUSRPRF automatically assigning default passwords but it creates a situation where OpsNav New User maintenance behaves differently than CRTUSRPRF. It also places your administrators in charge of assigning unique passwords and your admins will also be knowledgeable of all user passwords, which makes your passwords less secure.

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

Creating Effective Passwords



                     Post this story to del.icio.us
               Post this story to Digg
    Post this story to Slashdot


Sponsored By
COMMON

COMMON Focus 2007 will be our first annual workshop conference event, featuring three days of intense, focused education. It will be a smaller, more intimate event than a traditional COMMON conference with a limited number of attendees - allowing attendees for more one-on-one interaction with the speakers and each other.

There will be 15 in-depth, all-day educational workshops offered - both in lab and lecture-style formats - in a wide range of topic areas. Attendees can attend only one workshop per day, providing attendees the opportunity to focus their educational needs on a specific topic each day.

                                Workshops offered at COMMON Focus 2007 include:

                                Monday
                                · Disaster Recovery Primer - Ready, Set, Plan
                                · Modernizing RPG Applications
                                · Implementing i5/OS Security
                                · (LAB): PHP Essentials
                                · (LAB): WDS and WDSc Guided Tour

                                Tuesday
                                · Disaster Recovery Workshop: Be Well Prepared
                                · All You Need to Know about SQL in Six Hours
                                · System i Access for Web
                                · (LAB): IBM System i Navigator Workshop
                                · (LAB): Hands on VB.net and ASP.net for System i Developers

                                Wednesday
                                · Systems Management Workshop
                                · Beyond the Basics with SQL
                                · RPG Meets the Web
                                · (LAB): Optimize Your System i with IBM Performance Management Tools
                                · (LAB): Using Java to Build System i Web Applications

COMMON Focus 2007 will kickoff on the evening of Sunday, October 14th
with a Welcome Reception, where attendees and workshop instructors can meet and network.
A continental breakfast and lunch will be provided each day, along with several breaks,
giving attendees time to interact with each other.

COMMON Focus 2007 will also have a tabletop-style exhibition area, featuring
a limited number of exhibitors. Attendees will be able to view and get
hands-on demonstration on the latest System i-related solutions available to them.

This innovative educational conference promises to be three days of intense learning -
it is an educational opportunity that you don't want to miss.

Learn more at www.common.org/focus.


Senior Technical Editor: Ted Holt
Technical Editors: Howard Arner, Joe Hertvik, Shannon O'Donnell, Kevin Vandever
Contributing Technical Editors: Joel Cochran, Wayne O. Evans, Raymond Everhart,
Bruce Guetzkow, Brian Kelly, Marc Logemann, David Morris
Publisher and Advertising Director: Jenny Thomas
Advertising Sales Representative: Kim Reed
Contact the Editors: To contact anyone on the IT Jungle Team
Go to our contacts page and send us a message.

Sponsored Links

COMMON:  Join us at the Annual 2008 conference, March 30 - April 3, in Nashville, Tennessee
Seagull Software:  Web-enable your System i apps with LegaSuite GUI
VAULT400:  Securely archive data with Instant Back-Up & 24x7 Recovery


IT Jungle Store Top Book Picks

The System i Pocket RPG & RPG IV Guide: List Price, $69.95
The iSeries Pocket Database Guide: List Price, $59.00
The iSeries Pocket Developers' Guide: List Price, $59.00
The iSeries Pocket SQL Guide: List Price, $59.00
The iSeries Pocket Query Guide: List Price, $49.00
The iSeries Pocket WebFacing Primer: List Price, $39.00
Migrating to WebSphere Express for iSeries: List Price, $49.00
iSeries Express Web Implementer's Guide: List Price, $59.00
Getting Started with WebSphere Development Studio for iSeries: List Price, $79.95
Getting Started With WebSphere Development Studio Client for iSeries: List Price, $89.00
Getting Started with WebSphere Express for iSeries: List Price, $49.00
WebFacing Application Design and Development Guide: List Price, $55.00
Can the AS/400 Survive IBM?: List Price, $49.00
The All-Everything Machine: List Price, $29.95
Chip Wars: List Price, $29.95

 

The Four Hundred
Workload Partitions Not Coming to i5/OS V6R1?

Power6-Based System i Performance and Bang for the Buck

The IT Job Market Is More Competitive, Says Gartner

User Feedback Credited for Inspiring System i Development

The Linux Beacon
Companies Test on Windows, Deploy on Linux

Intel Sets Up 'Tigerton' Xeon MPs Against Future Opterons

The IT Job Market Is More Competitive, Says Gartner

IBM, HP Boast of High Security for Servers with RHEL 5

Four Hundred Stuff
IBM Shows Off Web 2.0 Stuff with Lotus Quickr

Varonis Prevents Unauthorized Access to Unstructured Data

CA Updates System i Development Tools, Renames Them Again

Infor Gives Hitachi Auto's Partners a Leg Up on EDI

Big Iron
IBM Turns In Its Best Second Quarter in Six Years

Top Mainframe Stories From Around the Web

Chats, Webinars, Seminars, Shows, and Other Happenings

System i PTF Guide
July 28, 2007: Volume 9, Number 30

July 21, 2007: Volume 9, Number 29

July 14, 2007: Volume 9, Number 28

July 7, 2007: Volume 9, Number 27

June 30, 2007: Volume 9, Number 26

June 23, 2007: Volume 9, Number 25

The Windows Observer
Microsoft Hits Record Revenues, But Vista Sales Forecast Lowered

Could Windows '7' Provide Virtual Desktop Breakthrough?

NEC, Stratus Flesh Out Fault Tolerant Server Lines

HP Buys System Management Tool Maker Opsware for $1.6 Billion

The Unix Guardian
The Search for Old Hockey Pucks

HP Buys System Management Tool Maker Opsware for $1.6 Billion

Intel Sets Up 'Tigerton' Xeon MPs Against Future Opterons

As I See It: Lawyers, Lies, and Statistics

Four Hundred Monitor
Four Hundred Monitor's
Full iSeries Events Calendar

THIS ISSUE SPONSORED BY:

WorksRight Software
Help/Systems
COMMON



TABLE OF CONTENTS
Use WDSc to Develop XSL Transformations

Have Your Cake and Eat It, Too

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

Four Hundred Guru

BACK ISSUES

From the IT Jungle Forums
Rexx STDIN File

What is holding companies back from using CASE tools?

Hexadecimal thumbprint of a file

Duplicated printer files

Problem with "cpyfrmimpf"





 
Subscription Information:
You can unsubscribe, change your email address, or sign up for any of IT Jungle's free e-newsletters through our Web site at http://www.itjungle.com/sub/subscribe.html.

Copyright © 1996-2008 Guild Companies, Inc. All Rights Reserved.
Guild Companies, Inc., 50 Park Terrace East, Suite 8F, New York, NY 10034

Privacy Statement