IBM i Security Guide: Security Levels, Special Authorities, Exit Points and Audit Journal

IBM i (the platform formerly known as AS/400, iSeries and System i) has one of the most capable built-in security models of any operating system, and one of the most frequently misconfigured, because many systems still carry settings chosen decades ago for green-screen menus that no longer protect anything. Users once confined by menu-based security can now reach the same data through ODBC, FTP, file shares and remote command servers, and over-granted special authorities such as *ALLOBJ make every one of those paths a route to the whole system. This guide explains how identity and authority work on IBM i, how to control the special authorities that make a profile powerful, how to govern service and application profiles, how to use exit points and the QAUDJRN audit journal for control and detection, and which system values form a hardening baseline. It is distinct from z/OS and RACF, which the Mainframe Identity and RACF Security Guide covers. It is for IBM i administrators, security officers and auditors.

Key takeaways

• Run at QSECURITY 40 or higher. Level 30 adds resource security, level 40 adds integrity protection against unsupported interfaces, and level 40 is the shipped default; level 20 gives every signed-on user access to all resources.
• Special authorities are the real privilege model. *ALLOBJ overrides even *EXCLUDE, *SECADM manages profiles, *AUDIT can switch auditing off and *SERVICE opens service tools. Track every holder and justify each one.
• Menu security is not security. Network interfaces bypass menus and command-line limits. Object authority, especially *PUBLIC, is what actually controls access.
• Exit points close the network gap. Exit programs registered with WRKREGINF on points such as QIBM_QZDA_INIT and QIBM_QZDA_SQL2 can log and reject ODBC, JDBC and other host server requests that object authority alone permits.
• Turn on the audit journal. CHGSECAUD creates QSYS/QAUDJRN and sets QAUDCTL and QAUDLVL; without it there is no record of authority failures, security changes or who used a powerful profile.

How identity and access work in IBM i

Every job runs under a user profile. The profile holds the password (and, from IBM i 7.6, an optional TOTP key), a user class, special authorities, group profiles, an initial program and menu, and the LMTCPB (limit capabilities) setting. Objects (programs, files, libraries, IFS directories, devices) each carry an owner, a *PUBLIC authority and optional private authorities or an authorisation list.

Security levels (QSECURITY)

Moving from 20 or 30 to 40 needs testing: run with auditing enabled first and look for authority failure (AF) journal entries that indicate programs using unsupported interfaces, then change the value, which takes effect at the next IPL.

Password level and MFA

• QPWDLVL 0 and 1: passwords of 1 to 10 characters; level 0 is the shipped default. Level 1 removes LAN Manager passwords used by NetServer for old Windows clients.
• QPWDLVL 2 and 3: case-sensitive passwords and passphrases of 1 to 128 characters; level 3 removes LAN Manager passwords. Changing QPWDLVL needs *ALLOBJ and *SECADM and an IPL, and it does not apply to service tools IDs.
• MFA (IBM i 7.6): the Additional sign-on factor security attribute enables TOTP (RFC 6238) for user profiles. It requires QSECURITY 40 or higher and QPWDLVL 4 or higher, applies only to profiles changed to require it, and can be entered in an additional factor field or appended to the password after a colon. Service tools (SST and DST) use a separate TOTP implementation that can be enabled independently. See the MFA Guide.
• Password composition: set QPWDMINLEN, QPWDRULES, QPWDEXPITV, QMAXSIGN and QMAXSGNACN to match your password standard; QSYS2.SECURITY_INFO shows them in one row.

Admin roles and privileged access

IBM i has no single "root"; power comes from special authorities assigned to profiles directly or inherited from group profiles. IBM's own guidance is that giving special authorities to users represents a security exposure, and that holders should be tracked and reviewed periodically.

• Who should hold what: *ALLOBJ and *SECADM only for named security officers and a break-glass QSECOFR-class profile; *AUDIT for the audit or security function, separated from day-to-day administration; *SAVSYS and *JOBCTL for operations profiles only where needed. Programmers should not hold *ALLOBJ on production.
• Group profiles: special authorities inherited from a group profile are easy to miss in reviews. Review the effective authorities, not just those on the profile.
• Limit security officer access: QLMTSECOFR restricts which devices *ALLOBJ and *SERVICE users can sign on from.
• Adopted authority: a program created with USRPRF(*OWNER) runs with its owner's authority. Owned by QSECOFR or another *ALLOBJ profile, it is an elevation path. Review adopting programs with PRTADPOBJ, and control who may create them with QUSEADPAUT.
• Elevation on demand: rather than standing *ALLOBJ, use a process (or a commercial tool) that grants elevated authority for a ticketed period and logs everything done with it. See the Privileged Access Management Guide.

Integrations, API tokens and service accounts

IBM i systems usually run decades of batch jobs, interfaces and middleware, each with its own profile. These are non-human identities and should be governed as such. See the Service Account Security Guide.

• IBM-supplied profiles: profiles beginning with Q (for example QSECOFR, QSYSOPR, QPGMR, QUSER, QSRV) exist on every system. Most should have PASSWORD(*NONE) or be disabled; a profile whose password equals its name is a default account (T1078.001). The ANZDFTPWD command reports and can disable or expire profiles with default passwords.
• Application and batch profiles: set PASSWORD(*NONE) for profiles that only own objects or run submitted jobs, so nobody can sign on with them; use LMTCPB(*YES), an initial program and no command line for any that must sign on.
• Job descriptions: a job description naming a powerful user profile lets anyone with *USE authority to the job description submit work as that profile. At level 40 the submitter also needs authority to the profile; at lower levels it is a privilege escalation path. Review job descriptions with USER other than *RQD.
• Interface credentials: ODBC and JDBC connection strings, FTP scripts and middleware configuration files on Windows and Linux servers often hold IBM i profile passwords. Move them into a vault and give each interface its own profile with only the object authority it needs. See the Secrets Management Guide.
• Profile ownership: every non-human profile needs a named owner, a purpose and a review date in the identity inventory, the same as the Mainframe Service Accounts and Batch Job Identity Guide recommends for z/OS batch identities.

