IBM i Security

Audit IBM i Job Description USER Changes with SQL

Use SYSTOOLS.AUDIT_JOURNAL_JD to identify who created or changed the USER parameter of an IBM i job description, compare previous and current profiles, assess risk, and build a controlled monitoring workflow.

An IBM i job description can define the user profile associated with jobs that use it. A change to that USER parameter can therefore alter the identity—and potentially the authority context—of future jobs. SYSTOOLS.AUDIT_JOURNAL_JD makes those changes queryable through SQL.

The service returns JD audit-journal entries created when the USER parameter is specified or changed by:

CRTJOBD
CHGJOBD

The key questions are:

Which job description changed?
Who made the change?
When did it happen?
Was the object created or modified?
What profile was previously specified?
What profile is specified now?

Why the USER parameter matters

Every job uses a job description during job initiation.

A job description can influence:

• user identity
• job queue
• output queue
• library list
• current library
• routing data
• logging
• job priority

IBM warns that a job description containing a specific user profile should be tightly controlled.

At security levels 40 and 50, SBMJOB USER(*JOBD) requires the submitter to have *USE authority to both the job description and the profile named in it.

At security level 30 and below, the exposure can be greater because a submitter may be able to run under the named profile without direct authority to that profile.

The audit entry does not determine whether the change was malicious. It preserves evidence that the change occurred.

Query the JD audit entries

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

Important JD-specific columns include:

ENTRY_TYPE
ENTRY_TYPE_DETAIL
JOB_DESCRIPTION_LIBRARY
JOB_DESCRIPTION
COMMAND_TYPE
JOB_DESCRIPTION_USER
PREV_JOB_DESCRIPTION_USER
ASP_NAME
ASP_NUMBER

COMMAND_TYPE contains:

CREATE
CHANGE

JOB_DESCRIPTION_USER is the new value.

PREV_JOB_DESCRIPTION_USER is the previous value and is null for CREATE.

Common audit context

The service also returns common audit-journal columns such as:

ENTRY_TIMESTAMP
SEQUENCE_NUMBER
USER_NAME
QUALIFIED_JOB_NAME
JOB_NAME
JOB_USER
JOB_NUMBER
THREAD
PROGRAM_LIBRARY
PROGRAM_NAME
SYSTEM_NAME
SYSTEM_SEQUENCE_NUMBER
RECEIVER_LIBRARY
RECEIVER_NAME

USER_NAME identifies the effective profile under which the thread was running.

JOB_USER identifies the profile that started the job.

Those values can differ.

Review changes from the last seven days

SELECT
    ENTRY_TIMESTAMP,
    USER_NAME AS CHANGED_BY,
    QUALIFIED_JOB_NAME,
    JOB_DESCRIPTION_LIBRARY,
    JOB_DESCRIPTION,
    PREV_JOB_DESCRIPTION_USER,
    JOB_DESCRIPTION_USER
FROM TABLE(
    SYSTOOLS.AUDIT_JOURNAL_JD(
        STARTING_TIMESTAMP =>
            CURRENT TIMESTAMP - 7 DAYS
    )
)
WHERE COMMAND_TYPE = 'CHANGE'
ORDER BY
    ENTRY_TIMESTAMP DESC;

Include both create and change activity

SELECT
    ENTRY_TIMESTAMP,
    COMMAND_TYPE,
    USER_NAME AS CHANGED_BY,
    QUALIFIED_JOB_NAME,
    PROGRAM_LIBRARY,
    PROGRAM_NAME,
    JOB_DESCRIPTION_LIBRARY,
    JOB_DESCRIPTION,
    PREV_JOB_DESCRIPTION_USER,
    JOB_DESCRIPTION_USER,
    ASP_NAME,
    ASP_NUMBER,
    RECEIVER_LIBRARY,
    RECEIVER_NAME,
    SEQUENCE_NUMBER
FROM TABLE(
    SYSTOOLS.AUDIT_JOURNAL_JD(
        STARTING_TIMESTAMP =>
            CURRENT TIMESTAMP - 30 DAYS
    )
)
ORDER BY
    ENTRY_TIMESTAMP DESC,
    SEQUENCE_NUMBER DESC;

Find *RQD changed to a named profile

SELECT
    ENTRY_TIMESTAMP,
    USER_NAME AS CHANGED_BY,
    QUALIFIED_JOB_NAME,
    JOB_DESCRIPTION_LIBRARY,
    JOB_DESCRIPTION,
    PREV_JOB_DESCRIPTION_USER,
    JOB_DESCRIPTION_USER
