Object Authority Manager (OAM)

The Object Authority Manager is IBM MQ's enforcement engine for authorization. Every time an application or channel-associated identity attempts to open a queue, publish to a topic, alter a channel, or browse a process definition, OAM compares the requested operation against stored grants for that principal on that object. A missing +put does not mean “try harder”—it means MQRC_NOT_AUTHORIZED reason code 2035 and no message on the queue. On distributed queue managers OAM data is manipulated with setmqaut and dspmqaut and viewed with DISPLAY AUTHREC in MQSC; on z/OS the same logical checks flow through RACF profiles. Beginners hear “OAM” in audit reports without knowing it is not a separate installable product but part of the queue manager. This tutorial explains OAM placement in the security model, AUTHREC structure, default authority behavior, group expansion, queue manager-level versus object-level records, interaction with MCAUSER, caching and open handle semantics, migration from default-allow estates, and troubleshooting DISPLAY output when 2035 persists after apparent grants.

OAM in the Request Path

After TCP, TLS, CONNAUTH, and CHLAUTH, the MQI thread resolves the effective user ID. MQOPEN requests a combination of access options—output, input, browse—and OAM maps those to authority bits. A single open for output requires +put; for input +get. Pass-through operations on alias queues check the base queue authority. OAM failure is immediate; there is no partial open. Channel agents performing puts on behalf of remote partners use MCAUSER as principal unless context overrides apply per IBM rules for your release.

OAM record scope
ScopeObjectExample grant
Queue manager@class(qmgr) or qmgr name+connect for clients
QueueQLOCAL name+put +get for app
TopicTOPIC name+pub +sub
ChannelCHANNEL name+ctrl for operations
GroupAny aboveGrant to mqapps group

DISPLAY AUTHREC and setmqaut

shell
1
2
3
4
5
DISPLAY AUTHREC PROFILE('PAYMENT.IN') OBJTYPE(QUEUE) PRINCIPAL('mqpay') DISPLAY AUTHREC PROFILE('PAYMENT.IN') OBJTYPE(QUEUE) GROUP('MQAPPS') setmqaut -m QM1 -n PAYMENT.IN -t q -p mqpay +put +get +browse setmqaut -m QM1 -n PAYMENT.IN -t q -g MQAPPS +dsp +inq dspmqaut -m QM1 -n PAYMENT.IN -t q -p mqpay

PROFILE names the object; OBJTYPE matches queue, topic, channel, and other enums. PRINCIPAL is a user; GROUP is a group grant—members inherit when platform group membership is correct. dspmqaut is the operator-friendly view; DISPLAY AUTHREC is authoritative in MQSC scripts. After bulk migrations, export AUTHREC lists to source control for drift detection.

Default Authority and Hardening

New objects may inherit default authority records—on some releases *PUBLIC or platform-specific defaults allow broad access until revoked. Security projects explicitly ALTER AUTHREC to remove public put/get and grant only service IDs. Queue manager AUTHOREC settings influence objects created without explicit grants. Document your estate baseline: “no +put for *PUBLIC on application queues.” Penetration tests often find one leftover default on a test queue that production traffic shares.

Groups and Least Privilege

Granting to group MQAPPS and adding application users to that OS or LDAP group scales better than per-user grants on thousands of queues. Separate groups for producers, consumers, and operators. Avoid nesting excessive privilege—operators need +crt on object classes for admin, not +all on payment queues. Review group membership quarterly; orphaned accounts in MQAPPS are a common audit finding.

OAM Versus RACF on z/OS

RACF stores profiles; MQ consults them during authorization. Commands differ from setmqaut but checks feel identical to application developers seeing 2035. Mixed hybrid estates need clear ownership: distributed team owns Linux QMgr setmqaut; mainframe team owns RACF profiles for z/OS QMgr. Never duplicate conflicting grants across migration cutover weekends without a rollback plan.

Why Grants Seem Ignored

  • Wrong principal—testing admin ID while production uses MCAUSER mqbridge.
  • Grant on alias queue but open resolves to base with different profile name.
  • Handle opened before grant—restart connection pool.
  • PUT inhibited—not OAM but similar symptom.
  • Typo in principal case—Unix IDs are case-sensitive.

Explainer: Security Guard With a Clipboard

OAM is the guard holding a clipboard listing which badge numbers may enter which room. No line on the clipboard for your badge means stop—even if you entered the building earlier through a different door.

Explain Like I'm Five: OAM

OAM is the list on the fridge that says which family members may open which snack box. If your name is not next to the cookie box, you cannot open it.

Practice Exercises

Exercise 1

Write DISPLAY AUTHREC commands for one queue and two principals.

Exercise 2

Explain difference between group grant and user grant.

Exercise 3

2035 after setmqaut—list five reasons grants appear ineffective.

Frequently Asked Questions

Frequently Asked Questions

Test Your Knowledge

Test Your Knowledge

1. OAM enforces:

  • Object-level access
  • TCP routing only
  • Cluster repository
  • JES job class

2. AUTHREC links:

  • Principal to object authorities
  • Queue to XMITQ only
  • Topic to retain
  • Channel to port

3. 2035 comes from:

  • Failed OAM check
  • Success path
  • TLS only
  • FTP

4. setmqaut on distributed:

  • Creates or updates grants
  • Starts listener
  • Defines cluster
  • Formats log
Published
Read time16 min
AuthorMainframeMaster
Verified: IBM MQ 9.3 documentation