With all the user accounts disabled, how do you login?

[Guest.Visitor]

We just got a new AS/400 in and have been experimenting with it. During the process, we disabled our two test user accounts, our test security officer account, and the main QSECOFR account. Do we have to reinstall everything from scratch? Or is there a way to IPL or something so we can enable the accounts?

[Guest.Visitor]

Warren, How did you disable your QSECOFR user? I did not know you could do that, and I've been working with /400 security for many years. Are you sure it's disabled or have you limited the locations that QSECOFR can sign on to and are outside that range? Later, Bret

[Guest.Visitor]

Well... someone didn't know the password (me) and after three attempts the account has been auto-disabled. I can not sign on to the DSP01 with QSECOFR, it just says "Account has been disabled"

[cwscholbe@dstsystems.com]

Warren, You have to do a "manual" IPL and come up under DST (Dedicated Service Tools). There is an option to reset the QSECOFR password. I've never done it, but I think this is where it happens.

[Guest.Visitor]

Warren, You're going to have to use the Dedicated Service Tools (DST) to log on to your AS/400 and reset the QSECOFR password. To start DST, you need to use the AS/400's Control Panel to IPL the system in manual IPL mode. When the first screen appears on the system console, select option 3 to start the DST. When prompted for the DST password, type in QSECOFR. Next, select option 5 to work with the DST Environment. Take option 9 to change the DST passwords. Take option 4 to reset all default passwords (this works for all the shipped "Q" user ids such as QSECOFR, QPGMR, etc.). The QSECOFR password will be reset to QSECOFR. And Brett, QSECOFR can be disabled just like any other AS/400 User Profile. HTH

[Guest.Visitor]

Warren, Go to http://as400service.ibm.com/supporth...ument/10000051 to see how to reset your QSECOFR password by ipl'ing to manual mode and starting DST. Alex Garrison

[Guest.Visitor]

Warren - If you can remember the QSECOFR password, QSECOFR can always sign on from the console (the device referenced by sysval (QCONSOLE) - even if the usrprf is disabled. From OS/400 Security Reference V4R4 - "You can always sign on with the QSECOFR (security officer) profile at the console, even if the status of QSECOFR is *DISABLED. If the QSECOFR user profile becomes disabled, sign on as QSECOFR at the console and type CHGUSRPRF QSECOFR STATUS(*ENABLED)." HTH, Steve

[Guest.Visitor]

Woops, should have mentioned to search for IBM doc 4231240.

[Guest.Visitor]

Steve, Yes! Yes! This is what I meant to say in my obscure posting. While it is possible to *DISABLE the QSECOFR profile, it can still sign on to a device defined as the CONSOLE. Thanks for clearing that up, Bret

[Guest.Visitor]

Gentlemen! Your statements may be correct several years ago, but it does not apply anymore. At least, from version 4.3, if QSECOFR is disabled, it cannot enable itself from the console. I know because I encountered the situation described by Warren more than once. In one instance, the console was the only terminal available, and it was varied off! The trick is to force a manual IPL first (using options from the control panel). During a manual IPL, the console is always varied on, and QSECOFR is always 'enabled'. So the only problem now is finding out the password for QSECOFR. By the way, the method using DST works if you do not know the QSECOFR password... and if the default DST password had not been changed. Makes me wonder... just how many of us do know about the need to change the default DST passwords?