Allowing user without SECADM authority to enable a disabled user

[Guest.Visitor]

We would like help desk personnel to be able to reset disabled USER PROFILES but don't want them to have *secadm special authority. Any suggestions?

[Guest.Visitor]

We made a command and clp that adopts the QSECOFR profile when it runs to allow anyone on the authorization list for the command and clp to use it. The clp looks like: PGM PGM PARM(&USER) DCL VAR(&USER) TYPE(*CHAR) LEN(10) LOOP: IF COND(&USER *EQ 'QSECOFR') THEN(GOTO + CMDLBL(END)) CHGUSRPRF ?*USRPRF(&USER) ??PASSWORD(PASSWORD) + ??PWDEXP(*YES) ??STATUS(*ENABLED) MONMSG MSGID(CPF6801) EXEC(GOTO CMDLBL(END)) /* F3 or F12 */ MONMSG MSGID(CPF2204) EXEC(GOTO CMDLBL(LOOP)) /* Invalid profile name */ END: ENDPGM ...and the command looks like: CMD PROMPT('CHANGE USER PROFILE') PARM KWD(USER) TYPE(*CHAR) LEN(10) MIN(1) + PROMPT('UserName:') Compile both objects as QSECOFR or any profile that has *SECADM authority. Then secure each object with the QUSEADPAUT authorization list. We use a group profile for all the pgmrs, so the authorization list QUSEADPAUT would have public *EXCLUDE and grppgmr *USE. The last step is to change system value QUSEADPAUT to include authorization list QUSEADPAUT. It's a little confusing that the authorization list and the system value have the same name. hth mike_kissinger

[Guest.Visitor]

Mike, You were right on target until you got to this part.... >>Compile both objects as QSECOFR or any profile that has *SECADM authority. >>Then secure each object with the QUSEADPAUT authorization list. We use a >>group profile for all the pgmrs, so the authorization list QUSEADPAUT would >>have public *EXCLUDE and grppgmr *USE. The last step is to change system >>value QUSEADPAUT to include authorization list QUSEADPAUT. It's a little >>confusing that the authorization list and the system value have the same >>name. First, only the program needs be compiled by a "QSECOFR like" profile. The command can be compiled (and therefore owned) by anyone. Next, the profile will likely need *ALLOBJ authority as well, because it will need to have (or acquire) *CHANGE authority to each user profile that it proposes to operate on. In order to change a User Profile object you must have both *SECADM special authority, and *CHANGE authority to the User profile Object. Third, in order for this program to adopt authority, it should be owned by a powerful profile (as you stated) and it should also run under the authority of it's owner. This is done by setting the USRPRF parameter on either the CRTCLPGM or CHGPGM command to *OWNER. Finally, the authorization list named in the QUSEADPAUT command has very little to do with what you are trying to accomplish here. If an authorization list is named in the QUSEADPAUT authority list, the authorization list controls which profiles are allowed to _create_ programs that adopt authority... if you're are not on the list, you can not use the USRPRF(*OWNER) parameter on the CRTxxxPGM or the CHGPGM command. It doesn't/shouldn't control access to your newly created program. In fact, if you added the help desk personell to the authorization list as you suggested, they would be permitted to create or change programs that adopt authority.... not a normal help desk task. I would reccommend setting up a separate authorization list (let's call it HELPDESK) and secure this new command and program with that authorization list. I'd give memebers of the helpdesk *USE to the authorization list so that they could *USE the program and command, and make sure that *PUBLIC had *EXCLUDE authority. Another helpfull hint: Change the CL program slightly so that it will refuse to change the passowrd for any user with *ALLOBJ or *SECADM special authority. This will prevent helpdesk personell from secretly becoming a security officer (O.K., so i'm paranoid... . jte MC Security Editor And one more thing... It's a nit, but the authorization list named in the QUSEADPAUT parameter does not have to be named QUSEADPAUT... you can call it whatever you like (within the boundaries of valid OS/400 object names).