Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Profile Ownership

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

  • Profile Ownership

    Kim, Be aware that anyone who has *use or higher authority to a user profile can submit jobs as that other user. For instance, if I do not have *allobj authority and yet I have *use or greater authority to someone's user profile that does have *allobj authority I can simply submit batch jobs to accomplish tasks that I need *allobj authority to perform. So if your application security officer is signing on with QPGMR and they cannot see user profiles on the system, if you give authority to QPGMR to see the profiles either with *use or by giving them object ownership then QPGMR will be able to submit jobs in batch to accomplish tasks that you probably do not want them to do. My practice has been to let QSECOFR or another ultimate authority user own all user profiles. This way the profile that owns them would never benefit by submitting jobs to accomplish tasks under other profiles. CAUTION ---- Be careful not to go out on your system and immediately being excluding the public from all user profiles. There are some key "Q" IBM profiles that the public must have *use authority to. Look into user created profiles that have public *use and find out why those are set that way. Maybe they should not be public *use. It may be possible that someone intentially set up some profiles to allow users to submit jobs under. Just make certain that you confirm everything before restricting authority. Scott

  • #2
    Profile Ownership

    Thanks for you response. It has been our policy for profiles to be owned by QSECOFR. User profiles have Public *exclude. Everyone belongs to a group which is where authorities are granted. Your response solidified continuance of our practices. Thanks so much...Kim

    Comment


    • #3
      Profile Ownership

      I was looking for other stuffs and I found this. In particular I don't like QSECOFR owns the profiles because everytime a change is required (even change a password) the administrators receive the message "not authorized", then an *ALLOBJ user is required, which is not the best practice. In our case I created a USRGRP named ADMINISTR with SECADM authorization. He owns the profiles and every security administrator is in it. Good luck.

      Comment


      • #4
        Profile Ownership

        I have a situation on one of my systems...the application security officer requested all profiles be owned by QPGMR so they can view all profiles. By doing this QPGMR has *ALL authority to the profiles. I have CHGUSRPRF public/*change, DLTUSRPRF public/*exclude, WRKUSRPRF public/*exclude & QPGMR *use. What is the 'Best Practice' for ownership of profiles (individual and group)? Should QSECOFR own profiles with QPGMR *use? Thanks in advance for any clarification or recommentations you could provide.

        Comment

        Working...
        X