Adopted Authority Basics

By Rich Loeber

On your IBM i, every object is owned by a user profile, even if it is just a system default owner profile.  As objects are created, the ownership is established by the person who creates the object.  When new objects are added to your system that were created on a different system, such as third party software or objects restored to your system from another IBM i, the ownership that was in effect on the other system is carried over onto your system.

Program objects have a unique aspect of ownership that many programmers and users of IBM’s i/OS may not be aware of.  There is a setting in each *PGM object on your system that controls authority checking whenever that *PGM object is executed.  This is controlled by the USRPRF parameter when the program is compiled.  For existing programs, it can be changed by the CHGPGM command.

The default setting for the various compilation commands in i/OS, as shipped from the factory, sets the USRPRF parameter to the value “*USER”.  This means that when that program runs, the security settings are checked according to the user profile in effect for the user who actually runs the program.  This is the intuitive setting that you would normally want to have in effect.  When a user runs a program, you only want them to have access to objects on your system that they are authorized to work with.  If they run a program that they are not supposed to be using; one that accesses objects they are not authorized for, then you want the OS security to kick in an prevent the object access.  As long as your programs are set to *USER for the USRPRF parameter, then this is exactly what will happen.

The alternate setting for the USRPRF parameter in programs is *OWNER.  When this is specified, then the program is said to “adopt” the security settings for the user profile that owns the *PGM object (regardless of who is running the program).  So, using this method, someone with fairly limited security authorization can run a program and access objects that they are not normally cleared for.  A good example of when this is desirable would be with a payroll application where a clerk is cleared for file maintenance under program control but you don’t want them to have access to the payroll files for any other purposes.  By having the maintenance program adopt the authority of the program owner, you can accomplish this with ease.

So, what’s the problem then with adopted authority?

The problem is that it can be misused and, under certain circumstances, open your system to abuse.  Because of this, you need to know which programs on your system use adopted authority and then check those programs to make sure that they are well behaved and don’t break any of the generally accepted rules for programs of this type.

As an example, having a program that uses adopted authority which is owned by a user profile with *ALLOBJ authority could lead to a security exposure.  If that program contained an option to display an open command line, then the user could gain access to your entire system.  When reviewing this situation, it is important to remember that not only can security authority be adopted, it can also be inherited.  This happens when a program with adopted authority is run and then calls another program deeper in the program stack.  That called program will inherit the adopted authority of the program that called it from higher up in the program call stack.  This inheriting feature is only in effect for a single call level.  If your called program then, in turn, calls a third program, then the inherit feature is no longer in effect.

IBM’s i/OS contains a reporting feature that will allow you to review programs that adopt authority so you can see where your possible exposures may lie.  The Print Adopting Objects  (PRTADPOBJ) command will let you review this on-line or via a printed report.  It is run by user profile and, at a minimum, you should take a look at all of your user profiles that have *ALLOBJ authority.

This just scratches the surface of the issues associated with programs that adopt their owner’s authority.  For additional research, take a long look at the IBM i Security Manual.  It will show you ways to limit the use of adopted authority and provide additional insights into the issues presented.

More Control over User Profiles

By Rich Loeber

No matter how good your office procedures are for setting up, enabling, disabling and removing users from your system, there is always room for error.  There is nothing like a quick check of your user profile base to help keep your user profiles in good order.  The user profile is a key that lets people into your system and keeping the keys in order is, or should be, a primary obligation of your security controls.

For many of us who have been doing this for a while, the quick review takes the form of a session with the WRKUSRPRF command using the *ALL option.  But, this is a tedious process at best and you can easily miss something important this way.  The ideal would be to get the user profile information organized into various views to focus in on the myriad aspects of security that exist in today’s IBM i world.

Fortunately, IBM’s i/OS contains a facility to help you with this.  The command “Print User Profile” (PRTUSRPRF) has the ability to generate up to four different format reports that will organize your user profile information base to give you a good overview.  The report information for the four different reports concentrate on:

  • Authority type information
  • Environment type information
  • Password type information
  • Password level type information (V5R1 and higher only)

