User Authorities

[Paul]

Users often forget their passwords or disable their user profiles from too many sign-on attempts so we have developed a small ProfoundUI program that we can use to reset their user profiles. It uses QCMDEXC to call chgusrprf to change 3 things: status(*enabled), pwdexp(*yes) and resets the password which it then emails to the user. This is great for the IT Support team, but the problem is that this is successful even if the ProfoundUI user doesn't have *SECADM authority. It basically works for everyone. A user that does not have *SECADM and therefore no authority to change user profiles in a 5250 session can reset user profiles using the ProfoundUI web program.

I have checked QTMHHTTP and QTMHHTP1 and they don't have *SECADM, (or any additional/group profiles), and the ProfoundUI user doesn't have *SECADM (or any additional/group profiles), but the chgusrprf command is still successful.

Am I missing something?

Thanks,

Paul

[dieter]

Hello Paul,

i think, you can write a RPG-program (or a CL-program) which does the work, e.g. which calls QCMDEXC. And you can give the nessesary rights to this tool instead of giving the rights to the session or the user. To do this, you should sign on as QSECOFR and than compile the tool and execute: "CHGPGM USRPRF(*OWNER)". This means that the programm gets the authorities of the Programmer who compiled and changed the program. I am not sure if had explained this correctly. But we use this method and it works.

Greetings from Germany,

Dieter

[Paul]

Hi Dieter,

Thanks for the tip, I'll give it a go. BTW, the RPG program does use QCMDEXC, I've corrected my typo in original post (from QCMD).

Thanks,

Paul

[David]

I can clarify what user profile's permissions are in effect, if this helps.

1. When running in Genie, the application runs in a standard 5250 interactive job and the signed in user profile's permissions are in effect. This is exactly the same as a green screen 5250 session.

2. When not running in Genie, there are two types of sessions:

a. For anonymous sessions (the user doesn't sign in) the user profile QTMHHTP1 permissions are used.

b. For authenticated sessions (user signs in), the signed in user profile's permissions are used.

3. User profile QTMHHTTP permissions will never come into play for this sort of thing. These are only used for static IFS file requests from the http server.

Also, if this helps, Profound UI has a built-in mechanism for handling expired passwords:

http://www.profoundlogic.com/docs/displ ... d+Handling

[Paul]

Thanks to Dieter and David for your suggestions and explanations.

Dieter's tip worked, except that I was wanting to restrict authority, rather than grant it. So the command that worked was:

CHGPGM PGM(MyLIB/MyPgm) USRPRF(*USER) USEADPAUT(*NO) FRCCRT(*YES)

Now regular users cannot change user profiles, and the IT Support teams can only change user profiles to which they are authorized, like we have with the standard chgusrprf from green screen.


(David: I use the Profound UI built-in mechanism for handling expired passwords for our Profound users, but we still have a number of 5250 users and this is for support teams to reset them.)

Cheers,

Paul

[Scott Klement]

Seems to me that this should behave the same in PUI as it does in green-screen. Did you previously have USRPRF(*OWNER)?

That would explain it if you had USRPRF(*OWNER) on your PUI program and USRPRF(*USER) on your green-screen program, they would behave differently.