FROM TABLE(
    SYSTOOLS.AUDIT_JOURNAL_JD(
        STARTING_TIMESTAMP =>
            CURRENT TIMESTAMP - 90 DAYS
    )
)
WHERE COMMAND_TYPE = 'CHANGE'
  AND PREV_JOB_DESCRIPTION_USER = '*RQD'
  AND JOB_DESCRIPTION_USER <> '*RQD'
ORDER BY
    ENTRY_TIMESTAMP DESC;

Review each result against:

• approved purpose
• object authority
• authority of the named profile
• where the job description is referenced
• associated deployment or change record

Find sensitive profiles

Create a controlled list:

CREATE TABLE SECURITY.SENSITIVE_PROFILE
(
    USER_PROFILE       VARCHAR(10) PRIMARY KEY,
    RISK_CLASS         VARCHAR(20) NOT NULL,
    BUSINESS_OWNER     VARCHAR(128),
    TECHNICAL_OWNER    VARCHAR(128),
    REVIEW_REQUIRED    CHAR(1) NOT NULL
);

Then query:

SELECT
    J.ENTRY_TIMESTAMP,
    J.USER_NAME AS CHANGED_BY,
    J.QUALIFIED_JOB_NAME,
    J.JOB_DESCRIPTION_LIBRARY,
    J.JOB_DESCRIPTION,
    J.PREV_JOB_DESCRIPTION_USER,
    J.JOB_DESCRIPTION_USER,
    P.RISK_CLASS,
    P.BUSINESS_OWNER,
    P.TECHNICAL_OWNER
FROM TABLE(
    SYSTOOLS.AUDIT_JOURNAL_JD(
        STARTING_TIMESTAMP =>
            CURRENT TIMESTAMP - 30 DAYS
    )
) AS J
JOIN SECURITY.SENSITIVE_PROFILE AS P
  ON P.USER_PROFILE = J.JOB_DESCRIPTION_USER
WHERE P.REVIEW_REQUIRED = 'Y'
ORDER BY
    J.ENTRY_TIMESTAMP DESC;

Detect repeated changes

SELECT
    JOB_DESCRIPTION_LIBRARY,
    JOB_DESCRIPTION,
    COUNT(*) AS CHANGE_COUNT,
    MIN(ENTRY_TIMESTAMP) AS FIRST_CHANGE,
    MAX(ENTRY_TIMESTAMP) AS MOST_RECENT_CHANGE
FROM TABLE(
    SYSTOOLS.AUDIT_JOURNAL_JD(
        STARTING_TIMESTAMP =>
            CURRENT TIMESTAMP - 30 DAYS
    )
)
WHERE COMMAND_TYPE = 'CHANGE'
GROUP BY
    JOB_DESCRIPTION_LIBRARY,
    JOB_DESCRIPTION
HAVING COUNT(*) > 1
ORDER BY
    CHANGE_COUNT DESC,
    MOST_RECENT_CHANGE DESC;

Repeated changes can indicate testing, competing automation, an unstable deployment, or a legitimate temporary maintenance action.

The count is a signal, not a conclusion.

Compare with the current job-description value

WITH JD_CHANGES AS
(
    SELECT
        ENTRY_TIMESTAMP,
        USER_NAME AS CHANGED_BY,
        QUALIFIED_JOB_NAME,
        JOB_DESCRIPTION_LIBRARY,
        JOB_DESCRIPTION,
        PREV_JOB_DESCRIPTION_USER,
        JOB_DESCRIPTION_USER
    FROM TABLE(
        SYSTOOLS.AUDIT_JOURNAL_JD(
            STARTING_TIMESTAMP =>
                CURRENT TIMESTAMP - 30 DAYS
        )
    )
    WHERE COMMAND_TYPE = 'CHANGE'
)
SELECT
    C.ENTRY_TIMESTAMP,
    C.CHANGED_BY,
    C.QUALIFIED_JOB_NAME,
    C.JOB_DESCRIPTION_LIBRARY,
    C.JOB_DESCRIPTION,
    C.PREV_JOB_DESCRIPTION_USER,
    C.JOB_DESCRIPTION_USER
        AS USER_RECORDED_IN_CHANGE,
    I.AUTHORIZATION_NAME
        AS CURRENT_JOB_DESCRIPTION_USER
FROM JD_CHANGES AS C
LEFT JOIN QSYS2.JOB_DESCRIPTION_INFO AS I
  ON I.JOB_DESCRIPTION_LIBRARY =
     C.JOB_DESCRIPTION_LIBRARY
 AND I.JOB_DESCRIPTION =
     C.JOB_DESCRIPTION
