QSECOFR Password
Mispers2
anyone tell how to go about getting it reset so it can be used again.
Thank You for any help you can give!
Mispers2
c_...@my-deja.com
to know the DST pwd).
Sent via Deja.com http://www.deja.com/
Before you buy.
Jim Thedorf
on using QSECOFR/QSECOFR (for CISC machines it is just QSECOFR). If this
password doesn't work it means that the DST password has been changed, and
the LIC must be reloaded. After signing on you want to WORK WITH DST
ENVIRONMENT, and then RESET DST PASSWORDS. Next you IPL and sign on as
QSECOFR/QSECOFR. Change the password as soon as you sign on.
Jim Thedorf
"Mispers2" <misp...@omantel.net.om> wrote in message
news:8h2cin$j1...@OM9.omantel.net.om...
Thomas
Easiest way is to sign on using any profile with *ALLOBJ and *SECADM
authority and just change the QSECOFR password with CHGUSRPRF. Pretty
much the same as you'd do for any user who lost his/her password.
Unless, of course, no one ever created such a profile. Should be one
of the first profiles created on any new AS/400 installation (IMHO).
Tom Liotta
In article <8h2cin$j1...@OM9.omantel.net.om>,
"Mispers2" <misp...@omantel.net.om> wrote:
> I work at a site were the qsecofr password has be change and forgotten
can
> anyone tell how to go about getting it reset so it can be used again.
>
> Thank You for any help you can give!
>
> Mispers2
>
>
--
Tom Liotta
AS/400 systems programmer
Daniel P. Manaut
there is a way to reset the OS/400 QSECOFR password back to the default. You
will need to use the Dedicated Service Tools -> Work With DST Environment ->
Change DST User Profiles -> Reset System Default Password. Of course you
will need the system key (if keylock is installed on your system) and the
DST password. (Default password(s) listed in same manual).
I had to use this once in the past for a similar issue.
Dan Manaut
Thomas <tho...@inorbit.com> wrote in message
news:8h4npl$98p$1...@nnrp1.deja.com...
Thomas
Sure, but certainly you don't prefer that over the way I outlined?
Actually, if you specifically want a way to reset QSECOFR to the default
password, then simply create a one-line CL program that executes a
CHGUSRPRF for QSECOFR and sets the password to QSECOFR. Compile the
program with QSECOFR as owner and have it adopt owner authority. Grant
authority to the program to any user you want to be able to run it and
exclude everybody else.
Why mess with all the DST stuff unless you actually have to? That's for
emergencies.
Tom Liotta
In article <#k2l9GFz$GA.302@cpmsnbbsa09>,
Joseph Lai
you need to reinstall OS!!!
manual IPL then enter DST mode with
userid qsecofr and password qsecofr
and select reset security!!!
if you cannot use qsecofr and qsecofr
login in DST! then bingo!!!
must install everying!!!
edge
In article <8hgd29$ku...@imsp212.netvigator.com>, josephlai@system-pro-
solutions.com says...
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Richard P. Klein
other things like disk config etc etc
Richard
"edge" <gavinma...@spamcopnospam.net> wrote in message
news:MPG.13a62f74...@my.newsfeeds.com...
Alessandro Monari
>Daniel:
>
>Sure, but certainly you don't prefer that over the way I outlined?
If he had such a profile, maybe he didn't asked...
>Actually, if you specifically want a way to reset QSECOFR to the default
>password, then simply create a one-line CL program that executes a
>CHGUSRPRF for QSECOFR and sets the password to QSECOFR. Compile the
>program with QSECOFR as owner and have it adopt owner authority. Grant
>authority to the program to any user you want to be able to run it and
>exclude everybody else.
How can you achieve this WITHOUT QSECOFR?
>
>Why mess with all the DST stuff unless you actually have to? That's for
>emergencies.
>
Because this is the way to open the door locked from inside.
Anyway, maybe there's another way:
1) find a program wich adopts QSECOFR authorities, is available to a profile you
can access and calls another program (in other words, a security hole);
2) create a CL program named as the called program; this program should call
QCMD or execute CHGUSRPRF;
3) call the program found in step 1.
HTH
Brian B. Christensen
<monaria...@dpinfo.it> wrote:
>
>Anyway, maybe there's another way:
>1) find a program wich adopts QSECOFR authorities, is available to a profile you
>can access and calls another program (in other words, a security hole);
>2) create a CL program named as the called program; this program should call
>QCMD or execute CHGUSRPRF;
>3) call the program found in step 1.
But this is only working if the program in step 1 is compiled with
QSECOFR as owner AND the parameter USRPRF(*OWNER). If the object
domain is *USER it will not work!
Regards brian
Alessandro Monari
wrote:
>>1) find a program wich adopts QSECOFR authorities, is available to a profile you
>But this is only working if the program in step 1 is compiled with
>QSECOFR as owner AND the parameter USRPRF(*OWNER). If the object
>domain is *USER it will not work!
A program compiled with QSECOFR as owner AND the parameter USRPRF(*OWNER) is a
program that adopts QSECOFR authorities. If you look around in your system,
probably you'll find one (many product use this technique to get rid of securiry
problems).
Regards.
Douglas Handy
>If you look around in your system,
>probably you'll find one (many product use this technique to get rid of securiry
>problems).
Or to create them, depending on how they are written ...
Doug
Thomas
Alessandro Monari <monaria...@dpinfo.it> wrote:
> On Sat, 03 Jun 2000 01:40:57 GMT, Thomas <tho...@inorbit.com> wrote:
>
> >Daniel:
> >
> >Sure, but certainly you don't prefer that over the way I outlined?
>
> If he had such a profile, maybe he didn't asked...
>
Yes, I might not have been clear enough that this is something that
should be set up ahead of time, ideally as soon as you get the system in
the first place. I see this as something to be done at just about the
same time you reset the original default passwords on a new system. You
shouldn't have to go looking for ways to hack into QSECOFR later. If you
don't prepare, then you are stuck with DST, etc.
I don't see it as very different from answering "Restore from your
backups" when someone asks "What do I do? My file was deleted
accidentally." You spend a little of effort to prepare in order to save
a lot of effort later.
> >Actually, if you specifically want a way to reset QSECOFR to the
default
> >password, then simply create a one-line CL program that executes a
> >CHGUSRPRF for QSECOFR and sets the password to QSECOFR. Compile the
> >program with QSECOFR as owner and have it adopt owner authority.
Grant
> >authority to the program to any user you want to be able to run it
and
> >exclude everybody else.
>
> How can you achieve this WITHOUT QSECOFR?
>
As above, this is an item of preparation.
> >
> >Why mess with all the DST stuff unless you actually have to? That's
for
> >emergencies.
> >
>
> Because this is the way to open the door locked from inside.
>
True enough. And that's what I meant by "unless you actually have to".
If you don't prepare, then you gotta go the hard way. Whenever possible,
I like to remind others to do a small amount of preparation.