IBM i Authority Collection: From Over-Privileged to Least Privilege

IBM i Authority Collection—what is it and why is it needed?

Imagine walking into your bank’s audit review meeting, only to hear the auditor flash a glaring warning: “Your core application profiles and batch users are running with full *ALLOBJ special authority.”

In the high-stakes world of banking, this is every IT security administrator’s nightmare. Granting *ALLOBJ (All Object special authority) is like giving every bank teller the master key to the main vault, the safety deposit boxes, and the administrative office. While it guarantees that applications never crash due to a “not authorized” error, it leaves your core financial files—like sensitive loan databases (PAYROLL), credit card ledgers (CREDITCARD), and transaction files—vulnerable to insider threats, ransomware exploitation, and stringent regulatory compliance failures.

A practical use case

The user profile authority report below illustrates how users hold distinct privileges on a production IBM i server. Drawing from this real example, I can identify several significant risks and security issues if oversight is inadequate.

Special Authority / Category	Total Profiles	Enabled Profiles	Risk Level
Total System User Profiles	13,811	3,570	Baseline
*ALLOBJ (All Object)	61	48	🔴 Critical
*SECADM (Security Admin)	59	40	🔴 Critical
*JOBCTL (Job Control)	11,941	3,509	🔴 Extreme Sprawl
*SPLCTL (Spool Control)	11,912	3,484	🔴 Extreme Sprawl
*SAVSYS (Backup & Restore)	74	43	🟠 High
*IOSYSCFG (Comm Config)	86	52	🟠 High
*SERVICE (Hardware Admin)	15	13	🟢 Low / Well-managed
*AUDIT (Auditor)	14	12	🟢 Low / Well-managed

If we consider *ALLOBJ and *SECADM Special authorities from above table,

Excessive *ALLOBJ (All Object) Profiles

Finding: 61 total profiles, with 48 active/enabled profiles holding *ALLOBJ special authority. Security Risk: *ALLOBJ gives users full, unrestricted access to view, modify, or delete every file, library, and application on the partition, bypassing all object-level security. IBM i (AS/400) Operational Impact: Having 48 enabled *ALLOBJ profiles exposes the organization to massive insider threats, accidental data deletion/corruption, ransomware exploitation, and severe audit/compliance failures (e.g., PCI-DSS, SOX, HIPAA).IBM i (AS/400)

Over-Privileged Security Administrators (*SECADM)

Finding: 59 total profiles, with 40 active/enabled profiles possessing *SECADM special authority. Security Risk: *SECADM allows users to create, modify, or delete user profiles and alter user authorities. Operational Impact: 40 enabled security administrators creates an unmanageable privilege sprawl. Users with *SECADM can elevate their own privileges or create unauthorized backdoor accounts without proper oversight.

Identifying user profiles with special authorities is easy. SQL queries like below can extract and list down all the profiles.

SELECT AUTHORIZATION_NAME, SPECIAL_AUTHORITIES, STATUS
  FROM QSYS2.USER_INFO
 WHERE SPECIAL_AUTHORITIES LIKE '%*ALLOBJ%'
   AND STATUS = '*ENABLED';

SELECT AUTHORIZATION_NAME, SPECIAL_AUTHORITIES, STATUS
  FROM QSYS2.USER_INFO
 WHERE SPECIAL_AUTHORITIES LIKE '%*SECADM%'
   AND STATUS = '*ENABLED';

But the challenge is, how do you strip away dangerous special authorities without breaking your production banking apps? This is where IBM i Authority Collection—a native operating system feature designed to solve exactly this problem.

Remediation Plan & Next Steps

1. Implement Authority Collection: Turn on IBM i Authority Collection (STRAUTCOL) for profiles with *ALLOBJ to capture real-time runtime access requirements. Strategy for Removing *ALLOBJ Special Authority from IBM i User Profiles.
2. Apply Least Privilege: Query QSYS2.AUTHORITY_COLLECTION to replace broad special authorities with granular object-level rights (*USE, *CHANGE) or adopted authority.Strategy for Removing *ALLOBJ Special Authority from IBM i User Profiles.
3. Revoke Excess Special Authorities: Immediately strip *ALLOBJ, *JOBCTL, and *SPLCTL from regular business users, limiting *ALLOBJ to a minimal number of emergency/break-glass administrative accounts.

Here is a complete, step-by-step technical blueprint on how a bank can use Authority Collection to discover exact object requirements, eliminate excess privileges, and lock down its system.