ORDER BY
    C.ENTRY_TIMESTAMP DESC;

A mismatch can mean the job description changed again, was deleted or recreated, or is unavailable in the current ASP or authority context.

Filter by the profile making the change

SELECT
    ENTRY_TIMESTAMP,
    USER_NAME AS CHANGED_BY,
    QUALIFIED_JOB_NAME,
    PROGRAM_LIBRARY,
    PROGRAM_NAME,
    JOB_DESCRIPTION_LIBRARY,
    JOB_DESCRIPTION,
    PREV_JOB_DESCRIPTION_USER,
    JOB_DESCRIPTION_USER
FROM TABLE(
    SYSTOOLS.AUDIT_JOURNAL_JD(
        STARTING_TIMESTAMP =>
            CURRENT TIMESTAMP - 30 DAYS,
        USER_NAME =>
            'DEPLOYUSR'
    )
)
ORDER BY
    ENTRY_TIMESTAMP DESC;

Do not confuse the USER_NAME input parameter with the JOB_DESCRIPTION_USER result column.

Use durable receiver and sequence checkpoints

For repeatable extraction, common parameters include:

STARTING_RECEIVER_LIBRARY
STARTING_RECEIVER_NAME
ENDING_RECEIVER_LIBRARY
ENDING_RECEIVER_NAME
STARTING_SEQUENCE
ENDING_SEQUENCE

Do not specify both a starting timestamp and starting sequence, or both an ending timestamp and ending sequence.

Sequence numbers can be reset, so a durable checkpoint should include receiver identity as well as sequence.

Auditing must already be active

The function can return only evidence that exists in QSYS/QAUDJRN.

Security auditing must have been active when the event occurred. IBM states that when auditing is active, a JD entry is written whenever the job-description USER parameter is changed.

Review:

QAUDJRN existence
QAUDCTL
QAUDLVL
QAUDLVL2
receiver management
receiver retention
audit failure handling

A query cannot reconstruct an event that was never audited or whose receiver is no longer available.

Required authority

The caller must have:

*USE authority to QSYS/QAUDJRN
*OBJEXIST authority to QSYS/QAUDJRN
*USE authority to every requested audit receiver

Use a dedicated audit-reporting profile rather than granting *ALLOBJ for convenience.

Store and review the findings

A protected snapshot table can preserve:

System
Receiver
Sequence
Timestamp
Changed-by profile
Qualified job
Program
Job description
Command type
Previous user
New user
Review status
Change reference
Review notes

Useful statuses include:

NEW
APPROVED
EXPECTED DEPLOYMENT
UNDER REVIEW
UNAUTHORIZED
REVERTED
RISK ACCEPTED

High-value alert conditions

Alert on conditions such as:

*RQD changed to a named profile
A sensitive profile assigned
A production JOBD changed outside a maintenance window
An unexpected profile made the change
The same JOBD changed repeatedly
A new JOBD created with a named profile
No matching approval record

Treat alerts as triage, not automatic proof of a security incident.

Review object authority too

When a job description names a profile, review:

Who has *USE authority?
Who can change the object?
Is *PUBLIC authorized?
Which groups have access?
Is adopted authority involved?
Where is the JOBD referenced?

A technically valid CHGJOBD can still create an excessive access path.

Understand when the change takes effect

A job-description change affects jobs started after the change that use the affected attribute.

It does not retroactively change already-running jobs.

It may not affect a submitted job when the relevant value is overridden by SBMJOB, BCHJOB, or an application wrapper.

Review both the job description and the method used to start the job.

Do not automatically revert

Do not automatically issue CHGJOBD solely because an audit entry appears unexpected.

A safer response is:

Detect
Preserve evidence
Assess current state
Confirm business purpose
Review authority
Contain if necessary
Correct through approved change control
Validate future jobs

Release requirement

SYSTOOLS.AUDIT_JOURNAL_JD is delivered with:

IBM i 7.6 — Db2 Group PTF SF99960 Level 3
IBM i 7.5 — Db2 Group PTF SF99950 Level 12

It is part of the IBM i 7.6 TR2 and IBM i 7.5 TR8 update streams.

Final takeaway

A job description is not merely a work-management template.

Its USER parameter can influence the identity under which future jobs run.

SYSTOOLS.AUDIT_JOURNAL_JD makes the change history queryable:

Who changed it
When it changed
Which job description changed
Which command was used
The previous profile
The new profile
The job and program context
The exact receiver and sequence

The function provides visibility.

The security outcome still depends on auditing, retained receivers, controlled authority, review ownership, and an accurate understanding of how jobs use the job description.