How to Audit IBM i – Part 2: A Practical Guide for IBM i Audit and Compliance

In Part 1 of this topic, I have discussed,

In this section, I will provide a practical guide on how to accomplish this task.

Table of Contents

IBM i Audit Types (What You Can Audit)

IBM i offers flexible audit types to fit your needs. Each serves a different purpose. Here’s a breakdown:

Audit TypeWhat it does
Security Audit Journal (QAUDJRN)This is your main hub. Enable it, and you get a chronological record of everything.

All security audit entries go into QAUDJRN
Stored in journal receivers (QAUDJRNxxx)
Controlled by system values

Without QAUDJRN, there is no IBM i auditing.
System ValuesYou control auditing via values like QAUDLVL (actions to audit) and QAUDCTL (what’s active, e.g., *AUDLVL for action auditing). Adjust these to fine-tune what the system captures.

System values control critical behavior like:
Password rules
Sign-on limits
Security level

You can audit:

Changes to system values
Who changed them
When they changed

This protects against silent security weakening.
Object AuditFocus on specific objects like files or programs. You track reads, changes, or deletes. Use this for sensitive data—set it per object or user.

Object auditing tracks access to specific objects, such as:

Database files
Programs
Data areas

You can audit:
Read access
Change access
Delete access
Failed access attempts

This is essential for sensitive data files.
User AuditMonitor individual users. You log their commands, profile changes, or object interactions. Great for auditing admins or suspicious accounts.

User auditing tracks actions by specific users, especially:

Users with special authority
Service accounts
Powerful profiles like QSECOFR clones

You can audit:

Sign-on attempts
Authority failures
Profile changes
Network AuditCatch network events, like failed logins or IP address changes. You use this to spot external threats or unauthorized access attempts.

Network auditing tracks:

FTP access
ODBC/JDBC access
Remote command execution
Exit point activity

This is critical because many IBM i breaches happen through network services, not green-screen sign-ons.

Key IBM i Auditing Commands

Commands make IBM i auditing actionable. Here are the must-haves:

Audit Setup & Configuration

These commands define what events the system should record.

CommandPurpose
CHGSECAUDChange Security Auditing: A “wizard-like” command to set up the auditing environment, including creating the QAUDJRN journal and setting initial system values.
CHGAUDChange Auditing Value: Sets the auditing level for a specific object (e.g., *NONE, *ALL, *CHANGE). It determines if actions on that object trigger an audit entry.
CHGUSRAUDChange User Audit: Defines which actions a specific user performs should be audited (e.g., auditing all commands run by a powerful profile).
CHGOBJAUDChange Object Auditing: Similar to CHGAUD, used to specify if access to a specific object should be logged based on the user’s audit settings.
WRKSYSVALWork with System Values: Used to manage QAUDCTL (Audit Control) and QAUDLVL (Audit Level), which are the “master switches” for system-wide auditing.

Analysis & Reporting

Once data is collected in the audit journal, these commands help you extract and read it.

CommandPurpose
DSPAUDJRNEDisplay Audit Journal Entries: Generates reports from the audit journal. You can filter by user, date, or entry type (e.g., AF for authority failures). Note: IBM now recommends using SQL services for more detailed analysis.
CPYAUDJRNECopy Audit Journal Entries: Exports audit data into a database file (out-file). This is standard practice for compliance because it allows you to run Queries or SQL against the data.
DSPSECAUDCheck your current auditing setup. Displays current information about the security audit journal and the current settings for the system values that control what is being audited on the system.
Restriction: You must have audit (*AUDIT) special authority to run this command.
DSPJRNDisplay Journal: The raw way to view entries in QAUDJRN. It is highly flexible but requires knowledge of journal entry codes (like T-AF for Authority Failures).
PRTADTRPTPrint Audit Report: Used in some environments to print specific formatted reports based on collected audit data.

Compliance & Vulnerability Assessment

These tools help you check if your current configuration meets security best practices.

CommandPurpose
ANZPRFACT(Analyze Profile Activity): Helps find “stale” user profiles that haven’t signed on in a long time—a key requirement for SOX and PCI compliance.
ANZUSROBJ(Analyze User Objects): Identifies objects owned by a user, which is useful when offboarding or auditing “orphaned” objects.
PRTCMDUSG (Print Command Usage): Generates a report on how specific commands are being used and by whom.
PRTPVTAUT (Print Private Authority): Reports on all users who have specific, private authority to objects, helping you identify “authority creep.”

Modern Alternative: IBM i Services (SQL)

While the commands above are the traditional method, modern compliance auditing is often done via SQL Table Functions. For example:

How to Configure and Enable IBM i Auditing

Configuring auditing on IBM i revolves around the QAUDJRN (Security Audit Journal). While you can set this up manually using multiple commands, the most efficient and recommended way is using the “all-in-one” command: CHGSECAUD.

Here is the step-by-step process to enable and configure auditing.

Use SECTOOLS menu for a guided setup—it’s a lifesaver for beginners.

Step 1: Run DSPSECAUD.

This command displays current information about the security audit journal and the current settings for the system values that control what is being audited on the system.

Step 2: Automated Setup with CHGSECAUD

The CHGSECAUD (Change Security Auditing) command is a shortcut. If the QAUDJRN doesn’t exist, this command creates it, creates a journal receiver, and sets the critical system values all at once. Run this command (requires *ALLOBJ and *AUDIT authority)

CHGSECAUD QAUDCTL(*AUDLVL *OBJAUD NOQTEMP) QAUDLVL(AUTFAIL *SECURITY *SERVICE *DELETE *PGMFAIL) INLJRNRCV(QGPL/AUDRCV0001)

What this command does:

  1. Creates QAUDJRN in library QSYS, if it is not already created.
  2. Creates Receiver AUDRCV0001 in QGPL (you can change the library to a dedicated audit library like JRNLIB).
  3. Sets QAUDCTL (Audit Control):
    • *AUDLVL: Enables auditing based on levels.
    • *OBJAUD: Enables specific object auditing.
    • *NOQTEMP: Prevents bloating logs with temporary session data.
  4. Sets QAUDLVL (Audit Level): This defines what is logged (e.g., authority failures, security-sensitive changes).
sample configuration with more audit values and custom journal receiver library

Step 3: Configure System Behavior (System Values)

After the initial setup, check these two system values via WRKSYSVAL to ensure the system handles audit logs correctly:

Step 4: Enable Object-Level Auditing

Even if auditing is “on,” the system won’t track access to specific files unless you tell it which ones are sensitive.

Step 5: Enable User-Level Auditing

If you want to watch a specific high-risk user (e.g., a contractor or someone with *ALLOBJ), use CHGUSRAUD.

Step 6: Verify the Setup

To confirm auditing is active and see what is currently being tracked, use: DSPSECAUD.

This displays a summary of your current QAUDCTL and QAUDLVL settings and confirms that the journal is active.

Important Maintenance Tip

Audit journals can grow very large and consume disk space quickly.

How to Monitor IBM i Audits Effectively

Monitoring keeps you in the loop. You review QAUDJRN regularly with DSPJRN or DSPAUDJRNE.

Modern IBM i administration has shifted away from manual command-line scrolling to Automation and SQL.

Analyzing Reports (The “New” Way via SQL)

IBM i Services (SQL) are now the gold standard for compliance. SQL allows you to join audit data with user information to find exactly who did what.

SELECT COUNT(*)
FROM TABLE(
  SYSTOOLS.AUDIT_JOURNAL_AF(
    STARTING_TIMESTAMP => CURRENT TIMESTAMP - 7 DAYS,
    USER_NAME => 'SAMEERA'
  )
)
WHERE VIOLATION_TYPE = 'A';
SELECT *
FROM TABLE(
  SYSTOOLS.AUDIT_JOURNAL_CP(
    STARTING_TIMESTAMP => CURRENT TIMESTAMP - 7 DAYS
  )
);

Key Audit Entry Types to Track

When generating reports, focus on these specific Journal Entry Types:

Entry TypeDescriptionWhy it matters for Compliance
AFAuthority FailureDetects unauthorized access or hacking attempts.
CPUser Profile ChangeTracks when someone gains higher privileges.
CDCommand RunProvides a “paper trail” of what admins did.
PWPassword InvalidIdentifies brute-force login attacks.
SVSystem Value ChangeTracks changes to global security settings.
ORObject RestoredDetects if an old (possibly insecure) file was restored.

You can generate reports using:

Automation Strategy

For true compliance (like SOX, HIPAA, or PCI-DSS), you should:

  1. Schedule a Nightly Job: Use the CPYAUDJRNE command or an SQL script to export the last 24 hours of data into a “Security History” file.
  2. Exception Reporting: Create a report that only shows Authority Failures (AF) and System Value changes (SV).
  3. Review Signature: Keep a log of when these reports were reviewed by a security officer.

For real-time alerts, integrate with SIEM tools—activate journaling and specify users to monitor. Third-party solutions like Fortra’s Powertech Complaince Monitor for IBMI i/Powertech SIEM Agent for IBM i or Precisely’s Assure Monitoring and Reporting automate this.

Best Practices for IBM i Auditing