IBM i Security

Audit Authority Changes Caused by Restored IBM i Objects with SQL

Use SYSTOOLS.AUDIT_JOURNAL_RA to find restored IBM i objects whose authorization list, public authority, or private authority changed during restore, then validate the resulting security exposure.

A restored object can return successfully while its security configuration changes. The authorization list can be removed, public authority can be forced to *EXCLUDE, or private authority can be removed. SYSTOOLS.AUDIT_JOURNAL_RA makes those restore-time authority changes queryable through SQL.

The service returns audit entry type:

RA

which represents:

Authority Change for Restored Object

This is especially useful after:

• disaster-recovery testing
• production recovery
• cross-system migration
• environment refresh
• application-library restoration
• IFS restoration
• object-level recovery

The central questions are:

Which object was restored?
What authority changed?
Was its authorization list removed?
Did the saved and restored authorization lists differ?
Was public authority set to *EXCLUDE?
Were private authorities removed?
Does the current object match the approved target policy?

Why a successful restore can still create a security issue

A restore command can complete while changing an object’s security configuration.

This can happen because:

• the saved authorization list does not exist on the target
• authorization-list differences were not allowed
• an existing object was already secured differently
• the target intentionally uses a different authorization list
• private authority was removed during object restoration
• the system protected the restored object with *PUBLIC *EXCLUDE

Some outcomes are protective. Others indicate that the recovered application no longer has the intended access model.

The RA audit entry records the result.

Query recent RA entries

SELECT *
FROM TABLE(
    SYSTOOLS.AUDIT_JOURNAL_RA(
        STARTING_TIMESTAMP =>
            CURRENT TIMESTAMP - 1 DAY
    )
)
ORDER BY
    ENTRY_TIMESTAMP DESC;

The function returns common audit-journal columns followed by RA-specific fields.

Important RA columns

ENTRY_TYPE
ENTRY_TYPE_DETAIL
OBJECT_LIBRARY
OBJECT_NAME
OBJECT_TYPE
OBJECT_ASP_NAME
OBJECT_ASP_NUMBER
SAVE_AUTHORIZATION_LIST
RESTORE_AUTHORIZATION_LIST
AUTHORIZATION_LIST_REMOVED
PUBLIC_AUTHORITY_EXCLUDE
PRIVATE_AUTHORITY_REMOVED
PATH_NAME
PATH_NAME_INDICATOR
RELATIVE_DIRECTORY_FILE_ID
IFS_OBJECT_NAME
OBJECT_FILE_ID
PARENT_FILE_ID
DLO_NAME
FOLDER_PATH

For ENTRY_TYPE:

A

means authority changed for a restored object.

Understand the key indicators

AUTHORIZATION_LIST_REMOVED

YES

means the authorization list was removed from the restored object.

PUBLIC_AUTHORITY_EXCLUDE

YES

means public authority was set to:

*EXCLUDE

PRIVATE_AUTHORITY_REMOVED

YES

means private authority was removed from the restored object.

These values describe what occurred during restore. They do not decide whether the result is correct for the target environment.

Review recent restore-time authority changes

SELECT
    ENTRY_TIMESTAMP,
    USER_NAME AS RESTORE_RUN_BY,
    QUALIFIED_JOB_NAME,
    PROGRAM_LIBRARY,
    PROGRAM_NAME,
    OBJECT_LIBRARY,
    OBJECT_NAME,
    OBJECT_TYPE,
    OBJECT_ASP_NAME,
    OBJECT_ASP_NUMBER,
    SAVE_AUTHORIZATION_LIST,
    RESTORE_AUTHORIZATION_LIST,
    AUTHORIZATION_LIST_REMOVED,
    PUBLIC_AUTHORITY_EXCLUDE,
    PRIVATE_AUTHORITY_REMOVED,
    PATH_NAME,
    RECEIVER_LIBRARY,
    RECEIVER_NAME,
    SEQUENCE_NUMBER
FROM TABLE(
    SYSTOOLS.AUDIT_JOURNAL_RA(
        STARTING_TIMESTAMP =>
            CURRENT TIMESTAMP - 7 DAYS
    )
)
ORDER BY
    ENTRY_TIMESTAMP DESC,
    SEQUENCE_NUMBER DESC;

This provides the restore job, effective user, object identity, saved security state, restored security state, and the exact journal position.

Find authorization lists removed during restore

SELECT
    ENTRY_TIMESTAMP,
    USER_NAME AS RESTORE_RUN_BY,
    QUALIFIED_JOB_NAME,
    OBJECT_LIBRARY,
    OBJECT_NAME,
    OBJECT_TYPE,
    SAVE_AUTHORIZATION_LIST,
    RESTORE_AUTHORIZATION_LIST,
    PUBLIC_AUTHORITY_EXCLUDE,
    PRIVATE_AUTHORITY_REMOVED
FROM TABLE(
    SYSTOOLS.AUDIT_JOURNAL_RA(
        STARTING_TIMESTAMP =>
            CURRENT TIMESTAMP - 30 DAYS
    )
)
WHERE AUTHORIZATION_LIST_REMOVED = 'YES'
ORDER BY
    ENTRY_TIMESTAMP DESC;

Investigate whether:

• the saved authorization list exists on the target
• the authorization list was restored before the object
• the restore allowed authorization-list differences
• a target-specific list was expected instead
• public authority was safely changed to *EXCLUDE
• application users lost required access

Find saved and restored authorization-list differences

SELECT
    ENTRY_TIMESTAMP,
    OBJECT_LIBRARY,
    OBJECT_NAME,
    OBJECT_TYPE,
    SAVE_AUTHORIZATION_LIST,
    RESTORE_AUTHORIZATION_LIST,
    AUTHORIZATION_LIST_REMOVED,
    PUBLIC_AUTHORITY_EXCLUDE
FROM TABLE(
    SYSTOOLS.AUDIT_JOURNAL_RA(
        STARTING_TIMESTAMP =>
            CURRENT TIMESTAMP - 30 DAYS
    )
)
WHERE COALESCE(SAVE_AUTHORIZATION_LIST, '') <>
      COALESCE(RESTORE_AUTHORIZATION_LIST, '')
ORDER BY
    ENTRY_TIMESTAMP DESC;

A difference can be legitimate when the target object intentionally retains its local authorization list.

It can also indicate:

• a missing authorization list
• an environment mismatch
• an incomplete security restore
• a restore performed with permissive ALWOBJDIF settings
• an object no longer secured by the expected policy

Review objects set to *PUBLIC *EXCLUDE

IBM documents that when a required authorization list is unavailable in certain restore scenarios, an object can be restored without the authorization-list association and public authority can be changed to *EXCLUDE.

SELECT
    ENTRY_TIMESTAMP,
    OBJECT_LIBRARY,
    OBJECT_NAME,
    OBJECT_TYPE,
    SAVE_AUTHORIZATION_LIST,
    RESTORE_AUTHORIZATION_LIST,
    AUTHORIZATION_LIST_REMOVED,
    PUBLIC_AUTHORITY_EXCLUDE
FROM TABLE(
    SYSTOOLS.AUDIT_JOURNAL_RA(
        STARTING_TIMESTAMP =>
            CURRENT TIMESTAMP - 30 DAYS
    )
)
WHERE PUBLIC_AUTHORITY_EXCLUDE = 'YES'
ORDER BY
    ENTRY_TIMESTAMP DESC;

*EXCLUDE can prevent unintended access, but it can also cause:

• application failures
• batch-job failures
• API authorization failures
• inaccessible IFS content
• support incidents after recovery

Treat it as a required review, not automatically as a vulnerability.

Find removed private authority

SELECT
    ENTRY_TIMESTAMP,
    USER_NAME AS RESTORE_RUN_BY,
    QUALIFIED_JOB_NAME,
    OBJECT_LIBRARY,
    OBJECT_NAME,
    OBJECT_TYPE,
    SAVE_AUTHORIZATION_LIST,
    RESTORE_AUTHORIZATION_LIST,
    PRIVATE_AUTHORITY_REMOVED
FROM TABLE(
    SYSTOOLS.AUDIT_JOURNAL_RA(
        STARTING_TIMESTAMP =>
            CURRENT TIMESTAMP - 30 DAYS
    )
)
WHERE PRIVATE_AUTHORITY_REMOVED = 'YES'
ORDER BY
    ENTRY_TIMESTAMP DESC;

Private authority can be restored later through the approved recovery sequence, including RSTAUT.

Do not assume the object is permanently missing authority solely because the RA entry shows private authority was removed during object restore.

Correlate the result with:

• later RU entries
• RSTAUT job logs
• current object authority
• the recovery runbook
• final security validation

Build a risk-focused report

SELECT
    ENTRY_TIMESTAMP,
    OBJECT_LIBRARY,
    OBJECT_NAME,
    OBJECT_TYPE,
    SAVE_AUTHORIZATION_LIST,
    RESTORE_AUTHORIZATION_LIST,
    AUTHORIZATION_LIST_REMOVED,
    PUBLIC_AUTHORITY_EXCLUDE,
    PRIVATE_AUTHORITY_REMOVED,
    CASE
        WHEN AUTHORIZATION_LIST_REMOVED = 'YES'
          THEN 'AUTHORIZATION LIST REMOVED'
        WHEN COALESCE(SAVE_AUTHORIZATION_LIST, '') <>
             COALESCE(RESTORE_AUTHORIZATION_LIST, '')
          THEN 'AUTHORIZATION LIST CHANGED'
        WHEN PUBLIC_AUTHORITY_EXCLUDE = 'YES'
          THEN 'PUBLIC SET TO *EXCLUDE'
        WHEN PRIVATE_AUTHORITY_REMOVED = 'YES'
          THEN 'PRIVATE AUTHORITY REMOVED'
        ELSE 'REVIEW'
    END AS REVIEW_REASON
FROM TABLE(
    SYSTOOLS.AUDIT_JOURNAL_RA(
        STARTING_TIMESTAMP =>
            CURRENT TIMESTAMP - 7 DAYS
    )
)
ORDER BY
    ENTRY_TIMESTAMP DESC;

The order of the CASE expression determines which reason is shown when multiple indicators are present. Preserve each indicator separately in the evidence table.

Summarize by library

SELECT
    OBJECT_LIBRARY,
    COUNT(*) AS RA_ENTRY_COUNT,
    SUM(
        CASE
            WHEN AUTHORIZATION_LIST_REMOVED = 'YES'
              THEN 1
            ELSE 0
        END
    ) AS AUTHORIZATION_LIST_REMOVALS,
    SUM(
        CASE
            WHEN PUBLIC_AUTHORITY_EXCLUDE = 'YES'
              THEN 1
            ELSE 0
        END
    ) AS PUBLIC_EXCLUDE_CHANGES,
    SUM(
        CASE
            WHEN PRIVATE_AUTHORITY_REMOVED = 'YES'
              THEN 1
            ELSE 0
        END
    ) AS PRIVATE_AUTHORITY_REMOVALS
FROM TABLE(
    SYSTOOLS.AUDIT_JOURNAL_RA(
        STARTING_TIMESTAMP =>
            CURRENT TIMESTAMP - 30 DAYS
    )
)
GROUP BY
    OBJECT_LIBRARY
ORDER BY
    AUTHORIZATION_LIST_REMOVALS DESC,
    PRIVATE_AUTHORITY_REMOVALS DESC,
    RA_ENTRY_COUNT DESC;

This can reveal one library restored before its security objects, an unavailable ASP, an environment-policy mismatch, or one restore command affecting a broad group of objects.

Review IFS objects separately

For objects in the root, QOpenSys, or user-defined file systems, use:

PATH_NAME
PATH_NAME_INDICATOR
IFS_OBJECT_NAME
OBJECT_FILE_ID
PARENT_FILE_ID

SELECT
    ENTRY_TIMESTAMP,
    PATH_NAME,
    PATH_NAME_INDICATOR,
    IFS_OBJECT_NAME,
    SAVE_AUTHORIZATION_LIST,
    RESTORE_AUTHORIZATION_LIST,
    AUTHORIZATION_LIST_REMOVED,
    PUBLIC_AUTHORITY_EXCLUDE,
    PRIVATE_AUTHORITY_REMOVED
FROM TABLE(
    SYSTOOLS.AUDIT_JOURNAL_RA(
        STARTING_TIMESTAMP =>
            CURRENT TIMESTAMP - 7 DAYS
    )
)
WHERE PATH_NAME IS NOT NULL
ORDER BY
    ENTRY_TIMESTAMP DESC;

When PATH_NAME_INDICATOR = 'NO', the path is relative rather than absolute. File identifiers can provide stronger identity when names have changed.

Compare with current authorization-list state

QSYS2.AUTHORIZATION_LIST_INFO returns objects currently secured by authorization lists.

SELECT
    AUTHORIZATION_LIST,
    SYSTEM_OBJECT_SCHEMA,
    SYSTEM_OBJECT_NAME,
    SYSTEM_OBJECT_TYPE,
    ASPGRP,
    PATH_NAME
FROM QSYS2.AUTHORIZATION_LIST_INFO
WHERE AUTHORIZATION_LIST = 'APPAUTL';

A recovery review can compare the saved list, restored list, and current list.

SELECT
    R.ENTRY_TIMESTAMP,
    R.OBJECT_LIBRARY,
    R.OBJECT_NAME,
    R.OBJECT_TYPE,
    R.SAVE_AUTHORIZATION_LIST,
    R.RESTORE_AUTHORIZATION_LIST,
    CASE
        WHEN A.AUTHORIZATION_LIST IS NULL
          THEN 'NOT CURRENTLY FOUND ON EXPECTED AUTL'
        ELSE 'CURRENTLY SECURED BY EXPECTED AUTL'
    END AS CURRENT_STATE
FROM TABLE(
    SYSTOOLS.AUDIT_JOURNAL_RA(
        STARTING_TIMESTAMP =>
            CURRENT TIMESTAMP - 30 DAYS
    )
) AS R
LEFT JOIN QSYS2.AUTHORIZATION_LIST_INFO AS A
  ON A.AUTHORIZATION_LIST = R.SAVE_AUTHORIZATION_LIST
 AND A.SYSTEM_OBJECT_SCHEMA = R.OBJECT_LIBRARY
 AND A.SYSTEM_OBJECT_NAME = R.OBJECT_NAME
WHERE R.SAVE_AUTHORIZATION_LIST IS NOT NULL
ORDER BY
    R.ENTRY_TIMESTAMP DESC;

Test the join against the installed release and object types. IFS objects require path-based matching.

Review current direct authority

QSYS2.OBJECT_PRIVILEGES returns users currently authorized to QSYS objects.

SELECT
    AUTHORIZATION_NAME,
    OBJECT_AUTHORITY,
    AUTHORIZATION_LIST,
    OBJECT_OWNER,
    PRIMARY_GROUP
FROM QSYS2.OBJECT_PRIVILEGES
WHERE SYSTEM_OBJECT_SCHEMA = 'APPLIB'
  AND SYSTEM_OBJECT_NAME = 'ORDERS'
  AND OBJECT_TYPE = '*FILE';

Use it to determine whether:

• required users still have access
• unexpected direct authority exists
• the object is currently linked to an authorization list
• owner and primary group match policy

The caller’s authority determines how much detail is returned.

Compare against an approved policy table

CREATE TABLE SECURITY.OBJECT_AUTHORITY_POLICY
(
    ENVIRONMENT_NAME       VARCHAR(20) NOT NULL,
    OBJECT_LIBRARY         VARCHAR(10) NOT NULL,
    OBJECT_NAME            VARCHAR(10) NOT NULL,
    OBJECT_TYPE            VARCHAR(10) NOT NULL,
    AUTHORIZATION_LIST     VARCHAR(10),
    PUBLIC_AUTHORITY       VARCHAR(12),
    POLICY_OWNER           VARCHAR(128),
    REVIEW_PRIORITY        INTEGER NOT NULL,
    PRIMARY KEY
    (
        ENVIRONMENT_NAME,
        OBJECT_LIBRARY,
        OBJECT_NAME,
        OBJECT_TYPE
    )
);

SELECT
    R.ENTRY_TIMESTAMP,
    R.OBJECT_LIBRARY,
    R.OBJECT_NAME,
    R.OBJECT_TYPE,
    R.SAVE_AUTHORIZATION_LIST,
    R.RESTORE_AUTHORIZATION_LIST,
    P.AUTHORIZATION_LIST
        AS EXPECTED_AUTHORIZATION_LIST,
    CASE
        WHEN P.OBJECT_NAME IS NULL
          THEN 'NO POLICY'
        WHEN COALESCE(R.RESTORE_AUTHORIZATION_LIST, '') <>
             COALESCE(P.AUTHORIZATION_LIST, '')
          THEN 'POLICY MISMATCH'
        ELSE 'MATCH'
    END AS POLICY_STATUS,
    P.POLICY_OWNER,
    P.REVIEW_PRIORITY
FROM TABLE(
    SYSTOOLS.AUDIT_JOURNAL_RA(
        STARTING_TIMESTAMP =>
            CURRENT TIMESTAMP - 7 DAYS
    )
) AS R
LEFT JOIN SECURITY.OBJECT_AUTHORITY_POLICY AS P
  ON P.ENVIRONMENT_NAME = 'PROD'
 AND P.OBJECT_LIBRARY = R.OBJECT_LIBRARY
 AND P.OBJECT_NAME = R.OBJECT_NAME
 AND P.OBJECT_TYPE = R.OBJECT_TYPE
ORDER BY
    P.REVIEW_PRIORITY DESC,
    R.ENTRY_TIMESTAMP DESC;

Understand ALWOBJDIF

Restore commands can use ALWOBJDIF to control how differences between saved and existing objects are handled.

Authorization-list-related values include:

*AUTL
*ALL
*COMPATIBLE

A recovery runbook should record:

The restore command
The ALWOBJDIF value
The source system
The target system
The expected authorization-list behavior
Approved exceptions

Do not evaluate an RA entry without knowing the restore parameters.

Correlate with related audit entry types

A complete restore-security review may also use:

OR   Object restored
RA   Authority changed for restored object
RO   Ownership changed for restored object
RP   Program adopting authority restored
RU   User-profile authority restored
RZ   Primary group changed for restored object
RJ   Job description restored with named profile

The RA entry explains one security dimension. It does not provide the complete recovered object state.

Preserve evidence

CREATE TABLE RECOVERY.RA_AUDIT_EVIDENCE
(
    RECOVERY_ID                 VARCHAR(40) NOT NULL,
    SOURCE_SYSTEM               VARCHAR(8) NOT NULL,
    RECEIVER_LIBRARY            VARCHAR(10) NOT NULL,
    RECEIVER_NAME               VARCHAR(10) NOT NULL,
    SEQUENCE_NUMBER             DECIMAL(21, 0) NOT NULL,
    ENTRY_TIMESTAMP             TIMESTAMP NOT NULL,
    RESTORE_RUN_BY              VARCHAR(10),
    QUALIFIED_JOB_NAME          VARCHAR(28),
    OBJECT_LIBRARY              VARCHAR(10),
    OBJECT_NAME                 VARCHAR(10),
    OBJECT_TYPE                 VARCHAR(10),
    SAVE_AUTHORIZATION_LIST     VARCHAR(10),
    RESTORE_AUTHORIZATION_LIST  VARCHAR(10),
    AUTHORIZATION_LIST_REMOVED  VARCHAR(3),
    PUBLIC_AUTHORITY_EXCLUDE    VARCHAR(3),
    PRIVATE_AUTHORITY_REMOVED   VARCHAR(3),
    REVIEW_STATUS               VARCHAR(24) NOT NULL,
    ISSUE_REFERENCE             VARCHAR(128),
    REVIEW_NOTES                VARCHAR(2048),
    PRIMARY KEY
    (
        SOURCE_SYSTEM,
        RECEIVER_LIBRARY,
        RECEIVER_NAME,
        SEQUENCE_NUMBER
    )
);

