Admin Alert: Resurrecting the QSECOFR Profile in OS/400

by Joe Hertvik

The first, and easiest, way to reenable QSECOFR--and one that many shops use--is to maintain a duplicate user profile that has *SECOFR authority on the system. Then, when QSECOFR is disabled, or you forget the password, this profile can run the Change User Profile (CHGUSRPRF) command to reset QSECOFR's status to *ENABLED or to change the password.

If you don't have a secondary security user profile, another way to rescue QSECOFR is to understand that a disabled QSECOFR profile isn't necessarily a dead profile. Here's a little-known OS/400 security tip: OS/400 allows QSECOFR to sign on to the system console--but not anywhere else--after the profile is disabled. So, if OS/400 automatically disabled QSECOFR because of an attempted hack, your disabled QSECOFR profile can still sign on to the system console, and you can use CHGUSRPRF to reenable the profile from there, as long as you know what the current QSECOFR password is. I tested this on both an OS/400 V5R1 machine and an OS/400 V4R5 machine, and it worked beautifully on both.

As a side note, the capability to use a disabled QSECOFR user profile from the system console is interesting, because it can also be used as a security technique when your iSeries or AS/400 machine resides outside the firewall. Since a disabled QSECOFR profile can be used from the system console, it can still be available for important things like applying PTFs, upgrading your operating system, or installing software; but it's also protected from attempted hackers who may try to crack the QSECOFR password using a 5250 Telnet session. (Anyone trying to sign on as QSECOFR from a 5250 session or another terminal will receive a message that the profile is disabled.) However, the idea of disabling QSECOFR to protect it does seem a little bizarre, and it can even lead to other problems such as disablement of the Java functionality in the V5R1 iSeries Operations Navigator Management Central GUI. IBM reports that, because OS/400 V5R1 OpsNav support added the OS/400 QYPSJSVR Java server job to support Management Central, QSECOFR must be enabled in order for the QYPSJSVR server to run. (You can find this information tucked away in the "General" section, under "Topics," on the iSeries 400 Systems Management Direction Web site.) It's unclear whether any other new OS/400 functions are also dependent on a fully enabled QSECOFR user profile, so you may find that it's not feasible to depend on a disabled QSECOFR user profile for Internet security. My recommendation is to think long and hard about intentionally disabling QSECOFR before you follow this route.

Signing on to the console with a disabled QSECOFR profile works well for reenablement if you know the password. But what if you've lost or forgotten the QSECOFR password--a situation I like to refer to as "DEFCON2" or Armageddon for your career--and you don't have a secondary security officer profile to change the password with? For such a situation, you must use the third way to reactivate the QSECOFR user profile. Go into OS/400's Dedicated Service Tools (DST) menu to reset the password to its default setting of QSECOFR. DST can be invoked before you IPL your iSeries or AS/400, so here are the steps to bring up DST during an OS/400 V5R1 manual IPL, and to use it to reset the QSECOFR user profile to its default password:

This is the procedure I used to test resetting the QSECOFR password under OS/400 V5R1. For OS/400 V4R5 machines, the procedure is similar but the options inside the Work with DST Environment menu are different. With V4R5, you would select option 3 (DST User Profiles) and Option 4 (Reset System Default Password) in steps 4 and 5. For earlier OS/400 releases, you may find that these options are also slightly different.

So don't despair if your QSECOFR user profile is disabled or you've forgotten the password. IBM has you covered on this one. You just need to know where to look.