IBM i (AS/400) Security: Levels, Authorities, Exit Points

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)

Level	Name	What it enforces	Position
10	No security	No longer supported; QSECURITY cannot be set to 10	Gone
20	Sign-on security	User ID and password required; only security officers or `*SECADM` users create profiles; users have access to all resources	Unacceptable for production
30	Resource security	Users need specific authority to each resource; only `SECOFR` class profiles automatically get `ALLOBJ`	Minimum, but leaves integrity gaps
40	Integrity protection	Programs fail if they use unsupported interfaces or restricted instructions; protects job descriptions; prevents sign-on without a password; protects program and job address spaces	Shipped default and recommended baseline
50	Enhanced integrity	Adds checks on parameter values passed to supported interfaces; aimed at strict requirements including some Common Criteria requirements	Highest assurance; test carefully

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.

Special authority	What it allows	Risk
`*ALLOBJ`	Access to any object, even where the user has `*EXCLUDE`; view, change, delete or grant access to anything	Total control of data; can run batch jobs under profiles holding other authorities
`*SECADM`	Create, change and delete user profiles; manage system distribution directory and access codes	Account creation and takeover; granting `SECADM` to others requires both `SECADM` and `*ALLOBJ`
`*AUDIT`	Change system, object and user auditing (`CHGOBJAUD`, `CHGDLOAUD`, `CHGUSRAUD`)	Can stop auditing or exclude actions; control and monitor tightly
`*SERVICE`	Start service tools (`STRSST`), debug programs, display and alter service functions	Display and change confidential information
`*SAVSYS`	Save, restore and free storage for all objects regardless of authority	Copy data to tape for another system; restore altered objects
`*SPLCTL`	All spool functions on any output queue	Read every confidential report
`*JOBCTL`	Manage other users' jobs and queues, stop subsystems, perform an IPL	Denial of service; job manipulation
`*IOSYSCFG`	Change system and communications configuration, including most TCP/IP commands	Network reconfiguration, host server and FTP changes

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 point	Called for	Typical control
`QIBM_QZDA_INIT`	Each database server start (ODBC, JDBC, IBM i Access)	Allow only known users and source IP addresses
`QIBM_QZDA_SQL1` / `QIBM_QZDA_SQL2`	SQL prepare, open, execute, connect, execute immediate and package functions; SQL2 takes precedence when both are registered	Log statements; block `UPDATE` or `DELETE` by read-only reporting profiles
`QIBM_QZDA_NDB1`	Native database requests: create and delete files and members, overrides, library list changes	Block file creation and deletion from client tools
`QIBM_QZDA_ROI1`	Retrieve object information and SQL catalog functions	Log catalog discovery
FTP, remote command, file and other host server exit points	FTP logon and requests, remote command and distributed program call, IFS access	Disable remote command for most users; restrict FTP to named profiles and directories

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.

Journal entry	Meaning	Why it matters
`AF`	Authority failure	Probing, misconfigured jobs, and level 40 readiness testing
`PW`	Invalid password or user ID	Password guessing (T1110.001)
`CP`	User profile created, changed or restored	New special authorities, re-enabled profiles
`SV`	System value changed	QSECURITY, QAUDCTL or password rules weakened
`AD`	Auditing changed for an object or user	Attempts to blind auditing
`CO`, `DO`	Object created, deleted	New programs in production libraries
`RA`, `OR`	Authority changes on restore, object restored	Restored programs that adopt authority

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

System value or setting	Baseline	Notes
`QSECURITY`	40 (50 where justified)	IPL required; test with AF entries first
`QPWDLVL`	3, or 4 where MFA is used	IPL required; check NetServer and peer system compatibility
`QCRTAUT`	`EXCLUDE` or `USE` for new objects	Libraries can override with their own create authority
`QAUDCTL` / `QAUDLVL`	`AUDLVL OBJAUD` / at least `*DFTSET`	Set with `CHGSECAUD`
`QMAXSIGN` / `QMAXSGNACN`	3 to 5 attempts / disable profile	Protects against guessing
`QLMTSECOFR`	1	Powerful profiles need explicit device authority
`QINACTITV`	15 to 30 minutes	Ends or disconnects idle interactive jobs
`QALWOBJRST` / `QVFYOBJRST`	Restrict restore of security-sensitive objects; verify signatures	Blocks restored programs that adopt authority
Security attribute change controls	Lock with `CHGSSTSECA` or `CHGSECA` (security system values, DCM, exit programs)	Stops changes to security system values without service tools access

Rollout in phases

Baseline: query QSYS2.SECURITY_INFO (requires *SECADM or *AUDIT), list profiles and special authorities, run ANZDFTPWD and PRTADPOBJ, and turn on auditing with CHGSECAUD.
Quick wins: fix default passwords, set PASSWORD(*NONE) on non-interactive profiles, remove unused special authorities and stop unused host servers.
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.
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.
Security level: move to QSECURITY 40 on a test partition, then production at a planned IPL.
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

Framework	Reference	IBM i control
NIST SP 800-53 Rev. 5	AC-2; AC-3; AC-6; IA-2; IA-5; AU-2; AU-6; AU-12; CM-6	Profile lifecycle; object authority; special authority restriction; MFA and password levels; QAUDJRN; system values
NIST CSF 2.0	PR.AA-01; PR.AA-05; PR.PS-01; PR.PS-04; DE.CM-03	Identity management, least privilege, configuration baseline, audit logging, monitoring of privileged users
CIS Controls v8.1	Controls 4, 5, 6 and 8	Secure configuration, account management, access control, audit log management
ISO/IEC 27001:2022 Annex A	A.5.15; A.5.18; A.8.2; A.8.5; A.8.15	Access control, access rights review, privileged access, secure authentication, logging
MITRE ATT&CK	T1078; T1078.001; T1110.001; T1005; T1048	Valid and default accounts, password guessing, data collection and exfiltration over FTP or ODBC

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.

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