Program to chagne Passwords

[Guest.Visitor]

John, I did such a project quite a few months ago. Unfortunately, I do not have access to the AS/400 I set this up on anymore as my roles have changed. But this is what I did: - Created a CL program that did what you needed it to do. - Compile the CL with *OWNER authority. - Run the CHGPGM command on the compiled object and change the (I think this is it) Use Adopted Authority to *YES. Then change the owner of the compiled CL object to whatever group profile you have defined that gives you enough authority to perfrom the password change. Usually QSECADM is enough, or if you have copied that to a new one for your company, use that one rather than the IBM supplied profile. That should be it. When the CL is run, it runs under the OWNER of the object, and when it is done, the user's authority goes back to what it was before the CL was run.

[Guest.Visitor]

Doug, We do something similar. A CL program is called that changes the user's password to be the same as the user ID and sets it to expired. That way they must change it next time they log on. However, if you want to be safe you should "qualify" all commands in any program that adopts QSECOFR profile. This prevents a rogue programmer from setting up a library list that has his/her library ahead of qsys and uses commands with the same name as system commands. If they don't qualify all commands then you've just opened a back door. To qualify every command place "qsys/" in front of each command. For example: qsys/RTVJOBA USER(&USER) qsys/CHGUSRPRF USRPRF(&USER) PASSWORD(&USER) PWDEXP(*YES) I've known people so paranoid that they qualify ALL statements. For example: qsys/PGM parm(&USER) qsys/DCL VAR(&USER) TYPE(*CHAR) LEN(10) But I don't think you can spoof PGM or DCL lines. In any event, the above 4 lines should work for doing what you want. It will change the user's password to match their user id and expire it. chuck Opinions expressed are not necessarily those of my employer. "Doug Englander" <cycleman@mcpressonline.com> wrote in message news:6ae6510d.0@WebX.WawyahGHajS... | John, | | I did such a project quite a few months ago. Unfortunately, I do not have access to the AS/400 I set this up on anymore as my roles have changed. But this is what I did: | | - Created a CL program that did what you needed it to do. | - Compile the CL with *OWNER authority. | - Run the CHGPGM command on the compiled object and change the (I think this is it) Use Adopted Authority to *YES. | Then change the owner of the compiled CL object to whatever group profile you have defined that gives you enough authority to perfrom the password change. Usually QSECADM is enough, or if you have copied that to a new one for your company, use that one rather than the IBM supplied profile. | | That should be it. When the CL is run, it runs under the OWNER of the object, and when it is done, the user's authority goes back to what it was before the CL was run.

[Guest.Visitor]

Chuck, Thanks for the feedback. That was helpful. I will keep this tip in my security file. Qualifying will definitely make the process more secure. John, Does any of this help you? Thanks! Doug.

[Guest.Visitor]

I have written a similar application available from our "Client Services" menu for our HelpDesk/Client Services, and beyond qualifying the command and utilization of Authority Adopting, found it wise to secure the CL program with an authorization list - either user specific or place the users ALL in a Group Profile and authorize the Group Profile.

[thull@fmic.com]

I have modified the old TAATOOLS program. I had a remote site with no staff and the shift supervisor was my on site Help desk. I gave him the original program (similar to your previous examples). He very quickly figured out that I re-set the password to the user profile. So he ran it against QPGMR, QSECOFR, etc... So I have the Q* exclusions. You may also have a software package that comes with an administrator profile with QSECOFR built in (block that too). I also added a SNDJRNE to give me a log to check... <hr width=50 align=left>Code ('http://www.mcpressonline.com/mc/showcode@@.6ae6510d/4')

[Guest.Visitor]

Our management would like out Help Desk to be able to change passwords on the Iseries machines. However they don't want them to have *secadm authority. So I thought we could write a cl program that would use *owner adopted authority. Does anyone have an example of how to do this. I don't have much for CL programming experience. JB

[Guest.Visitor]

Any programs that you change so that they are owned by a *SECADM profile, plus any programs that this program calls, should probably be moved to a library in the system portion of the library list. Then you don't have to worry about qualifying any called programs. The CHGSYSLIBL command is usually secured against *PUBLIC usage.