IBM i Security: Reducing Risk by Controlling PUBLIC Authority on Adopted Authority Programs

In one of my latest IBM i security hardening projects, I implemented an automated approach to identify and remediate risky program authorities. The goal was simple:

Reduce attack surface and privilege escalation risks by controlling PUBLIC authority on adopted authority programs.

Because let’s be honest… if PUBLIC has ALL authority on a program that adopts ALLOBJ, that’s basically like leaving the keys to the kingdom under the doormat.

This article explains the methodology, tools, and automation strategy used to significantly reduce risk in an IBM i environment.

Why PUBLIC Authority on Adopted Authority Programs Is a Security Risk

Programs that use Adopted Authority execute using the privileges of the program owner instead of the calling user.

If the owner profile has special authorities like:

• *ALLOBJ

• *SECADM

• *SERVICE

• *SPLCTL

then the program can perform high-privilege operations even when invoked by a normal user.

Now combine that with *PUBLIC authority = ALL or CHANGE and you get a classic privilege escalation scenario.

Common risks include:

• Unauthorized access to sensitive objects

• Privilege escalation through adopted authority

• Data manipulation or deletion

• Bypassing security controls

From a cybersecurity and compliance perspective, this is exactly the kind of exposure auditors love to find — and security teams prefer to eliminate first.

Project Objective

The main goal of the project was to:

1. Identify programs that adopt authority from highly privileged owners

2. *Detect risky PUBLIC authorities (ALL or CHANGE)

3. Create a centralized inventory

4. Automatically remediate risky permissions

5. Continuously enforce the security policy

In other words:
Detect → Monitor → Correct → Automate

Step 1 – Building the Program Inventory

The first step was creating a CLP program to generate a Physical File (PF) containing the relevant information for all programs.

The table includes fields such as:

• Owner profile

• Creation date

• Change date

• PUBLIC authority

• Last used date

• Library name

• Program name

This inventory allows security teams to analyze risk and prioritize remediation.

Example: Physical File Definition

Best approach to create the database with list of those programs is using SQL

SELECT

OBJLIB,

OBJNAME,

OBJOWNER,

OBJATTRIBUTE,

CREATE_TIMESTAMP

FROM QSYS2.OBJECT_STATISTICS

WHERE OBJTYPE = '*PGM'

AND OBJOWNER IN

(

SELECT AUTHORIZATION_NAME

FROM QSYS2.USER_INFO

WHERE SPECIAL_AUTHORITIES LIKE '%ALLOBJ%'

OR SPECIAL_AUTHORITIES LIKE '%SECADM%'

)

This dataset becomes the foundation for automated IBM i security monitoring.

Step 2 – CLP Program to Populate the Table

The next step was building a CL program that scans the system programs and populates the table.

Key commands used:

• DSPOBJD

• DSPPGM

• OUTFILE

• RUNQRY / CPYF

Example simplified CLP logic:

PGM
/* List all programs /
DSPOBJD OBJ(ALL/*ALL) OBJTYPE(*PGM) +
OUTPUT(*OUTFILE) +
OUTFILE(QTEMP/PGMLIST)

/* Copy relevant information to our security table /
CPYF FROMFILE(QTEMP/PGMLIST) +
TOFILE(SECURITY/PGM_PUBLIC_RISK) +
MBROPT(REPLACE) +
FMTOPT(*MAP)

/* Additional processing can enrich the data /
DSPPGM PGM(ALL/*ALL) +
OUTPUT(*OUTFILE) +
OUTFILE(QTEMP/PGMDETAIL)

ENDPGM

This program collects core metadata from IBM i system catalogs, allowing us to identify programs with risky PUBLIC authorities.

Step 3 – Identifying High-Risk Authorities

For this project, I prioritized programs with:

• PUBLIC authority *ALL

• PUBLIC authority *CHANGE

These authorities allow users to modify or fully control program objects, which becomes especially dangerous when adopted authority is involved.

However, the same methodology can easily be extended to detect:

• *USE

• *EXECUTE

• or any authority threshold defined by your security policy.

Step 4 – Automating Remediation with Ansible

Once the inventory table was built, the next step was automating enforcement.

A daily Ansible playbook runs to correct PUBLIC authority for risky programs.

Target policy:

Minimum allowed PUBLIC authority = *USE

Example Ansible task:

- name: Fix PUBLIC authority for risky programs
ibmi_cl_command:
cmd: "CHGPGM PGM({{ library }}/{{ program }}) AUT(*USE)"

The playbook:

1. Reads the risk inventory table

2. Identifies programs with PUBLIC ALL or CHANGE

3. Executes CHGPGM or GRTOBJAUT

4. Adjusts PUBLIC authority to *USE

This ensures that security policies are enforced automatically, without manual intervention.

Because in cybersecurity, automation is not a luxury — it’s survival.

Benefits of This IBM i Security Solution

Implementing this approach delivers several important benefits.

🔒 Reduced Privilege Escalation Risk

Programs adopting powerful authorities become far less exploitable.

📊 Complete Visibility

The inventory table provides a centralized security view of all programs.

⚙ Automated Enforcement

The Ansible playbook continuously maintains the desired authority model.

🧾 Audit and Compliance Support

Security teams can demonstrate active risk management and monitoring.

🚀 Improved IBM i Security Posture

This simple control significantly reduces the attack surface of the platform.

Why This Matters for IBM i Security

Despite its reputation for strong security, IBM i environments are not immune to misconfiguration risks.

Many organizations accumulate legacy authorities over years or decades.

It’s common to find programs that:

• Adopt powerful authorities

• Are owned by ALLOBJ profiles

• Still allow PUBLIC *CHANGE or ALL

That combination is essentially a cybersecurity time bomb waiting for the wrong user to press the button.

By implementing authority governance and automated remediation, we bring modern security practices into the IBM i ecosystem.

Final Thoughts

This project shows that improving IBM i cybersecurity doesn't always require complex tools.

Sometimes the most effective improvements come from:

• good visibility

• clear authority policies

• automation

By combining CL programming, IBM i object analysis, and Ansible automation, we can drastically reduce risk with relatively simple techniques.

And most importantly…

Security should never depend on someone remembering to run a command manually at 3 AM.

Automation does not forget. Humans do. 😉

If you work with IBM i security, authority management, or privilege escalation protection, this type of control can deliver immediate security improvements with minimal operational impact.

And if you enjoyed this post, stay tuned — there are always more IBM i cybersecurity adventures coming.

Contact me

If you have any requests, queries, or are interested in collaborating with me, please don't hesitate to reach out using the form provided below or any of my social media!