Limiting User Abilities

10 pts.
Tags:
AS/400
CLP
DataCenter
Security
We have an administrator here that we are trying to limit access on and I wanted to know if anyone else has solved this issue. I spoke with IBM and we have restricted the access to ADDUSRPRF and DLTUSRPRF commands and we have also restricted access to certain user profiles like QSECOFR and QSYSOPR. The problem is that this user needs to be able to re-enable user profiles as part of his on-call duties. The IBM technician said that there might be a way to further limit him with a CL program. Has anyone else been able to figure this out?? Thanks!!

Answer Wiki

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

You could create a CL program that adopts authority by the owner, and make the owner QSECOFR. The program could accept a user profile and the program would change the user profile re-enabling it only. A command could be created asking for the profile and passing the profile to the program. You could then grant access to the CL program to anyone that needs to re-enable profiles, but does not have other SECOFR authorities.

Discuss This Question: 5  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
  • Rayne427
    Thank you. I am not really the best CL programmer. I was hoping that maybe someone could give an example...
    10 pointsBadges:
    report
  • astradyne
    Hi You can do this by creating a CL program that is defined as the initial program for a user profile whose only task is to reset passwords. When the user profile signs on, a screen is displayed asking for an ID and temporary password. The ID and password are reset and the next time the reset ID signs on they will have to change their password according to the system rules. To do this, first create a display file, CHGUSRPWD, in QGPL. The source can be found at http://code.midrange.com/index.php?id=4a490d490e Next create the CL program CHGUSRPWD in QGPL (souce at http://code.midrange.com/index.php?id=9f647ec6ba ). Remember when compiling the program it MUST be as QSECOFR and you must specify USRPRF(*WNER) on the CRTCLPGM command. This is necessary to adopt the QSECOFR authority. Finally create a user profile with the following command: CRTUSRPRF USRPRF(PWDRESET) PASSWORD(PWDRESET) INLPGM(QGPL/CHGUSRPWD) INLMNU(*SIGNOFF) LMTCPB(*YES) The important things here are the INLMNU(*SIGNOFF) and LMTCPB(*YES) this will prevent the user from signing on to the machine to do anything other run the CHGUSRPWD program and will sign him/her off as soon as it finishes. The program has a test within it to ensure that important user profiles (e.g. QSECOFR, QSYSOPR, etc) cannot be reset in this way. You may want to add your own power-user profiles to prevent anybody from maliciously resetting and changing passwords. Hope it helps Jonathan
    370 pointsBadges:
    report
  • TomLiotta
    we have also restricted access to certain user profiles like QSECOFR and QSYSOPR. Since *PUBLIC should already be *EXCLUDE for QSECOFR, it doesn't make sense to say that someone was deliberately "restricted" from it. It implies that the user had *ALLOBJ (though a private authority could have been previously granted, but that doesn't quite make sense either). If the user was *ALLOBJ, then there were no real restrictions put in place without removing *ALLOBJ. At best there was a limited obstacle that would be possible if *ALLOBJ was a group authority. When describing a security problem, please provide exact commands that have been run and attributes/permissions that exist. If at all possible, include actual copy-pastes. Tom
    125,585 pointsBadges:
    report
  • Batman47
    I allow my Help Desk to do this but restrict them from reseting profiles that have the special authority of *ALLOBJ, *SECADM, *SPLCTL, or *SERVICE. We use TAATOOL INZPWD2 that uses Retrieve User Information API QSYRUSRI. If fields in positions 29, 30, 32, or 34 return a 'Y' then a message is sent back to user stating that the Security Officer must reset the user. The program not only re-enables, but it also changes the password.
    1,050 pointsBadges:
    report
  • Rayne427
    [...] Limiting user abilities [...]
    0 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