How to enable a user Profile

15 pts.
Tags:
AS/400
QSECOFR
The only QSECOFR profile was accidentally disabled. How can it be restored to enabled?

Software/Hardware used:
AS400

Answer Wiki

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

Discuss This Question: 6  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
  • TomLiotta
    Sign on with QSECOFR at the system console. You can sign on with QSECOFR when it is disabled if you have access to the configured system console. After you re-enable it, the first thing you should do is create one or two other *SECOFR class profiles and stop using QSECOFR except when directions from IBM say to use it. -- Tom
    125,585 pointsBadges:
    report
  • ToddN2000
    If you cannot log in as QSECOFR you need to log on with another profile that has SECADMIN authority and enable the QSECOFR profile. You can also do it through the service tools if you can log into them. We had a problem here a way back where ops changed the QSECOFR password before a long weekend. When they cam back they could not remember it.. 3 invalid logon attempts and the profile was disabled and were were dead in the water. IBM had to come in to resolve it. We now have a backdoor it it happens again. Take Toms advice if you do get in... create atleast 1 additional profile with the same authority.
    11,025 pointsBadges:
    report
  • TomLiotta
    Note that *SECADM is not sufficient; authority to the QSECOFR profile is also needed. And a secondary *SECOFR profile shouldn't be considered a 'backdoor'; it should be the primary security officer access. The QSECOFR profile itself should be the 'backdoor'. -- Tom
    125,585 pointsBadges:
    report
  • ToddN2000
    I know back doors are a security risk. It was not my call to do so. IBM spent about 6 hours here getting our QSYSOPR sign on back in working order. IBM set up the back door and I believe they have the login information. If it happens again we just need to place a service call. I think you also need a profile with  *IOSYSCFG authority as well to reset QYSYOPR. 
    11,025 pointsBadges:
    report
  • TomLiotta
    IBM spent about 6 hours here getting our QSYSOPR sign on back in working order.   Good example from experience. This relates to why IBM-supplied "Q" object types such as user profiles should not be used by applications. QSECOFR is the most important example, but others can also be significant trouble.   When objects are in use, there is higher risk of object damage. The QSECOFR profile is one of a couple critical profiles that the system relies on for basic operation. QSYS is the other. Those two can be needed simply to start the system.   If QSECOFR suffers any damage, it can be costly to fix it. The cost can be both in lost system time and in IBM consulting services. Damage due to system flaws may be repaired under normal maintenance. But recovery from damage due to customer choices in using QSECOFR instead of a secondary *SECOFR can be chargeable services.   It's too easy just to create your own *SECOFR and use it for running security functions and owning customer objects. Ownership of objects should not be assigned to QSECOFR nor any other IBM profile.   For others threads here, similar consideration should go to using objects such as the QSYSOPR *MSGQ for application messages. Although the message queue can be used, it should be limited to operational functions, e.g., "Load tape" or "Restart printer" kinds of actions. The system itself expects QSYSOPR *MSGQ to be available for its messaging at all times. Use it with care. If you want to "log" messages, then create a MYLOG *MSGQ. It's too easy, and it's simply good practice to avoid interfering with the system itself.   Tom
    125,585 pointsBadges:
    report
  • MDratwa
    In a previous job, I created a program to enable QSECOFR and QSYSOPR.  It was created and owned by QSECOFR.  Only my boss and I knew of this program.  Later I added a parameter to reset the password (or just enable them) as the user name and set to change on next sign on.  (Never told the auditors about it and they never asked.)
    785 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:

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