Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Limit CHGUSRPRF Parameters for certain users

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Limit CHGUSRPRF Parameters for certain users

    Why do these people need direct access to CHGUSRPRF? If there are limited functions they routinely perform you can write a tight CL program they can run that gives them only the functions they need and uses them in a consistent way. Have the program adopt the authority it needs and grant selected users access to it through an authorisation list. Dave...

  • #2
    Limit CHGUSRPRF Parameters for certain users

    Dave, because they were hired to be help desk and do our more mundane tasks like enabled those who have been disabled, and we do not want all the parameters for command line, etc. at their fingertips. They have had no formal AS/400 training.

    Comment


    • #3
      Limit CHGUSRPRF Parameters for certain users

      Please help... is there an example of tight CL pgm that would only give them the status parameter?

      Comment


      • #4
        Limit CHGUSRPRF Parameters for certain users

        Ann, Here is a utility I gave to our computer operators to handle the frequent calls for assistance by "disabled" users. You can compile both CLPs to adopt QSECOFR authority. However, my preferred method is to create a security-officer profile that is limited to a mandatory menu where I put in home-grown utilities requiring security access (example: spool archiving/retrieval, power down, system/all-user backups, reclaim storage, etc.) Command Source: CMD PROMPT('Enable a User Profile') PARM KWD(USRPRF) + TYPE(*CHAR) LEN(10) + MIN(1) + PROMPT('User Profile') CLP (Program to Process) Source: PGM PARM(&USRPRF) DCL VAR(&USRPRF) TYPE(*CHAR) LEN(10) DCL VAR(&MSG ) TYPE(*CHAR) LEN(40) CHGUSRPRF USRPRF(&USRPRF) STATUS(*ENABLED) MONMSG MSGID(CPF0000) EXEC(RCVMSG RMV(*NO) MSG(&MSG)) IF COND(&MSG *NE ' ') THEN(SNDPGMMSG + MSGID(CPF9897) MSGF(QCPFMSG) MSGDTA(&MSG) + MSGTYPE(*STATUS)) ENDPGM CLP (Validity Checker) Source: PGM PARM(&USRPRF) DCL VAR(&USRPRF) TYPE(*CHAR) LEN(10) DCL VAR(&STATUS) TYPE(*CHAR) LEN(10) DCL VAR(&MSG ) TYPE(*CHAR) LEN(40) DCL VAR(&ERRMSG) TYPE(*CHAR) LEN(44) RTVUSRPRF USRPRF(&USRPRF) STATUS(&STATUS) MONMSG MSGID(CPF0000) EXEC(RCVMSG RMV(*NO) MSG(&MSG)) IF COND(&MSG *NE ' ') THEN(GOTO CMDLBL(ERROR)) IF COND(&STATUS *NE '*DISABLED') THEN(DO) CHGVAR VAR(&MSG) VALUE(+ 'User "'|| &USRPRF |<'" is not DISABLED') GOTO CMDLBL(ERROR) ENDDO RETURN ERROR: IF COND(&MSG *NE ' ') THEN(DO) CHGVAR VAR(&ERRMSG) VALUE('0000' || MSG) SNDPGMMSG MSGID(CPD0006) MSGF(QCPFMSG) + MSGDTA(&ERRMSG) MSGTYPE(*DIAG) SNDPGMMSG MSGID(CPF0002) MSGF(QCPFMSG) + MSGTYPE(*ESCAPE) ENDDO ENDPGM

        Comment


        • #5
          Limit CHGUSRPRF Parameters for certain users

          That’s the sort of thing. It demonstrates my point that resetting user profiles does not need direct access to the CHGUSRPRF command, even a crippled version. I’m afraid I don’t have a sample source of my own to give you and I don’t have sufficient authority on my current box to write one and test it, but I can describe the strategy I’ve used successfully in the past. The strategy is a 2-pronged fork. The first prong is the software; the second is procedural. The software was a CL program similar to Ric’s, which was attached to the help desk operators’ menu. No command or validity checker was used: the program used a display file to prompt for the ID. The program adopted QSECOFR authority, had public authority *EXCLUDE and had an authorization list attached to ensure that only the help desk operators could run it. Like Ric’s program it retrieved the user profile. Unlike Ric’s it didn’t care if the profile was not disabled, but it did check the group profile against a hard coded list. If the profile was not in a recognised group it would not re-enable it. I made sure my own profile, particularly my God profile, could be re-enabled though. This way if there’s someone you want to shut out of the system temporarily you can then disable their profile and change their group profile to one that is not in the list. This will prevent a well meaning help desker from being conned into re-enabling them. One day you will get a call from a panic-stricken manager saying, “One of my people has just resigned and she’s still working on the system. I’ve no idea what she’s doing and I need to get her off now and keep her off. Can you help?” I’ve only had this happen once but was rather fun doing an ENDJOB OPTION(*IMMED) on an active session when it did. The program should not just reset the profile to enabled but also reset the password to some standard value (same as user ID is a good choice, the word “PASSWORD” is also popular) and set the password to expired. That way the user is forced to select a new password when they sign on again. If they have actually forgotten the password, which happens, Ric’s program will not help them. To provide the other prong, I wrote a set of instructions that the help deskers were required to follow when re-enabling an ID. Basically it required them positively to identify the person making the request. Either they needed to recognise their voice, or they would have to look them up in the company phone book and call them back (not just using the phone number the requester gave them of course). If the requester was not in the book then they would phone their manager, again using the phone book, and get a verbal OK to re-enable that profile. Next time we had an internal audit I got the auditors to review both the policy and the procedure. Auditors love it when you do this kind of thing proactively. So I then had a nice letter, or get out of jail free card, from the auditors saying that the procedure was satisfactory. Dave…

          Comment


          • #6
            Limit CHGUSRPRF Parameters for certain users

            Actually, I think we're now supposed to call them "differently abled" or "profile challenged". :-) Dave...

            Comment


            • #7
              Limit CHGUSRPRF Parameters for certain users

              Ann, You can use Selective Prompting on the command in question. The selective prompt characters tell the system how to handle the parameter, for example: - to select a parameter for display ??KEYWORD() - to omit a parameter from display ?-KEYWORD() - to display and protect a parameter ?*KEYWORD() If you want to display the parameter without letting the user change the value, you could use WRKUSRJOB ?*STATUS(), if you want to display the paramter then use WRKUSRJOB ??STATUS(), or if you want to omit the parameter all together use WRKUSRJOB ?-STATUS(). HTH

              Comment


              • #8
                Limit CHGUSRPRF Parameters for certain users

                Ann, We use something similar to Ric's program, except we force a password change when reenabling the user after positive Id has been made. The CL is owned by and adopts QSECOFR and is secured with an AUTL containing the helpdesk user id's. They do not have access to CHGUSRPRF. We formatted the break message so it could be cut and pasted into the helpdesk software returning the closure message to the user. CMD Source: /************************************************** ******************/ /* PROGRAM ID - CHGUSRPWD */ /* PROGRAM NAME - Change User Password */ /* */ /************************************************** ******************/ CMD PROMPT('Change User Password') PARM KWD(USERID) TYPE(*CHAR) LEN(10) MIN(1) + PROMPT('User Profile') CL Source: /************************************************** ******************/ /* */ /* PROGRAM ID - CHGUSRPWD */ /* PROGRAM NAME - Change User Status */ /* */ /************************************************** ******************/ PGM PARM(&USERID) DCL VAR(&USERID) TYPE(*CHAR) LEN(10) DCL VAR(&PASSWD) TYPE(*CHAR) LEN(10) VALUE('newpasswrd') DCL VAR(&STATUS) TYPE(*CHAR) LEN(10) DCL VAR(&USRCLS) TYPE(*CHAR) LEN(10) DCL VAR(&ERRMSG) TYPE(*CHAR) LEN(100) VALUE(' ') DCL VAR(&JOB ) TYPE(*CHAR) LEN(10) DCL VAR(&MSG ) TYPE(*CHAR) LEN(256) DCL VAR(&USRTXT) TYPE(*CHAR) LEN(50) RTVJOBA JOB(&JOB) RTVUSRPRF USRPRF(&USERID) TEXT(&USRTXT) USRCLS(&USRCLS) MONMSG MSGID(CPF2204) EXEC(CHGVAR VAR(&ERRMSG) + VALUE('User Profile not found')) MONMSG MSGID(CPF2217) EXEC(CHGVAR VAR(&ERRMSG) + VALUE('Not Authorized to User Profile')) /* Display error msg and end program */ IF COND(&ERRMSG *NE ' ') THEN(DO) SNDPGMMSG MSG(&ERRMSG) GOTO CMDLBL(ENDPGM) ENDDO /* Only user class PGMR and USER are allowed to change */ IF COND(&USRCLS = *USER | &USRCLS = *PGMR) + THEN(DO) CHGUSRPRF USRPRF(&USERID) PASSWORD(&PASSWD) + PWDEXP(*YES) STATUS(*ENABLED) CHGVAR VAR(&MSG) VALUE('User profile..: ' *CAT + &USERID *CAT ' ' *CAT &USRTXT *CAT + 'Password..: ' *CAT &PASSWD *CAT ' + <---you will be forced to change it + during signon.') SNDBRKMSG MSG(&MSG) TOMSGQ(&JOB) ENDDO ENDPGM: RETURN ENDPGM

                Comment


                • #9
                  Limit CHGUSRPRF Parameters for certain users

                  Dave, Your routine works in your site, and probably will work for many other sites. However, I would like to express some reservations: 1. It empowers the Help Desk staff to change most people's password to gain unauthorized access on their own. This may tempt a disgruntled and/or unscrupulous staffer to do some unethical things (specially where large sums of money can be easily moved about) at the application level. 2. It is good that there is checking for user class. But it would be better to instead check the special authorities. (Note: OS/400 will flag a warning message, but will not prevent anyone with *USER or *PGMR class from being given *ALLOBJ, *SECADM or any other special authority.) Okay! Maybe I am a bit paranoid! Maybe I have an overly untrusting nature! But isn't that expected of a responsible security administrator?

                  Comment


                  • #10
                    Limit CHGUSRPRF Parameters for certain users

                    I just came back for an update. Since my last post I've added an RPG call to write a record with userid changed, last maint userid, date, time when the change is successful. Makes it a little easier to dump the info if needed instead of the security logs. Rik, I agree that there is that possibility about unauthorized resets, that is always a concern with that functionality. But this is a way to prevent the Helpdesk from creating new id's, adding special authorities, or changing the class on existing ones while still allowing the password reset function to happen. The Helpdesk id's have since been changed to *USER class with no special authorities in order to prevent that and other problems. Paranoid? Overly untrusting nature? How about a scheduled job that dumps all new userid's to one splf and a separate splf where the class does not match the special authorities and other fields we've defined for that class? Universal inital program that logs signin date/time and logout date/time (logout date equal to zero means user turned off the PC in the middle of the session)? How can you be paranoid when corporate auditors, helpdesk, and the user community band together to make our lives miserable??

                    Comment


                    • #11
                      Limit CHGUSRPRF Parameters for certain users

                      We have new personnel and need to put a version of CHGUSRPRF for their access on a menu. We have the menu in place, securing payroll and HR outq's, but need to create a version of CHGUSRPRF with selected parameters available. Can't get the CL to work with the new CMD object.

                      Comment


                      • #12
                        Limit CHGUSRPRF Parameters for certain users

                        Dave, Regarding auditors, "Miserable" is an apt description. I just went through 2 weeks of arguing with 2 sets of auditors (internal and external) over what should or should not be allowed. Can't say I passed with flying colors, but I held my ground and they grudgingly "passed" me. With regards to Help Desk, I can't help liking them. After all, they wouldn't be there if they didn't have pleasing personalities. But as a security administrator, we have to look at this issue impersonally. Take Note: Pleasing Personalities are not the same as Honest Personalities. In my site, help desk is treated as a starting point for new hires. The staff are mostly young (usually new-graduates from technical schools), casual employees with only 2 to 3 weeks orientation and training. They do not stay very long (average 1 to 2 years) before they move on, or are replaced/promoted. Now, if I was an unscrupulous individual out to get a quick buck, I would not be keen on acquiring special authorities, creating user-ids, and going through complicated steps to acquire the necessary access rights to several critical application functions. Why should I go to so much trouble and risk to be able to do so many things that I am not even trained for? Why bother since I can very easily hijack an existing manager's user-id (note: User Class is *USER) who already has all the necessary application authorizations? And if this site does not happen to have security auditing activated, who would know? The manager? If asked why his/her password doesn't work anymore, I would just say "He probably just changed and forgot his password again" or "Must be some kind of system error". And with over 4 other Help Desk staffers with the same authorities, nobody can pin anything on me. Most likely I will get away with this. I wouldn't even bother to quit (and "draw attention to myself?"). I rest my case.

                        Comment

                        Working...
                        X