Tweet
I've written a password validation program but I'm having problems with users signing on from Client Access. When their passwords expire they can't get a new one via my program because the password change is handled by the QZSOSIGN job which runs under QUSER. QUSER does not have *SECADM authority (so the QZOSIGN jobs fails with not authorised to usrprf). I don't really want to grant it QUSER *SECADM. Has anybody got any ideas how I can my program to run without compromising security? Ken
-
-
QUSER and Password Validation Program
Ken, It is not clear if the program is a Password Validation Program (a program that verifies that new passwords meet specific password composition rules) or if the program is a Password Generation Program (a program that generates new passwords). I will assume that the program actually is a Password Generation Program and that after generating the password it actually changes the user profile to use that password. I agree with you that giving QUSER *SECADM special authority is a bad idea. One way for the program to always have *SECADM is for the program to be owned by a user profile that has *SECADM and have the program adopt its owners authority. This can be done by specifying USRPRF(*OWNER) when creating the program. Ed Fishel -
QUSER and Password Validation Program
Ed, Sorry, I should have been clearer - it is a password validation program 'plugged in' to QPWDVLDPGM system value.Comment
-
QUSER and Password Validation Program
Ken, You should think about what the password validation program is doing that requires *SECADM special authority. If you are sure that this program needs that authority then having the program adopt its owners authority may still be the best way to be sure you always have that authority. Ed FishelComment
-
QUSER and Password Validation Program
Hi Ed, My password program is not actually changing any user profiles, it just receives the old and new passwords and makes sure they follow certain rules that I have determined. Control is then passed back to the system using. In the case of people using Client Access control is passed back to the QZSOSIGN job which is an autostart job in QSYSWRK subsystem under QUSER. This is where its failing. If I am already signed on to the AS400 via CA or direct and do a CHGPWD then my password validation program works fine and my profile is changed. The problem only occurs if the password needs to be changed when first logging on via Client Access. The password program adopts QSECOFR but it makes no difference. KenComment
-
QUSER and Password Validation Program
Ken, I think that I finally understand the problem. It has nothing to do with the password validation program. It is probably the case that this program has no reason to adopt its owners authority. (If it were my program I would change it to not adopt.) I am not a Client Access expert, but it seems strange to me that Client Access will let the users attempt to change their passwords but then fail to do the actual change. We must still be missing something. Do the users have authority to their own user profiles? If they sign-on from a 5250 type device can they change their passwords there? You may receive more help by asking your questions in the Client Access category instead of the Security category. Ed FishelComment
-
QUSER and Password Validation Program
Ken, One more question for you. What is the public authority of the password verification program? I am wondering if Client Access cannot change the passwords because the QUSER user profile does not have authority to call the password verification program. If this is the problem you can solve it by changing the public authority of the program to *USE. Ed FishelComment
-
QUSER and Password Validation Program
Hi Ed, Thanks for your thoughts on this. The QZSOSIGN job is failing because QUSER does not have authority to the user profile that is requesting the change of password. If I turn off the password validation program then users can request a password change at CA login successfully. If I turn it back on then its the QZSOSIGN job that fails. All very puzzling - I will take your suggestion of reposting on the CA category. Cheers KenComment
Comment