RE: Allowing power users to re-enable users

Trust?

Don't let the program change any user profile with certain special 
authorities like *ALLOBJ, *SECADM.  Just happens to be the second 
parameter on RTVUSRPRF, therefore I believe it indicates it is a popular 
request.

On the program, and the command that runs it, make sure you *EXCLUDE 
*PUBLIC and add just the 'trusted' individuals.

Rob Berendt
-- 
"They that can give up essential liberty to obtain a little temporary 
safety deserve neither liberty nor safety." 
Benjamin Franklin 





"Wills, Mike N. (TC)" <MNWills@xxxxxxxxxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx
06/26/2003 11:28 AM
Please respond to Midrange Systems Technical Discussion
 
        To:     "'Midrange Systems Technical Discussion'" 
<midrange-l@xxxxxxxxxxxx>
        cc: 
        Fax to: 
        Subject:        RE: Allowing power users to re-enable users


Thanks, this worked. I knew how to make the CL, it was the authority that 
we
had the problems with. This will completely take care of it now. Now, we
just have to trust the people that have authority to do this.

-----Original Message-----
From: Raul A Jager 

You can write a CL program that receives one parameter, the user 
profile, and calls  CHGUSRPRF to change that user's password.  You need 
to set the adopted autority to *owner, and make the owner QSECOFR or 
some other profile with enough authority.  Then you can set the 
permisions to the program as public *exclude, and list the people the 
are allowede to use it.

It may be a good idea to also generate a log.

Raul
_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.