Allowing users to change other user?s passwords

DebraTart

pts.

Tags:

AS/400

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

Asked: December 14, 2005 2:48 PM Last updated: November 22, 2009 4:11 AM

Answer Wiki

Last updated: December 14, 2005 5:08 PM GMT

Jaicee0 pts.
History
Contributors
- Ordered by most recent
- Jaicee0 pts.

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

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.

Discuss This Question: 5 Replies

Pcatlin Dec 15, 2005 8:21 AM GMT

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.

200 pointsBadges:

report
Slewisbcc Dec 15, 2005 8:23 AM GMT

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...

0 pointsBadges:

report
TheQuigs Dec 15, 2005 11:51 AM GMT

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.

0 pointsBadges:

report
Maverick64 Dec 15, 2005 12:14 AM GMT

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).

0 pointsBadges:

report
TomLiotta Nov 22, 2009 4:11 AM GMT
The program only needs:
```
PGM
CHGUSRPRF ??USRPRF() ??PASSWORD()
ENDPGM
```
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:
```
PGM
QSYS/CHGUSRPRF ??USRPRF() ??PASSWORD()
ENDPGM
```
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
125,585 pointsBadges:
report