DST & Qsecofr password Reset

205 pts.
Tags:
AS/400
AS/400 passwords
DST
QSECOFR
hi, anyone help how to reset the Qsecofr usrprf id & Dst Id if Disabled. thanks kingston

Answer Wiki

Thanks. We'll let you know when a new response is added.

Use the CHGDSTPWD command and change to * DEFAULT which will make password QSECOFR. You should than be able to sign on and change.

Discuss This Question: 9  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • DanTheDane
    This link from IBM's knowledgebase may help you: http://www-912.ibm.com/s_dir/SLKBase.nsf/1ac66549a21402188625680b0002037e/b17e4f5b90912282862565c2007d2a41?OpenDocument&Highlight=2,4231240 DanF
    2,555 pointsBadges:
    report
  • kingstoniseries
    hi, Mr bmangan, Thanks for your support, I knw this answer but my question is if DST&QSECOFR both password will be disabled what will be Do. and i dont have the Qsecofr equal rights authority user. at the same time i cant go to os installation way also. pls help any other way is there. Advance thanks kingston
    205 pointsBadges:
    report
  • TomLiotta
    The document from DanTheDane contains instructions to go to this document in your case -- Resetting QSECOFR Password Using DST - Version 5. If you can't use that procedure, IBM is probably the only direction for you to go. Tom
    125,585 pointsBadges:
    report
  • MDratwa
    Create a program to change the QSECOFR password and enable it. Change the owner of the program to be QSECOFR and have the authority to just a couple of users to run it. This way only a known list of users have access to a program which can reset QSECOFR. You can also make a user which will call that program and sign off.
    785 pointsBadges:
    report
  • TomLiotta
    Change the owner of the program to be QSECOFR and have the authority to just a couple of users to run it. This is a good suggestion for a way to help avoid the problem in the future. But note that it won't help with the current problem. If no profile exists that has the authority to re-enable QSECOFR, then there is similarly no current profile with the authority to assign ownership of a USER(*OWNER) program to QSECOFR. But for the current problem, is it clear to kingston that a disabled QSECOFR can always sign on to the system console as long as the password is known? Physical access to the console provides "physical" security. Once signed on at the console with QSECOFR, the CHGUSRPRF command can re-enable QSECOFR. Tom
    125,585 pointsBadges:
    report
  • kingstoniseries
    [...] DST & Qsecofr password reset [...]
    43,525 pointsBadges:
    report
  • WilsonAlano
    Hi,

    I'm not sure but I think that there is there a way to reset DST/SECOFR passwords to default using main panel and key functions?
    I don't remember which manual contains the instructions.

    Google?

    Regards
    Wilson
    2,710 pointsBadges:
    report
  • ToddN2000
    We had that happen here a few years back. Both QSECOFR and SERVICE TOOLS were disabled and we had no other profile with authority to reset them. We had limited access as we could not reset necessary functions. We had to have IBM come in to resolve the issue over a week end it was a long process and I believe cost some $$. It is always a good idea to have a secondary profile with the proper authority for maintaining ALL security and profiles.
    25,240 pointsBadges:
    report
  • TheRealRaven
    ToddN2000 speaks truth from experience here.

    Security profiles and passwords should not have documented ways to bypass. No one should post ways to recover them; and if ways are discovered to reset them (without sufficient authority), vendors should fix such holes immediately.

    It's been known for decades that QSECOFR should not be used as the primary *SECOFR profile. It's a painful (potentially expensive) lesson to learn, but the security of many critical business systems is at risk.

    I, for one, don't want to see methods posted that are not already covered in standard documentation.

    For QSECOFR, all that's needed is to keep its password safely available for those who need it, along with system console physical access. Even a disabled QSECOFR can sign on to the console if the password is known. From there, the rest is easy.
    6,975 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following