Step 1: Identifying the Current Authority Challenge

The core problem in many legacy IBM i financial environments is fear of breakage. Administrators assign *ALLOBJ or wide-open public data authorities (*PUBLIC *RWX or *CHANGE) because finding the precise authority an application or user profile needs manually is like finding a needle in a haystack.

Instead of guessing what a core banking user profile (let’s call him user SAMEERA running the an application) actually needs, we can turn on IBM i’s runtime authority checker to passively log every single object access and permission check.

Step 2: Starting Authority Collection

To begin capturing runtime data for our targeted user profile and library, use the Start Authority Collection (STRAUTCOL) command:

For know user profiles:

STRAUTCOL USRPRF(SAMEERA) LIBINF((SATDTALIB)) OBJ(CUSTMAST) OBJTYPE(*FILE)

Note: You must have *ALLOBJ special authority or be authorized to the Database Security Administrator function (QIBM_DB_SECADM) to run these commands.

For all users:

Alternatively, if you want to track all users accessing specific high-risk objects across the partition, you can start system-level object authority collection:

CHGAUTCOL OBJ('/QSYS.LIB/SATDTALIB.LIB/CUSTMAST.FILE') AUTCOLVAL(*OBJINF)

if in case you want to start the collection for entire library

CHGAUTCOL OBJ('/QSYS.LIB/SATDTALIB.LIB') AUTCOLVAL(*OBJINF) SUBTREE(*ALL)

Perhaps if you want to include IFS files also within this,

CHGAUTCOL OBJ('/home/sameera') AUTCOLVAL(*OBJINF) SUBTREE(*ALL)

Finally make sure to start the collection with

STRAUTCOL TYPE(*OBJAUTCOL)

Step 3: Capturing Runtime Data

Once authority collection is active, let your users and batch jobs run normally through their standard daily cycles. Let the system collect data for a representative period—typically a few days or a full weekly/monthly processing cycle—to ensure all month-end reports, daily transactions, and exception paths are exercised.

During this phase, the operating system quietly logs all runtime authority checks into a secure system repository without impacting normal application flow.

The IBM i operating system provides four primary SQL views to query and analyze authority collection data:

• QSYS2.AUTHORITY_COLLECTION: The primary base view returning authority collection entries.
• QSYS2.AUTHORITY_COLLECTION_OBJECT: Used for QSYS-based objects when dealing with large datasets where you need to filter for specific objects or libraries.
• QSYS2.AUTHORITY_COLLECTION_LIBRARIES: Used for QSYS-based objects when the collection data is smaller or when you want to view most or all objects within a library.
• QSYS2.AUTHORITY_COLLECTION_FSOBJ: Used for integrated file system (IFS) objects located in the root (/), QOpenSys, and user-defined file systems.
• QSYS2.AUTHORITY_COLLECTION_DLO: Used specifically for document and folder objects (*DOC and *FLR).
• QSYS2.AUTHORITY_COLLECTION_IFS: This view is used to look at information that was collected for all file system objects in the “root” (/), QOpenSys, and user-defined file systems during authority collection for objects. This is a curated view with a modified layout, different than the other views.

Review which users have ACTIVE authority collection on-going?

SELECT AUTHORIZATION_NAME, AUTHORITY_COLLECTION_REPOSITORY_EXISTS 
  FROM QSYS2.USER_INFO 
    WHERE AUTHORITY_COLLECTION_ACTIVE = 'YES';

Which users have authority collection detail?

SELECT AUTHORIZATION_NAME, AUTHORITY_COLLECTION_ACTIVE 
  FROM QSYS2.USER_INFO 
    WHERE AUTHORITY_COLLECTION_REPOSITORY_EXISTS = 'YES';

Step 4: Stopping the Collection

Once you have gathered enough operational data (and after ensuring all relevant jobs have completed),stop the collection process using the End Authority Collection (ENDAUTCOL) command:

Plaintext

ENDAUTCOL TYPE(*USRPRF) USRPRF(SAMEERA)

(If you were tracking objects globally, you would end it with ENDAUTCOL TYPE(*OBJAUTCOL)). 

ENDAUTCOL TYPE(*OBJAUTCOL)

Stopping the collector pauses logging, but safely preserves everything captured in the system repository for analysis.

Step 5: Extracting Captured Data

IBM i exposes this collected goldmine through built-in SQL services. You can easily extract and query the data using Access Client Solutions (ACS) Run SQL Scripts.

How much Authority Collection detail was captured?

SELECT AUTHORIZATION_NAME, count(*) as AC_COUNT
  FROM qsys2.authority_collection 
  GROUP BY AUTHORIZATION_NAME
  ORDER BY 2 DESC;

To pull all records for our user SAMEERA and examine what they touched, run:

SELECT *
  FROM QSYS2.AUTHORITY_COLLECTION
 WHERE USER_NAME = 'SAMEERA';

Or narrow it down specifically to the critical payroll file we are auditing:

SELECT *
  FROM QSYS2.AUTHORITY_COLLECTION
 WHERE USER_NAME = 'SAMEERA'
       AND SYSTEM_OBJECT_NAME = 'CUSTMAST'
       AND SYSTEM_OBJECT_SCHEMA = 'SATDTALIB';

A few other SQL alternatives with minor changes to extract captured data.

SELECT AUTHORIZATION_NAME AS USER_NAME,
CHECK_TIMESTAMP,
SYSTEM_OBJECT_NAME,
SYSTEM_OBJECT_SCHEMA,
AUTHORITY_CHECK_SUCCESSFUL,
DETAILED_REQUIRED_AUTHORITY,
AUTHORITY_SOURCE,
JOB_NAME
FROM QSYS2.AUTHORITY_COLLECTION
WHERE AUTHORIZATION_NAME = 'SAMEERA'
AND SYSTEM_OBJECT_NAME = 'CUSTMAST';

SELECT
SYSTEM_OBJECT_SCHEMA CONCAT '/' CONCAT SYSTEM_OBJECT_NAME AS OBJECT,
SYSTEM_OBJECT_TYPE,
AUTHORITY_SOURCE,
DETAILED_CURRENT_AUTHORITY,
DETAILED_REQUIRED_AUTHORITY,
AC.*
FROM QSYS2.AUTHORITY_COLLECTION AC
WHERE AUTHORIZATION_NAME = 'SAMEERA'
AND SYSTEM_OBJECT_SCHEMA = 'SATDTALIB'
AND SYSTEM_OBJECT_NAME = 'CUSTMAST';

-- Review the successes
SELECT system_object_schema concat '/' concat system_object_name as Object, 
       system_object_type, authority_source, 
       detailed_current_authority,
       detailed_required_authority, ac.*
     FROM qsys2.authority_collection ac
     WHERE authorization_name = 'SAMEERA' and
      (system_object_schema concat '/' concat system_object_name like '%CUSTMAST%') and
           authority_check_successful = '1';

-- Review use of adopted authority 
SELECT adopting_program_schema concat '/' concat adopting_program_name as Object, 
       adopting_program_type,    current_adopted_authority, 
       adopted_authority_source, detailed_required_authority, 
       multiple_adopting_programs_used, ac.*
     FROM qsys2.authority_collection ac
     WHERE authorization_name = 'SAMEERA' and
           adopt_authority_used = '1';

-- Which commands and programs are being used?           
SELECT SYSTEM_OBJECT_SCHEMA concat '/' concat SYSTEM_OBJECT_NAME as Object, COUNT(*) as COUNT
 FROM QSYS2.AUTHORITY_COLLECTION A
 WHERE SYSTEM_OBJECT_TYPE IN ('*PGM', '*CMD') and authorization_name = 'SAMEERA' 
 GROUP BY SYSTEM_OBJECT_SCHEMA concat '/' concat SYSTEM_OBJECT_NAME   
 ORDER BY 2 DESC;

Step 6: Analyzing the Data and Identifying Required Information

When you look at the query results, you will see powerful diagnostic columns such as REQAUTH (Required Authority), CURAUTH (Current Authority), and AUTHSRC (Authority Source—showing whether access came from a private authority, group profile, or adopted authority).

When reviewing your SQL output, focus on these critical indicators:

Step 1. Check Success (CHKSUCCESS): Rows where CHKSUCCESS = '0' represent actual authority failures or boundary hits that need attention.

• Check Authority Success (AUTHORITY_CHECK_SUCCESSFUL)
  • Value 1 (Success): The operation was permitted. All rows in our sample dataset show 1, meaning user SAMEERA successfully performed the requested actions. Rows where CHKSUCCESS = '1' and CURAUTH heavily exceeds REQAUTH flag candidates where you can safely reduce permissions.
  • Value 0 (Failure): These represent access violations (unauthorized attempts). If any rows show 0, they are your highest-priority items to investigate to see if a user or program lacked necessary permissions.

