[Webinar] Streamline your web hosting managementRegister Today

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1090
  • Last Modified:

ISeries User Profiles

Cannot figure out what is up with my QSECOFR profile.  I can sign on to the system with the QSECOFR but when I try to go to DST or SST, it tells me that the user is disabled.  When I do a WRKUSRPRF the profile is displayed as enabled.  What am I missing?
0
Don1411
Asked:
Don1411
  • 2
  • 2
1 Solution
 
_b_hCommented:
The QSECOFR user profile is separate from the QSECOFR DST profile.

The QSECOFR DST profile password can be changed by QSECOFR user profile using the Change DST password command:
CHGDSTPWD PASSWORD(*DEFAULT)  
Since you have access to DST, sign on to DST using uppercase QSECOFR as the password. You will be prompted to change the password.  This step can also be done from SST depending on your system settings; use DSPSECA to check.

It is generally a good idea to have a backup DST profile that is equivalent to QSECOFR so that it can be used to reset QSECOFR DST password.

Hope this helps!
Barry
0
 
tliottaCommented:
In general, neither the QSECOFR user profile nor the QSECOFR DST profile should ever be used except (1) during initial setup of system security and (2) when IBM instructions direct you to use one of those profiles.

In the case of (1), you should initially use the two QSECOFR profiles to create at least one additional user profile with *SECOFR user class special authorities and at least one additional DST profile with all DST security capabilities. After those are created, use them instead of QSECOFR. Once that's done, there should no longer be much concern about problems with QSECOFR passwords. The QSECOFR profiles would only be needed in normal operation to recover your other profiles if problems come up with them.

(By avoiding use of the two QSECOFR profiles, you minimize the risk of object damage to them. Object damage is rare nowadays, but it happens most often when objects are in use and being updated by the system. Updates may happen when other objects are being created/deleted and ownership or authority is being set in the *USRPRF object. Unexpected power losses, etc., can cause the damage. Recovering damaged QSECOFR *USRPRF objects can require costly help from IBM. The simplest rule-of-thumb is "Don't use them.")

In the context of this question, the existence and use of secondary security profiles for standard system operations and for SST/DST would effectively make the problem irrelevant. Creating such profiles should be the first thing done after signing on with QSECOFR and after accessing SST/DST. The two QSECOFR passwords should be made to be different and then stored in a safe location. After that, they should only be needed in emergencies. The replacement profiles would be the ones used for most things.

Tom
0
 
Don1411Author Commented:
Thanks for the assistance.  I think I have it cleared up now.
0
 
tliottaCommented:
I think Barry's comment should have a significant award of points. It was first; it was correct. I was primarily simply providing background and general justification for avoiding "QSECOFR" rather than directly accessing QSECOFR.

If Barry chooses to follow up, this comment is here for reference.

Tom
0
 
_b_hCommented:
Thanks for the consideration, Tom.
The answers are complete and correct, enough said.
0

Featured Post

Firewall Management 201 with Professor Wool

In this whiteboard video, Professor Wool highlights the challenges, benefits and trade-offs of utilizing zero-touch automation for security policy change management. Watch and Learn!

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now