The command has up to four parameters to control the information presented on the listings.  Some of these parameters are context sensitive and will not always be prompted depending on other values you enter.  In addition to indicating which of the four report formats you want, you can also narrow your selection of the specific user profiles to be included, thereby letting you analyze like profiles together.  These selection options let you limit the reports to only users with specific special authority settings and users for specific user classes.  You will probably want to start by specifying all users, but if you’re in a very large shop, this may produce too much information for you to be able to focus in on.

The four reports, however, are the key to using this tool effectively.  The report on authority type information shows each selected profile along with a reference to any group profile or supplemental groups that the profile belongs to.  Then, the special authorities in effect for the user are shown along with their user class, the user profile object ownership setting and other object ownership related information.  A quick scan of this report can quickly show you users that are categorized in an incorrect group, users who are in a group that gives them more access rights than you really intend and many other options.

The report on environment type information presents a different report format.  This report focuses in on the job execution environment in place for each user profile.  These things include the current library, initial menu/library, default job description and other settings that control how jobs run by each user profile will be setup by your system.  This report lets you do a quick audit of user profiles to make sure that they are set up for just the work they should be doing and no more.

The third report produces password type information.  This report lists the current enabled/disabled status of each profile, the current number of invalid signon attempts, the last signon, when their password was last changed and more information that will help with administration of password controls.  In preparing this article, I discovered some unusual values on this report that seemed to indicate someone attempting to gain access to our test system via Telnet using the QSRV and QSYSOPR user profiles.  Both profiles were disabled and the not-valid signon attempts were at the maximum.  Since nobody uses these profiles in our shop, I can only conclude that an illegal signon attempt was made for both of these.  Fortunately, it appears that these attempts failed since we do not have the default passwords still active for any of the IBM supplied ‘Q’ user profiles.  Using this report, you can perform a very quick scan of the setup for each user and quickly spot anomalies, like I did.

The fourth report prints a report on password level type information.  Under the more recent versions of i/OS, you can optionally use longer passwords (up to 128 bytes long) and you can specify a controlled switch over from one setup to another.  This fourth report supplies you with information on how this extended password level is configured for each user on your system.  You can see additional information about this on the system value QPWDLVL and by using the DSPSECA command on these systems.

These four reports, and their various mutations when you use the filtering options, will give you a good tool in keeping current on the status of the user profile pool on your system.  A monthly review of the first three reports would be in order and you can simplify this by just loading these commands into your system job scheduler to automatically run on a monthly basis.

Getting Control over User Profiles

By Rich Loeber

Every IBM i shop has the potential to have active user profiles on the system for users who have left the company.  Unless your personnel department is extra careful about global notifications when people leave, then you may have a security exposure that you don’t even know about.

You can, if you’re careful about setting up user profiles, take care of this problem when new profiles are created.  The “Password expiration interval” (PWDEXPITV) parameter on the Create User Profile (CRTUSRPRF) command lets you set up a separate expiration day interval for each user.  On a system-wide basis, you can also enforce a default expiration interval with the system value QPWDEXPITV.  Using the system value, you just have to use the default *SYSVAL setting for the PWDEXPITV parameter for each user profile.  I suspect that a lot of shops use this arrangement.

However, in every shop, there are users who have passwords that are set to never expire.  This is not recommended, but may make sense for some people who can closely guard their password and use the system heavily.  (I know many programmers and system operators who enjoy this luxury.)  For these people, simply relying on the password expiration interval won’t work, leaving you an even more serious exposure since the type of people who want permanent passwords also tend to have broad access to your system.

The good news is that IBM’s i/OS contains a way for you to enforce periodic expiration on user profiles that have not been used for a specified period of time.  There are several i/OS commands that will help you to enforce a policy of automatically forcing unused profiles to inactive status by disabling them.

The “Analyze Profile Activity” (ANZPRFACT) command will let you set up and control the number of days that the system should use to check for unused profiles.  Then, after this has been set, the system will scan the active profiles on your system once per day and disable those that have not been used for the specific period of time.  Before you start to use this, however, be sure to read on.  (Note, you can disable this check by running this command again and changing the setting to *NOMAX.)

The “Display Active Profile List” (DSPACTPRFL) command will let you display a list of specific profiles that the ANZPRFACT command will ignore when it is checking for unused profile activity.  These might be certain profiles that own object code on your system but are not actually used for signon purposes.  Some applications may require that these owner profiles remain active on your system.  This may be particularly true of third party software.

The “Change Active Profile List” (CHGACTPRFL) command lets you modify this list of profiles on your system.  You can use this command to add or remove entries from the list.  It is important to note that most Q profiles (IBM profiles) are automatically excluded from ANZPRFACT processing.  If you prompt the ANZPRFACT  command and use the HELP facility, you can access a quick list of the Q profiles that are excluded.

It is important for you to check the list (DSPACTPRFL) and update the list (CHGACTPRFL) before any regularly scheduled analysis processing takes place.  This will make sure that you don’t shoot yourself in the foot by disabling a user profile that needs to remain active.  If you use third party software on your system, check with each developer to find out if their ownership profile needs to remain enabled on your system.  Some third party software won’t care of the profile is disabled, but it is important to get the developer’s blessing before taking this step.  If you do have an owner profile that needs to remain enabled, you can always prevent user logon attempts by changing the password to *NONE.

Controlling Telnet Sessions

By Rich Loeber

I am always amazed at how easy it is to establish a Telnet connection with another system.  Just open a command box on your PC and enter the TELNET command along with the IP address of the system you want to connect to.  On most IBM i boxes, you’ll get the familiar signon screen and as long as you have a legitimate user profile and password, you’re in business.  I recently had a IT manager ask me to connect to their system to do some diagnostic work.  They gave me what appeared to be very secure instructions to obtain a sign-on screen from a web-based applet.  I followed their instructions and ended up connecting and getting the work done.  When I was finished, on a whim, I tried a direct Telnet connection to their system and got through without a hassle.  Their IP address was provided through the web-based application sign-on process which was a significant weakness of that in my book as well.

In other tips about getting control over IP server functions, I recommended just shutting off the server function if you use it sparingly or not at all.  Unfortunately, Telnet does not fall into this category.  IBM i Access uses it to establish emulation sessions and most other legitimate methods for establishing a terminal session end up going through the Telnet server.  So, if you shut off Telnet, you’ll be shooting yourself in the foot.

The good news is that there are several things that you can do to get control over how Telnet sessions are issued on your system.  The first big step you can take is to turn of automatic configuration of virtual devices.  For terminal sessions, these are the pesky QPADEVnnnn sessions that you may be familiar with already.  You do this by setting the system value of QAUTOVRT to zero.

Before you do that, check your system to see if there are active sessions using one of these device names.  If so, then you’ll have to contact the users that are coming in with these device names and get their terminal session configurations updated to use a known device name.

Concurrent with this, you will also have to deactivate automatic device configuration.  Without taking this step, anyone can configure a new device name by just using it in a new configuration.  The first time they sign-on, the system will generate the required device description for them.  You can shut this off by setting the system value QAUTOCFG to zero (off).

Once you’ve made these changes, you should then go through your system and manually removed any QPADEVnnnn devices that have already been created and used on your system.  You can view all of these by going to the i/OS menu named CFGVRT and running option #3 or just run the following command:


This will display all of the virtual display devices on your system, just check those with names that start with the QPADEV.

While you’re making these changes, it would also be a good idea to check the system value QAUTORMT.  This should also be set to zero (off) to help assure a secure system.  This value is used for automatically creating remote controller devices.

Some of your people may rely on automatic device configuration when new devices are attached to your system, and that’s probably still OK.  But, it doesn’t happen every day in most shops which is a good reason to keep it turned off most of the time.  When you need automatic device configuration, you can activate it for a few minutes as needed and then shut it off again.

If you want even more control over Telnet session, you can activate the required exit point and check for specific source IP addresses and only permit Telnet session that are coming from a known address.  Our SafeNet/i network security software includes this feature and we turn away illegal connection attempts to our system on a daily basis with this activated.

