Special Authority Worst-Case Scenarios and How to Avoid Them | HelpSystems

Special Authority Worst-Case Scenarios and How to Avoid Them

March 8, 2017


“All Hail King Robin of Chertsey!”

Summer finally feels like it’s arrived, and with it news of another wave of denial-of-service attacks and the unveiling of a new cyber security framework by NIST (and it’s subsequent progression through the U.S. Senate). Sure, the birth of Prince George is being celebrated around the world, but I’m not going to dwell on that as it furthers my claim to the British throne! It’s a shame as I think King Robin has a really nice ring to it.

Despite being in the midst of vacation season, the throng of organizations lining up to engage us for a no-charge Security Scan is not showing any signs of slowing: I have personally conducted 9 this month alone and more than 50 since January. One of the many risk factors that continue to be identified is the presence of overly-privileged users. Privileges are often granted without justification and simply need to be reviewed and then removed. There is, however, another common scenario that requires careful mitigation planning.

What’s the Worst that Could Happen

Under the IBM i operating system, users are often granted additional authority to perform specific server tasks. Unfortunately, that often results in the ability for a user to do things beyond the anticipated. For example, changing print priorities requires Job Control (*JOBCTL) special authority which also permits subsystems to be ended.

Resetting a disabled user account requires Security Administrator (*SECADM) privileges and object authority of *USE + *OBJMGT to the profile itself. This is the type of task often delegated to a help desk, but these privileges permit the help desk employee to access dozens of additional user profile settings, as well as submit jobs as the newly-reset profile! The object authority requirement is often accomplished by granting All Object (*ALLOBJ) authority to help desk profiles which increases their capabilities even further and introduces significant risk.

Risk Mitigation the Easy Way

Authority adoption is one of several techniques that I teach to reduce the risk posed by these types of situations. Adoption is a proven programming technique that permits a user (e.g. help desk) to perform privileged tasks while operating from a non-privileged account. The task is coded inside a (typically CL) program instead of being invoked directly from a command line.

By default, a program runs with the authority of the invoking user but we desire that the invoking user NOT carry the necessary privileges. With adoption, a program runtime attribute instructs the OS to additionally leverage the authority of the profile that owns the program. Having the program owned by a profile that has sufficient authority for the desired task ensures that the user is now able to perform it but no other.

Be aware that adopted authority is typically handed down from one program to the next in the stack, although controls do exist to suspend adoption during the execution of a sub-program.

A program can also limit the command parameters that are presented to the user. The following example prompts for a profile name, sets the status value (without allowing it to be overridden), and hides the remaining profile parameters from view. This powerful “selective prompting” capability is useful when a user should only see or access specific parameters. Instructions are found under CL Programming Reference in the online IBM Information Center.


There are several important considerations when using authority adoption. Most importantly, the program should not do anything other than the specified task. Executing a command—such as WRKSPLF—that exposes a command line may allow the invoking user to issue additional commands—with the added privileges and authority of the adopting profiles! In addition, adoption is not honored when accessing the Integrated File System (IFS) and an object’s public authority is never considered. Overall, this is an extremely powerful capability that’s often overlooked when contemplating how to grant user access to server tasks and to production data libraries.

Adoption eliminates the necessity to assign privileges when performing a specific task. Fewer privileges assigned; less chance a user will abuse them.

For more reading on this topic:

  • Download the white paper, Managing Privileged Users on IBM i, published by HelpSystems
  • Search for “iseries authority adoption” online. You will find numerous articles authored by fellow securitarians such as Dan Riehl and Ted Holt.
Get Started

Do you know how many overly-privileged users have access to your systems? Find out now. Request your free security scan today.

Related Solutions

Stay up to date on what matters.