Allowing users to change other user?s passwords
Deb wrote in with this question recently:
"Is there a way to allow a user to change passwords for other users without giving them access to the entire user profile? We have a small shop, and I'd like to share this ability with some of our late night staff. However, I'm reluctant to give them the ability to change user type, special authorities, etc. (inadvertently or otherwise)."
What are you feelings on allowing users to change other user?s passwords?
-- Debra Tart, associate editor, Search400.com
Software/Hardware used:
Software/Hardware used:
ASKED:
December 14, 2005 2:48 PM
UPDATED:
November 22, 2009 4:11 AM
Answer Wiki:
You can use the following CL command in a program, menu or create your own command:
chgusrprf ??usrprf() ??password()
When the command runs, it will only allow them to change those 2 parms. However, if they have access to a command line, they can always type the command in and prompt it. In that case this would not help you.
You could create your own CHGUSRPRF command as above and add it to a lib above QSYS. Then revoke authority to the IBM command for all except those you want to have access.
To see all answers submitted to the Answer Wiki: View Answer History.
Deb…
We wrote a simple screen based program in CL to prompt the user for a user profile. The program then resets the password to a default value and sets the password to expired so the user has to change it at signon. The program adopts QSECOFR authority, and is only given to supervisors. This is essentially the same as the previous response, but hides all the other profile information, and presents a simple display panel to the user.
Create a CL program like this…
PGM
?CHGUSRPRF ??USRPRF() ??PASSWORD() ?-all other parms()
ENDPGM
The ?- stops the ability to see (or modify) the other parameters on the command. The program should be owned by someone with *SECADM rights. Be sure the USRPRF(*OWNER) parameter is used on the CRTCLPGM to CHGPGM commands so the person using the program will adopt the rights of the owner of the program.
The downside to this solution is if someone wants to break into a command line with adopted rights, they just need to create a duplicate CHGUSRPRF command that calls program QCMD and place their new command above the “real” CHGUSRPRF command in their library list. Of course if you have issues like that going on you have bigger problems…
slewisbcc is on the right track. To prevent someone from causing problems by creating their own CHGUSRPRF command is a matter of ordering your library list correctly. If QSYS comes before any user libraries, they can create their own CHGUSRPRF command, but the system will always find and execute the QSYS version.
PCATLIN has the best way to do it or create your own command instead of the display file. Have the program check the user ids of those you want to be able to run this and exit if not one of those or better still if they have a certain group profile or supp. group profile. Then no one needs the special authority other than the security admin(s).
The program only needs:
There is no need for the “?” prompt character for the command nor the “?-” prompt characters for unnecessary parameters. The program does need to have the USRPRF(*OWNER) attribute and to be owned by a profile that is authorized to the profiles that need passwords changed. And as for possibility of a duplicated CHGUSRPRF in a library above QSYS in the library list:
Qualify the command to QSYS and any number of duplicates can exist without affecting the program. If changes are allowed to commands in QSYS, then all bets are off anyway.
Tom