Working With IFS Security

By Rich Loeber,

For years, IBM’s i/OS provided robust security for its native file system.  For some of us who’ve been around for a while, this has been all we’ve known on our systems.  But, these days, more and more applications and users are working with the other non-native file systems that are collectively known as the Integrated File System, or IFS.  IBM’s i/OS provides the same level of security in the IFS, but the commands to review items in the IFS and a lot of the terminology is different from what the “natives” may expect to see.  This article will attempt to scratch the surface of this issue by explaining how you can view the IFS directories and files from your i/OS command line and how to interpret the security settings used in the IFS.

The main command that you need to start with is the “Work with Object Links” command (WRKLNK).  These “links” can take several different types, the most common of which are directories (DIR) and stream files (SMTF).  If you thought about this from a PC perspective, these would correspond to disk directories and files.

If you use the WRKLNK command with no parameters, a complete list of all of the top level directories in the IFS (the root) will be displayed.  This display will let you explore the entire IFS on your system, including the “native” file system which will be included under the QSYS.LIB file system.  If you want to go directly to a specific directory, you can do so with a qualified OBJ selection parameter.  For example:

WRKLNK OBJ(‘/qdls/kisco’)

On our test system here, we have a directory in the shared folders file system named KISCO.  The shared folders system is found in the QDLS file directory.  Running the above command gets us straight to this folder without having to spend time searching.

To check on the security setting for an displayed object, just put a ‘9′ next to that object.  This will bring up a Work With Authority display and will give you all of the security information about the object selected.  This will include the owner, any applicable authorization list, any public authorization settings and a list of user profiles that are authorized to the object.  If you want to print this information for an off-line review (or for security documentation), you can use the Display Authority command (DSPAUT).

Data authority in the IFS is described by a series of letter codes which, in combination, will describe the authorities in place.  The applicable access letter codes are as follows:

R – Gives access to object attributes (think READ)
W – Gives access to the object for change (think WRITE)
X – Allows the object to be used (think USE)

You will see these codes in combination or singly (preceded by the ever present *), depending on the authorities implemented.  For example, if full authority is being granted, then you will see the *RWX authority setting displayed.  Specific object authorities are also displayed on this screen.  You can use this screen to make changes and to check on specifics for any object shown by placing a ‘2′ next to the line in question and making updates.

So, if you’ve never (or rarely) considered what’s going on in the IFS on your system, now is the time to get started and the WRKLNK command gives you are very good starting point.

A Solution for the Clear Physical File Member (CLRPFM) Quandary

By Trevor Seeney

All too often I see IBM/i security schematics that gives All Object (*ALLOBJ) to all the user profiles. I have recently seen a security schematic that did not have *ALLOBJ authority at the user profile level but instead had all (*ALL) authority applied to all objects.  Both of these schematics amount to no security at all because all the users can delete any object!

In the ideal world, all physical files should have *CHANGE authority assigned to the general user community (i.e. *PUBLIC), that enables the object to be ‘operated’ (Opr) on but there are no ‘management’ (Mgt) or ‘existence’ (Exist) rights. Existence rights are needed to delete or clear a physical file.

In the real world, most applications use the CLRPFM command. The use of CLRPFM really demands that for each file that is the target of a CLRPFM command, existence rights need to the granted to the target file to avoid an authentication failure during execution.

To be correct, what is required is to identify each incidence of the CLRPFM command and grant object existence or *ALL authority to the target file. Finding instances of the CLRPFM command is straightforward enough using the search capabilities of the Program Development Manager (PDM), but then changing the authority on the individual files is a laborious effort. As such, this effort is often not done and the easy way out is taken, that being to grant *ALL authority to all of the physical files. Not good!

There is a quick, albeit sneaky, way of identifying the targets of the CLRPFM command and granting existence rights to the file. The solution deploys a user-defined variation of the CLRPFM command with a Validity Checking Program attached.

Validity Checking Programs

