AS/400 security
AS/400 user authority
Besides QSECOFR, which othere accounts justify having *ALLOBJ and/or *SECADM

Answer Wiki

Thanks. We'll let you know when a new response is added.

I am sure that would totally depend on your enviroment and how you wanted to structure your security. We also give that authority to QSYSOPR and each of our MIS staff. That said, we are a small shop with only three MIS people.

At minimium, I would make sure you have two accounts with full authority, because if a profile was to get corrupt or disabled, you wouldn’t want to not have a seperate way to get into it.

I would do the same thing with SST profiles. We only had one once upon a time, and it’s password was either lost or the account locked (can’t remember which) and that was a nightmare of a problem.

Discuss This Question: 3  Replies

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • Beatrix Kiddo
    60 pointsBadges:
  • TomLiotta
    Besides QSECOFR, every profile that needs authority to access any or all objects on the system will need access to *ALLOBJ. Access to that special authority may be through the profile itself or through a group profile. (It doesn't really matter which one.) Access can often also be supplied through the use of the USRPRF(*OWNER) attribute of a program object. Most of the profiles listed above are IBM profiles. You'll need to ask IBM if the listed special authorities are needed for those -- it's almost guaranteed that the answer will be "Yes." For 3rd-party vendors, you'll need to ask the vendor. If the profile is used for a security or system administration related function, then the vendor's answer will probably also be "Yes." I work for a vendor of security related products. One product line is for network exit-point programming and the subsequent reporting. One feature is the capability of the exit program to switch to a different profile in order to process a transaction that enters through a network interface, e.g., within an FTP session. The system administrator chooses which user profiles need to switch, which transactions will cause a switch and which profiles will be switched into. Profile switching allows the use of authorities that do not need to be given to all of the various users -- the authority might only be used during extremely granular circumstances. In order for the exit program to do this, it must be owned by a profile that has the authority to switch to any profile chosen by the administrator. Further, the program itself must have sufficient authority to switch back to the original user profile after the transaction completes; the profile that was switched-to might not have sufficient authority to do this. In addition, logging of network activities is done through the system audit journal (to help guarantee integrity of audit trails.) Adding entries to QAUDJRN and retrieving entries for reporting also require high levels of authority. These are features that the customer has chosen a 3rd-party product to do. A product cannot do what it was bought for if sufficient authority is taken away. There aren't many ways to get this done without the use of a special authority such as *ALLOBJ in the owning profile. There's no way to predict what profiles will be used in the future, so the product cannot be built with enough individual authorities nor can individual authorities be specified at the time of installation. There are far too many combinations, most of them are not known in advance. There are many other possible reasons that a given special authority might be used. The vendor should have no problem giving you a list of uses that the authorities are used for. This should be true for each special authority that is in use. Finally, note that 3rd-party vendors should not be using QSECOFR as an owning profile nor as a group profile. QSECOFR should _only_ be used at IBM's direction. This tends to mean that some additional profiles need to be created that are intended for particular products. Multiple products (from different vendors) should _not_ be sharing profiles. In summary, there are many reasons for using profiles with special authorities. Profiles should only have the authorities that are needed. 3rd-party vendors should be able to answer why any authority is needed. Tom
    125,585 pointsBadges:
  • CarterC19
    One rather surprising reason to use a profile might be performance considerations for large jobs that do many, many file opens. I had a group of large nightly batch jobs that would, according to the IBM performance reports, routinely generate up to 35,000 thousand authority lookup exceptions *per second*. I read up on the 'Authority Order of Operations' and reasoned that in my case for each open, the system had to go through eight levels of authority checking before finding a condition that granted access via the group profile model we used here. The system does check for a user's special authority in their profile several steps earlier than checking for the group's authority to an object in particular, so I changed these jobs to run under a profile with *ALLOBJ special authority, figuring on access being granted several steps sooner than under the earlier scenario. Sure enough, it decreased these lookup exceptions to just a couple thousand per second, and the jobs themselves ran a considerable amount quicker. As a side note, it did make for a fun experiment, too. Carter
    220 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: