Adopting authority enables users to drive the car to the store and back yet stay off the highway. To ensure no one ends up in the ditch, you must know where the keys are at all times.

Adoption of authority is a solution to the problem of having users who need to execute commands that are otherwise forbidden based on their current IBM i authority level.

For example, your helpdesk personnel must have the ability to re-enable user profiles that have been disabled, but you don't want to give them *SECADM special authority and access to the Change User Profile (CHGUSRPRF) command. Instead, you can create a simple custom program that accepts one parameter (i.e., the user profile name); then, once the program is called, it then changes the profile status from *DISABLED to *ENABLED. For this to happen, the program has to adopt the authority of the owner of the program object, and that owner must have the authority to run the commands called within the program.

Since these programs give users expanded abilities, you need to be able to keep an eye on them. Fortunately, IBM provides the command Print Adopting Objects (PRTADPOBJ). This command gives you the ability to print a list of programs that adopt authority.

You can choose a specific profile whose authority is adopted or specify *ALL to cover all the bases. The command has another parameter called CHGRPTONLY, which gives you the option to list either only new programs that have been changed/created since the last time the command was run or all programs that adopt authority.

I'd suggest you run the command yearly with CHGRPTONLY set to *NO so you can fully review all objects that adopt authority. During the year, you should run the command with CHGRPTONLY set to *YES so you can see what new programs are adopting authority and ask the appropriate questions of your developers if need be. The frequency really depends on the amount of custom development in your shop and whether you have frequent vendor program patches applied. A heavy development shop may require a weekly checkup while a fairly static system may need far less scrutiny.

Don't Run This Command at 9:00 on a Monday Morning

Running this command during production hours may cause performance problems due to the command obtaining locks on user profiles to analyze private authorities. (See IBM Technote 561184146 for details.) For that reason, it's probably best to run this command after hours.

as/400, os/400, iseries, system i, i5/os, ibm i, power systems, 6.1, 7.1, V7,

Steve Pitcher works with iTech Solutions, an IBM Premier Business Partner. He is a specialist in IBM i and IBM Power Systems solutions since 2001. Feel free to contact him directly This email address is being protected from spambots. You need JavaScript enabled to view it..