When creating a user-defined command, you can attach a VCP that can be used to perform additional validity checking of the command’s parameters that are not provided for within the command definition itself. To perform these additional validity checks, the CL Syntax Checker runs the VCP when a command with one attached is entered (or changed)  in a source member. Putting it another way, when a command with an attached VCP is entered using the Source Entry Utility (SEU) under CL syntax, the program executes right there and then! In fact, if you compile the CL program, the VCP will execute during compilation.

Before we tackle solving the CLRPFM quandary with a VCP let’s take a couple of minutes to knock up a quick example. We’ll write an abbreviated Work Active Job command.


  • Type into QCMDSRC file a member called WAJ (for work active job) the single line ‘CMD
  • Type into QCLLESRC file a member called RETURN, the single line ‘RETURN’ and compile. This will be the command processing program
  • Type into QCLLESRC file a member called WAJ, the single line ‘WRKACTJOB’ and compile. This will be the validity check  program
  • Create the command as follows:- CRTCMD CMD(WAJ) PGM(RETURN) SRCMBR(WAJ) VLDCKR(*LIBL/WAJ).

Entering the command WAJ into a source member under CL syntax will cause a Work Active Job display to be launched from within SEU!

Compiling the CL program will cause a Work Active Job display to appear again.

Solving our CLRPFM Quandry with a VCP.

Let’s now apply the technique above to the CLRPFM command. We’ll name our command @CLRPFM.  Since the CLRPFM command has parameters, our programs are a little more involved but not by much.

In Figure 1 below at call-out A is the command definition of the command @CLRPFM.  With parameters representing a qualified file name and a member name.

At call-out B is the VCP which is executing the Grant Object Authority command.

At call-out C is the CPP which has no executable commands.

* It should be noted that the CPP and the VCP should have the same parameters passed whether they are used or not.

Finally at call-out D is the command creation string.

The underlying search function of PDM is the command Find String PDM (FNDSTRPDM) and we can execute same over our production CL source file to find all occurrences of CLRPFM and change them to @CLRPFM by inserting the @ sign. This will cause the VCP to execute and thereby grant *ALL authority to the *PUBLIC for the referenced file. Repeat the ‘Find’ within the member until all CLRPFM commands have been found and then exit the source member without update. Repeat until FNDSTRPDM has finished executing.



Using the technique described herein will apply existence rights, i.e. the right to clear file, for only those files that need it. All other files will have the standard authority applied.

About the Author:

Trevor Seeney is the Technical Director at Sentinex Inc. Trevor is a specialist in IBM/i system security. A COMMON presentation entitled ‘How an iSeries/400 is hacked and how to stop it’ spawned an article for Midrange Computing and a Webinar on Search-400. Trevor also developed a workstation security product for the System/i, which secures inactive work stations and is commercially available today under the name of ScreenSafer/400 and is distributed by Kisco Information Systems.

Controlling Remote Command Processing

By Rich Loeber,

One of the cardinal rules of securing your IBM i system is to prevent users from having open access to the i/OS command line unless absolutely necessary.  Typically, access to the command line is limited to operators, programmers and other IT staff users who need it to get their jobs done.  But, users in general should never be granted the use of the command line.

But, a knowledgeable PC user, using PC-based software tools such a iSeries Navigator, can run commands on your system without obtaining a signon screen and command line.  Also, when a user submits a remote command, IBM’s i/OS does not honor the Limit Capability (LMTCPB) setting for the user profile in use.  In my book, that is a significant security exposure!  Granted, the user must be knowledgeable, but it can be done.

There are several ways that this can be accomplished, as follows:

•    Using DDM (Distributed Data Management), a user can open a file and use the remote command function to run any command on the remote system.

•    Using the iSeries Navigator client, or other similar PC software, a user can issue a command through DPC (Distributed Program Call) APIs without even using DDM.

•    Using remote SQL and ODBC, some software can provide a remote command function without using either DDM or DPC

So, what’s a security officer to do?

To deal with the DDM issue, one easy way to control this is to simply turn DDM access off completely for your system.  You should first verify that no current applications running on your system require DDM, DRDA (Distributed Relational Database Architecture) or DB2.  To shut DDM off, simply run the following command:


This step is pretty drastic and will obviously not work for many shops where DDM, DRDA and/or DB2 are in use on a regular basis.  For those shops, your best defense is an aggressive security policy that protects your critical data assets.

If you want to take an more active approach to this issue, then you’ll have to look into coding an exit point program, or you can purchase a third party software package that implements exit point processing.  The easiest approach when creating your own exit program is to limit use of remote commands to a list of known user profiles.  This will allow you to grant permission to process remote commands for known and trusted user profiles while denying permission to all others.  In the exit point process, you can set a flag that will return a failure status to the PC software issuing the remote command process, so your user will know why their attempt failed.  You can find more information about exit point programming in several different manuals.  These include:

  • Implementation Guide for iSeries Security and Auditing – GG24-4200
  • iSeries Security Reference – SC41-5302
  • iSeries System API Reference book

Network/Internet Security

By Rich Loeber,

When your IBM i system is connected to a network, you cannot always guarantee the integrity of the person at the far end of a network connection. If your system is connected to the Internet, ethics go out the window altogether. You have to assume that the person at the far end is a bad guy, then proceed from there. With this tip, we’ll outline an approach to this problem that may help you to focus in on how to deal with the bad guys wherever they may be.

Internet bad guys generally fall into two categories, sneaks and bullies. The bullies you can probably identify easiest, they are the ones who go after you system with active attacks. They will try to break into your system trying just about everything in the book. On our test IBM i server in the office recently, we had a bully come by who tried to log on using over 700 different user profiles in a period of 5 minutes. Each logon attempt was met by our exit point software and tossed out right at the point of entry with a security warning message to our security officer for each try. The user profiles were all different and all “typical” of what you might expect to see in just about any shop in the country. When a bully comes after you, he does it with brute force. They can try to spoof your system, guess your passwords, deny others from using your system by keeping it overly busy dealing with their break-in attempt and much more.

The sneaks are a lot more passive. A sneak will sit back and monitor network traffic to your system and try to uncover secret information that will then give them what they need to gain access to your system “normally”. Sneaks are very hard to identify and the have insidious tools at their disposal to get the information they want. This can even include Trojan horses that gather the information for them. Since sneaks are so hard to identify, you should plan your security strategy assuming that someone is always watching your system.

To guard your system against both sneaks and bullies, you need to think about how to layer your system defenses to guard against anything and anyone. If your system is connected to the Internet, you must assume that a sneak or a bully is going to attempt to gain access and plan accordingly. The best defense is always a good offense and you should consider the various layers of your system and have a plan to deal with intruders at every level. This layered approach will help you develop a good defense. The layers you should give consideration to include:

  • System security – including your system level use of user profiles and regularly rotated passwords. For most IBM System i shops, this will be your last line of defense, so plan it well.
  • Network security – this commonly involves implementation of a firewall between your network and the Internet but can also include services available from your ISP. On the IBM i there are also things that can be done at the IBM i/OS server level via exit programs that can address network security issues.
  • Application security – your applications should be designed to integrate with your security policies. Application software can easily be misused and abused and your applications should be designed with this in mind, especially those applications that are open to network and Internet users.
  • Transmission security – when you use an uncontrolled network like the Internet, your data will be open to anyone while it is in transit from one place to another. To protect your data, you need to consider encryption techniques and the use of Secure Sockets Layer (SSL) on your IBM i server.
In your plan for Network and Internet security, you need to have a plan for each of these layers of control in order to guarantee your system. And, even then, a bully or a sneak might still get past you, so watch out.


Securing Printed Output on your IBM i

By Rich Loeber,

In today’s security conscious environment, most System i shops have already locked down their systems.  Object level security is locked down and users are classified as to what they can and cannot do when they are logged onto the system.  But, securing files is only part of the problem.  If a user can’t look at a file, but they can look at processed output sitting in a print spool file, then your hard work of locking up the files is for naught.