Useful statuses include:

NEW
EXPECTED
REVIEW REQUIRED
AUTL MISSING
POLICY MISMATCH
ACCESS RESTORED
REMEDIATED
APPROVED EXCEPTION

Use bounded extraction

A scheduled collector should preserve:

Journal
Receiver library
Receiver name
Sequence number
Entry timestamp
Recovery ID
Collection status

Read a bounded range, store the entries, commit the evidence, then advance the checkpoint.

Do not store only sequence number because journal sequences can be reset.

Auditing must already be active

The function reads RA evidence from:

QSYS/QAUDJRN

The audit policy must have been active when the restore occurred, and the required receiver must still be available.

Save-and-restore security activity is associated with auditing coverage such as:

*SAVRST

Confirm the organization’s actual settings through:

QAUDCTL
QAUDLVL
QAUDLVL2
QSYS2.SECURITY_INFO

A query cannot recreate evidence that was never collected.

Required authority

The reporting profile needs appropriate access to:

QSYS/QAUDJRN
The journal library
Every requested audit receiver
Each receiver library

Current-state validation through AUTHORIZATION_LIST_INFO and OBJECT_PRIVILEGES has its own authority requirements.

Prefer:

• a dedicated audit-reporting profile
• QIBM_DB_SECADM function usage where appropriate
• explicit journal and receiver authority
• no unnecessary *ALLOBJ
• protected evidence tables
• separation between collection and remediation

Do not auto-remediate every RA entry

An automated process should not blindly:

• relink the saved authorization list
• grant private authority
• change public authority
• replace target security configuration

The target environment may intentionally differ from the source.

Use this workflow:

Collect
Classify
Compare with target policy
Review restore parameters
Validate current authority
Confirm application impact
Approve remediation
Apply the controlled change
Revalidate
Preserve evidence

Recovery sign-off checklist

Before closing a recovery or DR exercise:

Collect all RA entries for the recovery window
Review every authorization-list removal
Review saved versus restored AUTL differences
Investigate every public *EXCLUDE change
Correlate removed private authority with RSTAUT results
Validate current object authority
Compare with the target environment policy
Test critical application access
Preserve receiver and sequence evidence
Obtain security-owner approval

Service availability

The SYSTOOLS.AUDIT_JOURNAL_RA helper function was added to the IBM i 7.5 and 7.4 update streams in the May 2023 SQL-services update.

IBM documents these minimum Db2 Group PTF levels:

IBM i 7.5 — SF99950 Level 4
IBM i 7.4 — SF99704 Level 25

It is also available on IBM i 7.6.

Confirm the installed Db2 Group PTF before deploying the query.

Final takeaway

A successful object restore does not prove that the object’s authority model was preserved.

SYSTOOLS.AUDIT_JOURNAL_RA exposes:

The authorization list on the save media
The authorization list after restore
Whether the authorization list was removed
Whether public authority became *EXCLUDE
Whether private authority was removed
The object, job, operator, ASP, receiver, and sequence

Use the RA entry to detect restore-time security changes.

Then compare the result with the approved target policy, current object authority, later RSTAUT activity, and actual application access.

Restore completion is an operational result.

Security validation is a separate control.