Block User Rules

Channel authentication in IBM MQ can allow partners by IP, map certificates to MCAUSER, and authorize remote queue manager names—but none of that stops a client from asserting a dangerous user ID on an SVRCONN unless you explicitly deny it. Block user rules (CHLAUTH TYPE(BLOCKUSER)) maintain a deny list of user IDs that must never connect: guest, anonymous, default vendor accounts, or IDs from decommissioned applications. They are a thin but important layer in defense in depth after you enable CHLAUTH. Penetration testers routinely probe SVRCONN channels with common weak names; BLOCKUSER turns those probes into logged blocks instead of silent adoption as mqm. This tutorial explains USERLIST syntax, scoping rules to channels, ordering with other CHLAUTH types, operational DISPLAY and REMOVE, false positives when applications legitimately use a blocked name, and how block user rules complement ADDRESSMAP and SSLPEERMAP rather than replacing them.

Why Deny Lists Still Matter

Modern CONNAUTH requires passwords or certificates, yet misconfigured SVRCONN channels with weak MCAUSER or overly permissive USERMAP rules occasionally allow asserted IDs through. Default product samples and training environments sometimes create users like mquser or guest that drift into production clones. BLOCKUSER gives security teams a single repository object to audit: DISPLAY CHLAUTH shows exactly which IDs are forbidden. Compliance frameworks ask for explicit denial of anonymous access; BLOCKUSER is one MQ-native way to demonstrate that control.

BLOCKUSER attributes (typical)
AttributePurpose
TYPE(BLOCKUSER)Identifies rule as user deny list
USERLIST(...)One or more user IDs to block
ACTION(BLOCK)Reject matching connections
CHLAUTH nameAdministrative label for DISPLAY and REMOVE
Channel scopeWhich CHNAME pattern the rule applies to

Creating Block User Rules

shell
1
2
3
4
5
6
7
8
SET CHLAUTH('BLOCK.WEAK.USERS') TYPE(BLOCKUSER) + USERLIST('guest','nobody','anonymous') ACTION(BLOCK) + DESCR('Deny well-known weak IDs on all channels') SET CHLAUTH('BLOCK.OLD.APP') TYPE(BLOCKUSER) + USERLIST('legacyapp') ACTION(BLOCK) + CHNAME('PAYMENTS.APP') DISPLAY CHLAUTH('BLOCK.WEAK.USERS') ALL REMOVE CHLAUTH('BLOCK.OLD.APP')

CHNAME scopes the rule to a specific SVRCONN or pattern per IBM matching rules for your release. A global weak-user block often uses a broad channel name pattern documented in your standards. When an application is retired, add its service ID to BLOCKUSER before deprovisioning OAM grants so stray automation fails fast.

What Gets Blocked

BLOCKUSER evaluates the user ID presented during client connection attempts—MQCONNX with a user name, or adoption scenarios described in IBM documentation. It does not replace network firewalls. It does not encrypt traffic. Message channel agents passing remote MCAUSER in protocol may be governed by different rule types; focus BLOCKUSER design on client-facing SVRCONN and CLNTCONN paths first. Test with mqclient or your application stack presenting each blocked ID; expect bind failure and CHLAUTH event in the log naming BLOCK.WEAK.USERS.

Combining With Other CHLAUTH Rules

  • ADDRESSMAP — allow partner subnet; BLOCKUSER still stops guest from allowed IP.
  • SSLPEERMAP — map good cert to apppay; BLOCKUSER stops cert-less assert of admin ID if policy allows.
  • USERMAP — route known good developers; BLOCKUSER catches everything else on a deny list.
  • Default rules — understand whether IBM defaults already block some IDs before duplicating.

Security architects document evaluation order on a poster for the operations center. Support engineers should not remove BLOCKUSER globally when one application misbehaves—fix the application ID or add USERMAP instead.

Operational Procedures

  1. Quarterly review USERLIST against active directory of service accounts.
  2. When onboarding apps, confirm their ID is not on BLOCKUSER.
  3. When offboarding, add ID to BLOCKUSER before deleting OAM grants.
  4. Export DISPLAY CHLAUTH TYPE(BLOCKUSER) after changes for CMDB.
  5. Monitor CHLAUTH block events for spikes indicating attack or misconfiguration.

False Positives and Exceptions

If a legitimate application still uses user ID guest in a legacy jar, BLOCKUSER exposes technical debt—migrate the application to a proper ID and SSLPEERMAP rather than removing the block. Temporary exceptions require a named rule with narrow CHNAME scope and expiry date in the change ticket, not deletion of the global deny list. Document approver and rollback REMOVE CHLAUTH command.

Explainer: Banned Names List

BLOCKUSER is the list of names not allowed on the guest list at the event—even if someone arrives from an approved address, if they sign in as guest they are turned away.

Explain Like I'm Five: Block User Rules

Block user rules are a list of names that are never allowed to use MQ, like a no-entry list for bad nicknames.

Practice Exercises

Exercise 1

Write SET CHLAUTH BLOCKUSER for three weak IDs and describe the test to prove it works.

Exercise 2

Why block guest at CHLAUTH if MCAUSER is already apppay?

Exercise 3

Draft offboarding steps: BLOCKUSER, revoke OAM, disable cert.

Frequently Asked Questions

Frequently Asked Questions

Test Your Knowledge

Test Your Knowledge

1. BLOCKUSER TYPE means:

  • Deny listed user IDs
  • Map IP only
  • Set cipher
  • Create XMITQ

2. USERLIST on BLOCKUSER contains:

  • User IDs to block
  • Queue names
  • Ports
  • Cipher specs

3. BLOCKUSER is best for:

  • Known weak accounts
  • Replacing TLS
  • Batch size
  • Topic wildcards

4. BLOCKUSER vs ALLOW ADDRESSMAP:

  • Deny ID vs allow IP
  • Same rule
  • Both set DLQ
  • Both set HBINT
Published
Read time17 min
AuthorMainframeMaster
Verified: IBM MQ 9.3 documentation