** Resetting QSECOFR DST User Profile **
Richard Schoen
We are staging a new iSeries 810 system running V5R2 and cannot get into
system panel option 21 to reset the DST password because the new iSeries has
the Async console which cannot be connected to without the DST password.
We also cannot IPL in manual mode for the same reasons.
We tried resetting the QSECOFR DST password to *DEFAULT, but the system
expires the password right away and you can't change it without going into
DST. Apparently on V5R2 there is also a DST setting that can disable the
QSECOFR profile from changing the DST password from a green screen.
Talk about a classic security Catch-22.
Here's the options as I see them:
1.) Reload OS/400 to reset DST passwords. This would be silly.
2.) Scrap the Async console and put a Twinax card in its place. I guess
twinax does still have a life :-)
Any input on resolving this dilemma without resorting to adding a Twinax
controller would be appreciated.
Regards,
Richard Schoen
RJS Software Systems Inc.
"The AS/400 and iSeries Report and Data Delivery Experts"
Email: ric...@rjssoftware.com
Web Site: http://www.rjssoftware.com
Jim Thedorf
After typing in the QSECOFR/QSECOFR, press F9 (in think this is the funcion
key) to set the password. You should now be able to get into DST.
Jim
"Richard Schoen" <ric...@rjssoft.com> wrote in message
news:oJ1ic.11752$d7....@twister.rdc-kc.rr.com...
Richard Schoen
Thanks for your reply.
We did actually reset the password to *DEFAULT just fine, however with V5R2,
there is another setting within DST that determines if you can change the
QSECOFR DST password from a green screen and apparently this setting was
enabled, so we can't change the password from a regular 5250 session. We
need to get into DST to change the password, but we can't because there's no
way to log into the Async Operations Console without a valid DST password.
This wouldn't be a problem if the machine had a Twinax console. It's the
Async operations console that causes this Catch-22 problem.
Fortunately we have an operational Ethernet connection, so the box can be
used, but we can't do a system backup until the DST password gets reset.
Word to the wise for anyone getting a new AS/400 or iSeries. Go with the
Twinax console until IBM resolves this blunder.
If you have any additional ideas, they would be appreciated. Otherwise I'm
off to my reseller for a Twinax card :-)
Regards,
Richard Schoen
RJS Software Systems Inc.
"The AS/400 and iSeries Report and Data Delivery Experts"
Email: ric...@rjssoftware.com
Web Site: http://www.rjssoftware.com
"Jim Thedorf" <jthe...@nospanallowed-rogers.com> wrote in message
news:cT6ic.4928$Ml....@news01.bloor.is.net.cable.rogers.com...
Jim Thedorf
V5R2 this would reset the DST passwords back to default.
Jim
"Richard Schoen" <ric...@rjssoft.com> wrote in message
news:lr7ic.13727$d7....@twister.rdc-kc.rr.com...
jse...@yahoo.co.nz
> We did actually reset the password to *DEFAULT just fine, however with V5R2,
> there is another setting within DST that determines if you can change the
> QSECOFR DST password from a green screen and apparently this setting was
> enabled, so we can't change the password from a regular 5250 session.
The setting I think you are referring to is the one to allow a service
tools user ID with a default and expired password to change its own
password. The default is no but can be changed from within DST (for
v5r1) or either DST/SST (for v5r2). REGARDLESS OF THIS SETTING, the
DST QSECOFR profile is ALWAYS changeable from DST.
> We need to get into DST to change the password, but we can't because there's
> no way to log into the Async Operations Console without a valid DST password.
Why are you using the QSECOFR profile as a console connection profile?
IBM recommend you create a user ID for this purpose. If you have not
done this, then you should try the default QCONSOLE user ID instead.
If this is disabled then you could try the reset procedure at this
link: http://www-1.ibm.com/servers/eserver/iseries/access/console/resynch_passwords.html
> This wouldn't be a problem if the machine had a Twinax console. It's the
> Async operations console that causes this Catch-22 problem.
For such a core function, I've always thought that reliability was
rather important. Although there are advantages to Ops Console
(remote support etc), there's always a little doubt in the back of my
mind when it comes to this :-)
oogla
Has the 11111111 profile also been disabled? If not, you should be able
to use the following procedure:
1) CHGDSTPWD *DEFAULT
2) Connect the OpsCon. When the service profile login pop-up window
comes up, use 11111111/11111111 as the user/password.
3) If all is well, the console should connect and give you a green screen.
4) Force DST
5) On the DST login prompt on the green screen key in qsecofr with the
default password QSECOFR (case sensitive, caps lock is ignored so use
shift) and use the F9 option to change the password.
6) Once in DST set the option to allow the password to be changed from
SST and also create some more QSECOFR level IDs so you don't have this
happen again.
Additional note, train your users to use the 11111111 profile for the
initial service tools user popup on the console. That then becomes one
less place a careless/distracted/rushed operator is likely to disable
DST qsecofr.