If you live outside the United States, by submitting your email address you consent to having your personal data transferred to and processed in the United States.
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.
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.
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.
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
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
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
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.
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