DCS12
asked on
Reset QSECOFR service tools password in V6.1
Is there a way to reset the QSECOFR service tools user password in
V6.1 Here is what I have tried:
1. Signed on to the console with QSECOFR
2. CHGDSTPWD PASSWORD(*DEFAULT)
3. STRSST, press F9 to Change the password and it tells me: "Service tools user ID password cannot be changed."
Cause . . . . . : Your system is configured to prevent a service
tools user ID with a default and expired password from changing its own
password.
Is there any other way of doing this?
V6.1 Here is what I have tried:
1. Signed on to the console with QSECOFR
2. CHGDSTPWD PASSWORD(*DEFAULT)
3. STRSST, press F9 to Change the password and it tells me: "Service tools user ID password cannot be changed."
Cause . . . . . : Your system is configured to prevent a service
tools user ID with a default and expired password from changing its own
password.
Is there any other way of doing this?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
What type of console?
Once you've gained QSECOFR DST access, you can change this behavior if you like:
1) Force DST to the console, log on as QSECOFR.
2) Option 13. Work with system security.
3) Change “Allow a service tools user ID with a default and expired password to change its own password” to 1=Yes.
4) Press Enter, then F3 to return to the Dedicated Service Tools (DST) menu. When you are ready to exit DST, press F3 once more and select Option 1. Exit Dedicated Service Tools.
- Gary Patterson
1) Force DST to the console, log on as QSECOFR.
2) Option 13. Work with system security.
3) Change “Allow a service tools user ID with a default and expired password to change its own password” to 1=Yes.
4) Press Enter, then F3 to return to the Dedicated Service Tools (DST) menu. When you are ready to exit DST, press F3 once more and select Option 1. Exit Dedicated Service Tools.
- Gary Patterson
Is there another DST user that has authority to change the QSECOFR DST password? If not, consider setting up one on this (and other) systems.
Barry
Barry
Barry's suggestion should be near the top of the "To Do" list.
I recently took over a system that (a) had security values locked down in DST, (b) used OpsConsole and (c) had the OpsConsole setup on a PC where the hard drive blew. Regaining full control of the system was a difficult task.
When any kind of "remote" console is configured on a system, the necessary security is multi-layered and difficult to get past. You can't just allow anything to plug into a port and magically become the 'Console'. You need the devices to do some hand-shaking just to allow a conversation and you need the humans to supply appropriate authentication values.
If you don't have an alternative already set up, it can be a complex process to get anything working.
The QSECOFR security setup should be the last resort.Secondary security profiles should be created as soon as a system becomes operational, and QSECOFR should only be used after that when IBM directs that it be used. Ideally, the only time QSECOFR should ever be needed is when installing OS upgrades/updates. Otherwise, there is no need for it.
As for the question, CHGDSTPWD *DEFAULT, followed by a QSECOFR DST logon through the console, is the appropriate path.
Tom
I recently took over a system that (a) had security values locked down in DST, (b) used OpsConsole and (c) had the OpsConsole setup on a PC where the hard drive blew. Regaining full control of the system was a difficult task.
When any kind of "remote" console is configured on a system, the necessary security is multi-layered and difficult to get past. You can't just allow anything to plug into a port and magically become the 'Console'. You need the devices to do some hand-shaking just to allow a conversation and you need the humans to supply appropriate authentication values.
If you don't have an alternative already set up, it can be a complex process to get anything working.
The QSECOFR security setup should be the last resort.Secondary security profiles should be created as soon as a system becomes operational, and QSECOFR should only be used after that when IBM directs that it be used. Ideally, the only time QSECOFR should ever be needed is when installing OS upgrades/updates. Otherwise, there is no need for it.
As for the question, CHGDSTPWD *DEFAULT, followed by a QSECOFR DST logon through the console, is the appropriate path.
Tom
BTW, if any of the QSECOFR, QSRV and 22222222 service profiles are still using their default passwords, the "Allow default/expired service profiles to change their passwords" should remain at '2=No'.
Tom
Tom
ASKER
Yes I tried. I will be up there this weekend and let you know how it went.
ASKER
I will be there in 2 days and will let you know how it goes.
ASKER
Two weeks turned into two months. That did get it. Thanks!
ASKER