Step 2. Compare Required vs. Current Authority

Analyze the relationship between what the system asked for versus what the user possessed during each call: Use columns like Detailed Required Authority (DTLREQAUTH) and Detailed Current Authority (DTLCURAUTH) to compare exact authority bits when summarized values look identical, allowing you to tune access down to the absolute minimum required level.

• DETAILED_REQUIRED_AUTHORITY: Shows the exact authorities needed at that specific runtime instant (e.g., *READ, *OBJOPR, *READ *ADD, *READ *DLT).
• DETAILED_CURRENT_AUTHORITY / AUTHORITY_SOURCE: Shows what authority the user actually held. In our sample data, AUTHORITY_SOURCE shows USER *ALLOBJ for all entries, meaning user SAMEERA has *ALLOBJ special authority, granting blanket access to everything.

Step 3. Identify Over-Privileged Access (Reduction Candidates)

• Look for rows where AUTHORITY_CHECK_SUCCESSFUL = 1 and the current/adopted authority greatly exceeds the required authority.
• Example from our data: A check required only *READ or *OBJOPR, but the user executed it under USER *ALLOBJ. This confirms SAMEERA (or the application workflow) has excessive rights and can be restricted to specific object authorities (like *USE or *CHANGE) once collection is complete.

4. Examine Program and Job Context

Review the execution context to understand how the access was triggered:

• MOST_RECENT_PROGRAM_INVOKED & MOST_RECENT_MODULE: Shows the system or application programs making the call (e.g., QQQSRVV1 / QQQVFILE for query processing, QDBOPEN for database file opening).
• JOB_NAME, JOB_USER, JOB_NUMBER: Identifies the job context (e.g., interactive session QPADEV000R run by user SAMEERA, or server jobs like QZDASSINIT).

Step 7: Remediating and Securing the Environment

Armed with precise facts from your Authority Collection analysis, you can finally execute true security remediation:

To holistically remediate and secure the environment following an authority collection analysis (moving away from over-privileged access like *ALLOBJ), follow a structured, multi-phase lifecycle approach:

1. Granular Permission Provisioning (Least Privilege)

• Grant Precise Object Authorities: Using the insights from QSYS2.AUTHORITY_COLLECTION(specifically DETAILED_REQUIRED_AUTHORITY), assign only the explicit object-level rights needed (e.g., *USE or specific data read/write rights) rather than relying on blanket permissions.
• Review Program Adoption: Evaluate if certain processes require adopted authority instead of direct user grants to securely execute privileged functions without exposing raw object control.

2. Privileged Access Stripping

• Revoke *ALLOBJ and Special Authorities: Safely remove high-risk special authorities (such as *ALLOBJ, *JOBCTL, and *SPLCTL) from routine business user profiles using the CHGUSRPRFcommand.
• Establish Break-Glass Procedures: Limit blanket administrative rights exclusively to heavily monitored, highly restricted emergency or administrator accounts. Perform these changes during controlled maintenance windows with a rollback plan ready.

3. Post-Removal Monitoring and Auditing

• Configure System Auditing (QAUDJRN): Ensure that security auditing is active (QAUDCTL includes *AUDLVL and QAUDLVL or QAUDLVL2 includes *AUTFAIL) to record authority failure entries (AF).
• Track Failures Proactively: Utilize SQL table functions like SYSTOOLS.AUDIT_JOURNAL_AF to monitor for any unexpected permission gaps or rare edge-case jobs hitting blocks immediately following the removal of excess privileges.

SELECT
ENTRY_TIMESTAMP,
USER_PROFILE_NAME,
JOB_NAME,
JOB_USER,
JOB_NUMBER,
VIOLATION_TYPE,
VIOLATION_TYPE_DETAIL,
OBJECT_LIBRARY,
OBJECT_NAME,
OBJECT_TYPE
FROM TABLE (
SYSTOOLS.AUDIT_JOURNAL_AF(STARTING_TIMESTAMP => CURRENT TIMESTAMP - 7 DAYS)
)
WHERE OBJECT_NAME IS NOT NULL
ORDER BY ENTRY_TIMESTAMP DESC;

By moving from blind trust (*ALLOBJ) to data-driven zero trust using IBM i Authority Collection, your bank can satisfy internal auditors, protect sensitive customer assets, and keep core financial applications running smoothly.