Exit points for network services

Exit programs receive each request before the server runs it, with a return code parameter: setting it to X'F0' rejects the request, any other value allows it. They are registered with WRKREGINF (Work with Registration Information).

Exit programs are an extra control, not a substitute for object authority: anything not covered by a registered exit point is decided by object authority alone. Also stop host servers that are not used (for example FTP or REXEC) through their autostart settings.

Logging and detection

CHGSECAUD QAUDCTL(*AUDLVL) QAUDLVL(*DFTSET) creates the QSYS/QAUDJRN journal and receiver if needed, sets QAUDCTL to *AUDLVL and sets QAUDLVL to the default set of *AUTFAIL, *CREATE, *DELETE, *SECURITY and *SAVRST. It requires *ALLOBJ and *AUDIT. Add *OBJAUD to QAUDCTL to audit access to specific sensitive objects, and *AUDLVL settings per user with CHGUSRAUD for powerful profiles.

Forward journal entries to the SIEM (many organisations use a syslog forwarder or the SQL services such as QSYS2.DISPLAY_JOURNAL to extract them) so a *AUDIT holder on the box cannot quietly remove the evidence. Correlate exit program logs with QAUDJRN to see which network user ran which SQL. See the SIEM Guide.

Metrics

• Powerful profiles: number of enabled profiles with *ALLOBJ, *SECADM, *AUDIT or *SERVICE, including via groups.
• Default passwords: profiles reported by ANZDFTPWD (target zero).
• Public exposure: production libraries and files where *PUBLIC is *CHANGE or *ALL.
• Exit coverage: percentage of active host servers with a registered exit program that logs requests.
• Audit health: days since QAUDJRN entries last reached the SIEM, and count of SV and CP entries outside change windows.

Hardening baseline

Rollout in phases

1. Baseline: query QSYS2.SECURITY_INFO (requires *SECADM or *AUDIT), list profiles and special authorities, run ANZDFTPWD and PRTADPOBJ, and turn on auditing with CHGSECAUD.
2. Quick wins: fix default passwords, set PASSWORD(*NONE) on non-interactive profiles, remove unused special authorities and stop unused host servers.
3. Exit programs in log-only mode: register exit programs that record but never reject, for at least one business cycle, to learn which users, IPs and SQL operations are legitimate.
4. Object authority: tighten *PUBLIC on production libraries and files, starting with the most sensitive data, using authorisation lists; watch AF entries and grant private authority where genuine access fails.
5. Security level: move to QSECURITY 40 on a test partition, then production at a planned IPL.
6. Enforce: switch exit programs to reject mode for unknown users and sources. Rollback is re-registering the log-only version, so keep both in source control.

Small shops with one partition can do this with native commands and SQL services. Larger estates with many partitions usually add a commercial exit point and audit tool, central profile management and SIEM integration.

Common misconfigurations

• Menu-only security: users with LMTCPB(*YES) and a restricted menu but *PUBLIC *CHANGE on files can update them freely through ODBC, FTP or Excel.
• *ALLOBJ everywhere: programmers, operators and vendor support profiles given *ALLOBJ "temporarily" years ago.
• Default and shared passwords on IBM-supplied and vendor profiles: the first thing an attacker or a curious insider tries (T1078.001).
• QSECURITY 20 or 30 on production: at 20 every user can access every resource.
• No audit journal, or one nobody reads: no evidence after an incident, and *AUDIT holders can switch it off unseen.
• Root IFS shared through NetServer: exposes the whole integrated file system, including /QSYS.LIB, to Windows clients and to ransomware running on them.
• Job descriptions naming QSECOFR: anyone allowed to use the job description can submit work as the security officer on systems below level 40.

Framework mapping

Practitioner checklist

• Confirm QSECURITY is 40 or higher on every partition and plan the change where it is not.
• Run CHGSECAUD with at least *DFTSET, add *OBJAUD for sensitive files and forward QAUDJRN to the SIEM.
• List every profile holding *ALLOBJ, *SECADM, *AUDIT, *SERVICE or *SAVSYS, including through groups, and remove what is not justified.
• Run ANZDFTPWD and fix every default password; set PASSWORD(*NONE) on batch, owner and interface profiles.
• Register exit programs on the database, FTP and remote command servers, in log mode first, then enforce.
• Tighten *PUBLIC authority on production libraries and set QCRTAUT to *EXCLUDE or *USE.
• Review adopted-authority programs with PRTADPOBJ and job descriptions that name a user profile.
• Raise QPWDLVL to 3 or 4 and enable the additional sign-on factor (TOTP) for powerful profiles on IBM i 7.6.
• Lock security system values with the service tools security attributes so changes need service tools access.

Standards and references

• IBM: Security system values: Security level (QSECURITY)
• IBM Support: IBM i security levels
• IBM Support: Special authorities
• IBM: Using CHGSECAUD to set up security auditing
• IBM: Database server exit points
• IBM: SECURITY_INFO view
• IBM: IBM i multifactor authentication overview
• IBM Support: QPWDLVL password level

Related NHI Mgmt Group resources: Mainframe Identity and RACF Security Guide · IBM AIX Security Hardening Guide · Service Account Security Guide · Privileged Access Management Guide