There are several things you can do to control spool viewing.  For starters, review your user profiles to see which users have the special authority of *SPLCTL or *JOBCTL.  Both of these special authorities can give a user access to spool files.  Only security officers and system operators should have these authorities.  In a smaller shop, this might also extend to your programmers, but not always.  Generally speaking, most users should not be given these authorities unless they absolutely must manage their own print spool files and job controls.  As a first step, these authorities should be limited as much as possible, especially the *SPLCTL authority because it is not subject to any restrictions and allows the user access to all spool files on your system.

Output spool files are special objects on your system and are not, per se, created with standard IBM i/OS security controls.  The way you can control security on spool files is through the way your output queues are set up and authorized.  If you have output reports with sensitive information, you can control who can see them by the output queue where the report is stored.  Output queues are created using the CRTOUTQ (Create Data Queue) command and they can be changed using the CHGOUTQ (Change Data Queue) command.  You can view the way and output queue is configured with the WRKOUTQD (Work with Output Queue Description) command.

The user profile that creates the report can always view it and control it.  Sensitive reports should be created using a restrictive user profile to prevent widespread use of the spool file.  To impose even stricter security, there are several parameters you can set when you create an output queue that will provide more control:

  • DSPDTA    Helps to protect the contents of spool files be defining who can display, copy, move or send a spool file in the output queue.
  • AUTCHK    Defines what authority is needed to change or delete a spool file.
  • OPRCTL    Defines whether a user profile with *JOBCTL authority can work with spool files in the output queue.

Using these three parameters, you can impose very restrictive access controls to spool files associated with an output queue.  There is a good chart in the Security Reference guide that shows how the three parameters work together.  If you have never given this concept much thought, you should conduct a thorough review of how your current output queues are set up to make sure that they conform to your company’s security policies already in place.

Checking For Default Passwords

By Rich Loeber,

When you create a new user profile, there are a ton of parameter values that you can select from to customize exactly how that profile will work on your system. A lot of us, because of time constraints or ignorance, have a tendency to take a lot of the defaults that IBM’s i/OS presents to us. One of those defaults, unfortunately, is the user profile’s password. Using default passwords is never a good idea, even when you’re rushed for time. This tip will show you an easy way to identify default user profiles on your system so you can get these passwords changed. A recent study I read showed a surprising number of IBM i shops that use at least some default passwords in their day-to-day operations, don’t be one of them.

IBM ships its i/OS with the default value for the PASSWORD parameter on the Create User Profile (CRTUSRPRF) command set to the special value of *USRPRF. When you use this setting, the password for the user profile is set to the same as the user profile itself. So, if I set up a user profile for RICHARD and leave the PASSWORD parameter set to *USRPRF, then the password for RICHARD is going to be RICHARD. It won’t take a rocket scientist for someone who wants to get into your system to be able to figure out how to log on with this in place.

If you’re concerned about this, it would probably be a good idea to change the default setting for the PASSWORD parameter from *USRPRF to *NONE. In my book, having no password is better than having one that everyone will know. You can make this quick change by just running the following Change Command Default (CHGCMDDFT):


If you do this, remember that the next time you upgrade your installed version of i/OS, the setting will get changed and you will have to repeat this process.

Fortunately, i/OS provides you with a nice utility that will let you analyze the profiles on your system and identify any that have the default password in place. The command to do this is Analyze Default Passwords (ANZDFTPWD) and can be found on the SECTOOLS menu. When you run this analysis, a listing of all user profiles with default passwords will be produced on your system. This listing will show the profile status and whether or not the password has expired.

If you want to quickly take care of any current default password profiles on your system, there is a parameter on the command called the ACTION parameter. It defaults to *NONE, which will not take any remedial action. If you choose, you can use either the *DISABLE option or the *PWDEXP option (or both). Selecting these options will immediately disable any profiles that are currently useable that have default passwords in place. The second option will set the password to show that it is expired. Both will stop the user profiles in question from further use.

Obviously, before taking remedial action, it would be a good idea to make a best effort to contact any affected users to let them know that they will have to change the password they are using when this change is made.

Personally, I think IBM should just do away with default passwords completely. They removed security level 10, and I think this falls right into that same category.

If you have any specific questions about this topic, you can reach me at (, I’ll try to answer your questions. All email messages will be answered.