IBM i security basics for administration: special authorities, object authority, QSECURITY, and QAUDJRN

What it is

IBM i access control has two independent layers. Special authorities, granted through the SPCAUT parameter on a user profile, control system-wide capabilities rather than access to one object. *ALLOBJ (all-object) lets a user access any resource on the system regardless of that object's own authority settings — even an object explicitly set to *EXCLUDE for that user becomes accessible — but it does not by itself allow creating or changing user profiles, which requires the separate *SECADM (security administrator) special authority. A user needs both *ALLOBJ and *SECADM to grant *SECADM to someone else.

Object authority is the per-object layer: who can read, change, or manage a specific library, file, or program. DSPOBJAUT displays who is authorized to an object (owner, private authorities, *PUBLIC, and any authorization list securing it); EDTOBJAUT edits those authorities interactively, and GRTOBJAUT/RVKOBJAUT do so non-interactively. A *GROUP entry in the User column of that display means the requester was authorized to the object through a group profile rather than their own user profile directly — worth checking before concluding a user has no path to an object.

The QSECURITY system value sets the overall enforcement level (20, 30, 40 or 50 in ascending strictness on current releases; level 10 can no longer be set); level 40 and above additionally reject programs that use unsupported interfaces or other integrity exposures. DSPSYSVAL QSECURITY shows the current level; a change takes effect only at the next IPL and is a system-wide, high-impact action that belongs to a change window, not a routine task.

The QAUDJRN journal is IBM i's security audit trail: object accesses, authority failures, profile changes and more are logged there when the journal exists and auditing is turned on via the QAUDCTL and QAUDLVL system values (for example, *AUTFAIL and *PGMFAIL to log authority and program failures). CHGSECAUD creates the journal if needed and sets these values in one step rather than by hand; unlike QSECURITY, changes to these audit system values take effect without an IPL.

Why it matters

An agent doing administrative work on IBM i should reach for the least special authority that accomplishes the task — *SECADM alone for profile management, rather than *ALLOBJ — and should know that raising QSECURITY or turning on QAUDJRN auditing are consequential, auditable changes, not routine configuration.

How to apply

• Check a profile's special authorities (DSPUSRPRF) before granting *ALLOBJ; ask whether the narrower authority (*SECADM, *JOBCTL, *SAVSYS, and so on) is enough.
• Use DSPOBJAUT/EDTOBJAUT to check and set authority on specific objects rather than defaulting to *ALLOBJ access to get past a permission error.
• Check DSPSYSVAL QSECURITY and the QAUDJRN/QAUDLVL configuration before assuming what is or is not being logged.
• Treat any change to QSECURITY, QAUDCTL, or special authorities as requiring the same change control as a production configuration change.

Pitfalls

• Reading *ALLOBJ as "can do anything," including profile administration — it cannot, without *SECADM.
• Assuming QAUDJRN captures everything by default; auditing is opt-in per the QAUDLVL values configured.
• Forgetting that raising QSECURITY to 40+ can break programs that relied on integrity exposures the lower levels tolerated; test before changing in production.